3 ms·
Not sure about the exact official stance, but can't imagine it's anything other than eventually fixing all soundness bugs, at least as long as someone is willin
by devit 7y ago
Not sure about the exact official stance, but can't imagine it's anything other than eventually fixing all soundness bugs, at least as long as someone is willing to do the work.
However, an important thing to note is that Rust strives to be safe only against unintentional bugs, and not against intentional malicious code (against which you are supposed to use OS/CPU-level sandboxing), so unsoundness issues that are very unlikely to be accidentally triggered aren't necessarily a very high priority.
This is a reasonable policy, since current Rust does not have a certified provably correct compiler and Rust programs in current practice don't come with formal proofs, so full provable soundness in type system doesn't really translate to any useful properties, since programs can intentionally fail to do what they are supposed to do in other ways (just do something safe but malicious or incorrect or exploit bugs in rustc or LLVM).
For instance, this issue is very unlikely to be triggered by non-malicious code, so emergency action to fix it is not being taken, and instead it will probably be fixed only once there is clear consensus on the best fix.
- zozbot234 7y agoThe line between "unintentional" bugs and "intentional/malicious" escape hatches is quite fuzzy given the extent that most Rust projects rely on outside code. Soundness bugs, at least in stable rust, are serious and should be addressed as such, or Rust developers will end up with a leftpad situation as soon as a popular third-party crate 'unintentionally' introduces some sort of soundness concern.
- devit 7y agoThird party crates can include malicious safe code that doesn't exploit any soundness bugs, so I'm not sure how exploiting soundness bugs could make the situation worse. It's only a problem if you try to restrict I/O APIs and use the Rust type system as a security boundary, which is something that I don't think anyone does and that should not be done since the surface area is too vast to secure without formal proofs of the whole Rust stack, which are too time-consuming to produce with current technologies.
- __s 7y agohttps://www.tockos.org https://www.tockos.org does what you think nobody does
- dethinking 7y agoTIL, and since it’s buried a bit: > A capsule is a Rust struct and associated functions. Capsules interact with each other directly, accessing exposed fields and calling functions in other capsules. Trusted platform configuration code initializes them, giving them access to any other capsules or kernel resources they need. Capsules can protect internal state by not exporting certain functions or fields. > ... > Rust’s language protection offers strong safety guarantees. Unless a capsule is able to subvert the Rust type system, it can only access resources explicitly granted to it, and only in ways permitted by the interfaces those resources expose. However, because capsules are cooperatively scheduled in the same single-threaded event loop as the kernel, they must be trusted for system liveness. If a capsule panics, or does not yield back to the event handler, the system can only recover by restarting. I take it from the present discussion that that might not be as good of an idea as they think. Worth noting that they also have process isolation on top, but it doesn’t seem to be motivated by any potential insecurity of the type system.
- staticassertion 7y agoI don't get how that's ever possible, regardless of soundness issues. Can you not simply use unsafe in a capsule, and violate this constraint? The only way isolates in V8 manage to provide any isolation is because the runtime/ language forbid such things entirely. I suspect it is not so simple as "Rust's safety ensures malicious rust code can't access data".
- __s 7y agoCapsules aren't allowed to use unsafe. The target of tock is not generally going to be out of order, so spectre things shouldn't occur
- TheCoelacanth 7y agoStealing credit card numbers, displaying adware and launching missiles are all safe Rust. Rust does not offer any protection against malicious code and it does not claim to. It offers protection against malicious input to non-malicious code, but no protection against malicious code itself.