| ▲ | sayamqazi 5 hours ago | |
Pardon my ignorance but I find the claim "removing the nastiest cla ss of security vulnerabilities" to be a bold claim. Is there ZERO use of "unsafe" rust in kernel code?? | ||
| ▲ | vlovich123 4 hours ago | parent | next [-] | |
Aside from the minimal use of unsafe being heavily audited and the only entry point for those vulnerabilities, it allows for expressing kernel rules explicitly and structurally whereas at best there was a code comment somewhere on how to use the API correctly. This was true because there was discussion precisely about how to implement Rust wrappers for certain APIs because it was ambiguous how those APIs were intended to work. So aside from being like 1-5% unsafe code vs 100% unsafe for C, it’s also more difficult to misuse existing abstractions than it was in the kernel (not to mention that in addition to memory safety you also get all sorts of thread safety protections). In essence it’s about an order of magnitude fewer defects of the kind that are particularly exploitable (based on research in other projects like Android) | ||
| ▲ | bmicraft an hour ago | parent | prev | next [-] | |
"Unsafe" rust still upholds more guarantees than C code. The rust compiler still enforces the borrow checker (including aliasing rules) and type system. | ||
| ▲ | bonzini 4 hours ago | parent | prev | next [-] | |
You can absolutely write drivers with zero unsafe Rust. The bridge from Rust to C is where unsafe code lies. | ||
| ▲ | littlestymaar 4 hours ago | parent | prev | next [-] | |
Not zero, but Rust-based kernels (see redox, hubris, asterinas, or blog_os) have demonstrated that you only need a small fraction of unsafe code to make a kernel (3-10%) and it's also the least likely places to make a memory-related error in a C-based kernel in the first place (you're more likely to make a memory-related error when working on the implementation of an otherwise challenging algorithm that has nothing to do with memory management itself, than you are when you are explicitly focused on the memory-management part). So while there could definitely be an exploitable memory bug in the unsafe part of the kernel, expect those to be at least two orders of magnitude less frequent than with C (as an anecdotal evidence, the Android team found memory defects to be between 3 and 4 orders of magnitude less in practice over the past few years). | ||
| ▲ | Ygg2 43 minutes ago | parent | prev [-] | |
It removes a class of security vulnerabilities, modulo any unsound unsafe (in compiler, std/core and added dependency). In practice you see several orders of magnitude fewer segfaults (like in Google Android CVE). You can compare Deno and Bun issue trackers for segfaults to see it in action. As mentioned a billion times, seatbelts don't prevent death, but they do reduce the likelihood of dying in a traffic accident. Unsafe isn't a magic bullet, but it's a decent caliber round. | ||