|
|
|
|
|
|
by t8sr
1236 days ago
|
|
|
If you want to understand how it might be motivated by security, just read the LKML threads around Rust - the Rust developers’ claims are at times pretty wild, and in my experience (after 20 years in infosec), they tend to have a relatively narrow view of “safe”. I am expecting new vulnerabilities to pop up from developer’s misunderstanding of what Rust actually guarantees, especially in the same memory space as the kernel. On top of that, Rust implies a huge new bundle of complexity, a second compiler to have bugs in, and a new software supply chain to attack. The language is extremely complex compared to C. These are not easily dismissible problems. While Rust is definitely a step up from C++ in embedded, I am not convinced bolting it onto existing kernels will fix more potential CVEs than it will cause. |
|
|
The project could start moving critical software to Rust. They could even write their own crates for this purpose, or fork others’ crates to rule out supply chain attacks.
None of this would be unprecedented for the OpenBSD project. They have forked Apache, OpenSSL, they maintain their own SSH client and server. What would be new is that now all of this would not be happening in C but in another language.
Edit: I don’t even think that the above has to be done in Rust. It could be done in any other modern language. But you also mention the complexity of Rust. In what way do you see it as an infosec problem?
To me it appears that the complexity of Rust is good. The limitations that the language puts on your code give you pain before compilation, not afterwards. It makes you do work that avoids certain kinds of memory and logic bugs.