Linux Kernel Rust Code Sees Its First CVE Vulnerability
Linux Kernel Rust Code Sees Its First CVE Vulnerability
You're viewing a single thread.
49 comments
-
What's the point of rewriting parts of the kernel in unsafe rust?
-
Because Rust lets you choose when something is unsafe vs writing all unsafe in code all the time:
Note the other 159 kernel CVEs issued today for fixes in the C portion of the codebase
-
Yes same concept as other languages like C#
-
You go ahead and write an OS kernel in C# then.
-
Why the hell would you do that
-
Why would you bring up C# in a thread about kernel programming?
-
Talking about how unsafe is not some new fancy rust feature and exists in other languages. Your comment makes it sound like the choice is some new wild computing concept.
-
Memory safe languages that are not garbage collected are not all that common. Ada and Rust are two examples.
With great care C++ and zig can be.
I'm sure there's a good reason a lot of the big players and the community at large have picked up rust though. Docs, error messages, cargo community etc.
I would argue that Rust does bring a lot to the table. I certainly would never code in C for work but I'll happily reach for Rust.
-
Bruh do you actually not get it. The point of rust is that its memory safe(with a huge grain of salt in the case of low level programming) and is a language you can write kernels in. Youre not gonna write a kernel in C# so it doesnt really matter for a discussion about kernels.
-
I think you are lost, nobody is saying use C# for an OS kernel.
-
-
-
-
-
Here, someone already wrote a bare bones one. Of course that also uses an unsafe block lol
-
-
-
I wonder if this can be adjusted for LoC count in each language
-
Not sure if that's a fair metric yet.
-
It's not, I have no better idea
-
Maybe only counting new/edited LoC in that language. But also probably not completely fair.
-
-
-
-
-
it's not like the whole driver is written in unsafe rust
-
Mostly to attract new, younger kernel maintainers.
-
That's legitimately a good reason. They can pry my C from my cold dead hands...but someday someone will have to. May as well think about what that should look like.
-
-
unsafe is usually used only when you need to interact with something else like low level or ffi
-
Because Rust is the popular thing in FOSS/Linux at the moment.
-
For memory safety, which is not unsafe rust
-
You say that. But the CVE is a memory corruption bug.
-
Which is worse?
- Entire driver written in a non memory safe language?
- The interface to the rest of the kernel is marked as unsafe and then the other X percent is safe from memory corruption?
Surely if X > 0 then this is still a net improvement?
-
I don't know, but I found this article interesting with respect to unsafe Rust - https://lightpanda.io/blog/posts/why-we-built-lightpanda-in-zig
-
After writing this comment I noticed it became a bit ranty, sorry for that. Something about this article rubbed a bit in the wrong way.
The relevant section seems to be this:
Browser engines and garbage-collected runtimes are classic examples of code that fights the borrow checker. You’re constantly juggling different memory regions: per-page arenas, shared caches, temporary buffers, objects with complex interdependencies. These patterns don’t map cleanly to Rust’s ownership model. You end up either paying performance costs (using indices instead of pointers, unnecessary clones) or diving into unsafe code where raw pointer ergonomics are poor and Miri becomes your constant companion.
The first half is obviously correct, this kind of data model doesn't work well for the ownership model rust uses for its borrowchecker. I don't like the conclusion though. Rust makes you pay the performance costs necessary to make your code safe. You would need to pay similar costs in other languages if you intend on writing safe code.
Sure, if you are fine with potential memory corruption bugs, you don't need these costs, but that's not how I would want to code.
The other thing bugging me is how miri being your companion is framed as something bad. Why? Miri is one the best things about rusts unsafe code tooling. It's like valgrind, or sanitisers but better.
Now, the raw pointer ergonomics could be better, I'll give them that. But if you dive deep into what rust does with raw pointers, or rather what they are planning to do, is really really cool. Provenance and supporting cheri natively is just not possible for languages that chose the ergonomic of a raw integer over what rust does.
-
-
They’re not calling Rust unsafe. There is a memory safe mode and a memory unsafe mode in Rust, and this was built in unsafe Rust which allowed for the memory bug to be exploited
-
You don't understand what unsafe means
-
Rust by default will not allow you to make certain kinds of errora, which is great. But if you are doing something advanced,
down at the hardware levelsee below, you might need to disable those defaults in order to write the code you need. This is what people mean by "unsafe" -- lacking the normal memory safeguards.With careful coding, "unsafe rust" or normal C, for that matter, can be free of bugs and safe. But if programmers make a mistake, vulnerabilities can creep in more easily in the unsafe sections.
Is that basically it?
-
But if you are doing something advanced, down at the hardware level
This part is wrong. Otherwise yes correct.
The “unsafe” code in rust is allowed to access memory locations in ways that skip the compiler’s check and guarantee that that memory location has valid data. They programmer is on their own to ensure that.
Which as you say is just the normal state of affairs for all C code.
This is needed not because of hardware access but just because sometimes the proof that the access is safe is beyond what the compiler is able to represent.
-
Thank you for the correction, I'll edit my comment.
sometimes the proof that the access is
safe is bevond what the compiler is able to represent
Could you say a few more words about this? In what situations do you have to write 'unsafe-tagged' code blocks? Could this be changed by improvements to the compiler? Or is it necessitated by the type of task being done by the code?
-
Check out the excellent tutorial # Learn Rust With Entirely Too Many Linked Lists especially chapters five and six. It has a lot more words, it’s entertaining, engaging, and informative.
-
-
-
-
-
-
-
-
49 comments