2 ms·
It ultimately depends on how you define your TCB (trusted computing base). I am not aware of any formally verified compilers for any language, but assuming one
by Cyph0n 5y ago
It ultimately depends on how you define your TCB (trusted computing base). I am not aware of any formally verified compilers for any language, but assuming one exists, wouldn't you also require said compiler to run on a formally verified OS? Also, how do you tackle the infamous "Reflections on Trusting Trust" compiler attack? It's turtles all the way down :)
Long story short, for the vast majority of use-cases, developers can assume that the compiler and stdlib are trusted. This is also how Rust defines "safety", which leaves you to focus on your code and its dependencies.
- nineteen999 5y agoNot talking about situations where the compiler or the OS are compromised - of course all bets are off in those situations. But "guaranteed" that there can be no security holes in code marked "safe" due to an inadvertent compiler bug? I would be very surprised if that is actually the case. Less likely than C/C++? Yes of course. Guaranteed? Probably not.
- Cyph0n 5y agoAn inadvertent bug in the compiler can be modeled as a compromise. So, as before, it depends on how you define “safe” in your model. In the case of Rust, the compiler is safe and is considered to be within the safety boundary. Will the Rust compiler have bugs in practice? Of course. Do you - as a developer - have a different safety model than the Rust language (i.e., one that does not include the compiler)? If the answer is no, you can “ignore” compiler bugs from a safety perspective.