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.
The funny part is: the fix does not change the unsafe block at all. The issue is elsewhere in safe rust code.
No. The issue is that an assumption they make in the unsafe block does not actually always hold true. They changed the safe rust code to strenghten the (incorrect) assumption they made in the first place, because that is way easier than rearchitecting the unsafe part. I.e. if the unsafe part was somehow to be written safely, the mitigation they introduced now would not result in any difference in behaviour, it would be correct behaviour both before and after.
Tldr: the problem lies in the unsafe part
I’ll admit, I haven’t looked at the code. I would stand by my comment of the unsafe block being a start point.
Countering that however, what is the difference to just debugging effectively? Not sure. I suppose it’s down to the people that identified it and fixed it at the end of the day to say if there was any benefit.
doesn’t change anything if you can’t avoid having to write the unsafe parts
It certainly does. It’s way simpler to keep up all invariants and to review the few percent lines of code in unsafe blocks than making sure that the 30 million lines of code are free of undefined behavior.
Is some part of the code it battle tested of course it’s complete unreasonable to rewrite it in any language, but if you have to do a major rewrite anyway or write a new component you should definitely use a memory safe language. And no it doesn’t matter that there is an unsafe escape hatch because it’s literally impossible to write low level kernel stuff or FFI to other languages without unsafe because Rust can’t uphold/guarantee the invariants of the hardware itself or the behavior of other languages.
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.
the cloudflare issues were configuration… they have nothing even remotely relayed to any of this
The software had a limit on the size of the feature file that was below its doubled size. That caused the software to fail.
this is not a rust problem… nor was the original problem of code writing entries to a file multiple times, and nor is the thing that made it worse: propagation of the poisoned file
JavaScript would have prevented this.
You’re so right! The Linux kernel should be re-written as a Deno executable
Sucks to be the person who made that commit. Genuinely.
Back luck Brian kernel developer.
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.
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.
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
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[see 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?
