- cross-posted to:
- linux@programming.dev
- hackernews
- cross-posted to:
- linux@programming.dev
- hackernews
You must log in or register to comment.
No one said rust was invulnerable.
I think the other takeaway here is that it was found in a section marked “unsafe”. At the very least, that’s a useful tool for the Devs to isolate potential problem areas. Comparing that to a pure C codebase where the problem could be anywhere.
Boone? There are plenty of fan boys out there that are selling rust like AI, or in other words snake oil.
Rust obviously has built in securities that C doesn’t have, but a shitty coder is a shitty coder and bad QC is bad QC. Now we’re seeing the reality of the consequences.
Rust and/or other memory safe® languages are like the future, but hopefully more people are now seeing the cracks. Just look at cloudflare for a prime example.
Sucks to be the person who made that commit. Genuinely.
Surprised it took so long.
almost as if using a memory safe language actually reduces the CVEs related to memory
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.
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
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 level, 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.
