3 ms·

One of the main conclusions says: > which aims to make the kernel more secure [...] Contrary to the common belief, our study shows Rust only makes the kernel m

One of the main conclusions says: > which aims to make the kernel more secure [...] Contrary to the common belief, our study shows Rust only makes the kernel more "securable" but not fully secure due to unsafe usage is inevitable in driver development. Okay, but does it make it more secure or not? If yes, is it by a significant amount or not? This feels like it's moving the goal post and so ends up not really answering anything. I don't think anyone believes "fully secure" was ever a possibility, especially given the mix of C and Rust. The more in-depth analysis that follows never answers that question either beyond just "reduces the vast attack space", and it was a genuinely interesting question. I feel cheated out of an an answer.

pornel 2y ago
The answer depends on a still unresolved issue of whether RFL can build usable safe and zero-overhead abstractions around kernel APIs. This work isn't complete, and it's hard to say whether the current issues are from immature integration, or a sign there are fundamental limitations. Rust was able to give safety guarantees where other languages couldn't by forbidding certain code patterns that complicate or break static analysis (ambiguous ownership, unrestricted mutations). Rust also has its own arbitrary design choices such as reserving a right to memcpy structs to a different address. For Rust code written from scratch these limitations are not a big deal. Rust programs pick architectures and design patterns that work with and not against the language. But Linux never had to worry about having statically known ownership of pointers. It could do whatever it wanted with uninitialized memory. It could play with pointers however it wanted. So RFL needs to bend backwards to support design patterns that are not idiomatic Rust. It remains to be seen where the compromise will end up (less safe Rust APIs? or more complex? Not zero-overhead? Maybe the Linux will change its APIs to fit Rust, or maybe Rust will change to help RFL).

pornel 2y ago

The answer depends on a still unresolved issue of whether RFL can build usable safe and zero-overhead abstractions around kernel APIs. This work isn't complete, and it's hard to say whether the current issues are from immature integration, or a sign there are fundamental limitations. Rust was able to give safety guarantees where other languages couldn't by forbidding certain code patterns that complicate or break static analysis (ambiguous ownership, unrestricted mutations). Rust also has its own arbitrary design choices such as reserving a right to memcpy structs to a different address. For Rust code written from scratch these limitations are not a big deal. Rust programs pick architectures and design patterns that work with and not against the language. But Linux never had to worry about having statically known ownership of pointers. It could do whatever it wanted with uninitialized memory. It could play with pointers however it wanted. So RFL needs to bend backwards to support design patterns that are not idiomatic Rust. It remains to be seen where the compromise will end up (less safe Rust APIs? or more complex? Not zero-overhead? Maybe the Linux will change its APIs to fit Rust, or maybe Rust will change to help RFL).