Comment by dfawcus
3 days ago
The impression I get from simply reading these various discussions, is that some folks are not convinced that the pain from accepting Rust is worth the gain.
Possibly also that a significant portion of the suggested gain may be achievable via other means.
i.e. bounds checking and some simple (RAII-like) allocation/freeing simplifications may be possible without rust, and that those are (from the various papers arguing for Rust / memory safety elsewhere) the larger proportion of the safety bugs which Rust catches.
Possibly just making clang the required compiler, and adopting these extension may give an easier bang-for-buck: https://clang.llvm.org/docs/BoundsSafety.html
Over and above that, there seem to be various complaints about the readability and aesthetics of Rust code, and a desire not to be subjected to such.
> Possibly also that a significant portion of the suggested gain may be achievable via other means.
Things like that have been said many times, even before Rust came around. You can do static analysis, you can put in asserts, you can use this restricted C dialect, you can...
But this never gets wider usage. Even if the tools are there, people are going to ignore them. https://en.wikipedia.org/wiki/Cyclone_(programming_language) started 23 years ago...
It took us decades to get to non executable stack and W^X and there are still occasional issues with that.
I think it's because C devs often think that they never make a mistake, so they see rust bringing on value.
I had an argument about rust with a freebsd developer that had the same "I never make a mistake" attitude. I've made a PR to his project that fixes bugs that weren't possible in rust to being with. Not out of petty, but because his library was crashing my application. In fact, he tried to blame my rust wrapper for it when I raised an issue.
I have definitely done such things out of pettiness. Sometimes people just attract your attention as deserving of an attempt to humble them. I hope people will humble me as well when my vociferousness outstrips my talent. It's good to be sent directly back to home every now and then.
What i don't get is why people gravitate toward trying to show off how many symbols they're able to manipulate in their brain without screwing something up.
It's a computer. It does what it was instructed to do, all 50 million or so of them. To think you as a puny human have complete and utter mastery over it is pure folly every single time.
As time goes on I become more convinced that the way to make progress in computing and software is not with better languages, sure, those are very much appreciated, since language has a strong impact on how you even think about problems, but it's more about tooling and how we can add abstractions to the software to leverage the computer we already got to alleviate the eye gouging complexity of trying to manage it all by trying to predict how it will behave with our pitiful neuron sacs.
1 reply →
> The impression I get from simply reading these various discussions, is that some folks are not convinced that the pain from accepting Rust is worth the gain.
Read the above email. Greg KH is pretty certain it is worth the gain.
> Possibly also that a significant portion of the suggested gain may be achievable via other means.
I think this is a valid POV, if someone shows up and does the work. And I don't mean 3 years ago. I mean -- now is as good a time as any to fix C code, right? If you have some big fixes, it's not like the market won't reward you for them.
It's very, very tempting to think there is some other putatively simpler solution on the horizon, but we haven't seen one.
> Over and above that, there seem to be various complaints about the readability and aesthetics of Rust code, and a desire not to be subjected to such.
No accounting for taste, but I don't think C is beautiful! Rust feels very understandable and explicit to my eye, whereas C feels very implicit and sometimes inscrutable.
> Read the above email. Greg KH is pretty certain it is worth the gain.
I don't think GP or anyone is under the impression that Greg KH thinks otherwise. He's not the "some folks" referred here.
> I don't think GP or anyone is under the impression that Greg KH thinks otherwise. He's not the "some folks" referred here.
Glad for your keen insights.
> The impression I get from simply reading these various discussions, is that some folks are not convinced that the pain from accepting Rust is worth the gain. [..] Possibly also that a significant portion of the suggested gain may be achievable via other means.
Sure, but opinions are always going to differ on stuff like this. Decision-making for the Linux kernel does not require unanimous consent, and that's a good thing. Certainly this Rust push hasn't been handled perfectly, by any means, but I think they at least have a decent plan in place to make sure maintainers who don't want to touch Rust don't have to, and those who do can have a say in how the Rust side of their subsystems look.
I agree with the people who don't believe you can get Rust-like guarantees using C or C++. C is just never going to give you that, ever, by design. C++ maybe will, someday, years or decades from now, but you'll always have the problem of defining your "safe subset" and ensuring that everyone sticks to it. Rust is of course not a silver bullet, but it has some properties that mean you just can't write certain kind of bugs in safe Rust and get the compiler to accept it. That's incredibly useful, and you can't get that from C or C++ today, and possibly not ever.
Yes, there are tools that exist for C to do formal verification, but for whatever reason, no one wants to use them. A tool that people don't want to use might as well not exist.
But ultimately my or your opinion on what C and C++ can or can't deliver is irrelevant. If people like Torvalds and Kroah-Hartman think Rust is a better bet than C/C++-based options, then that's what matters.
If you look at the CVE lists, about 70-80% of all c memory bugs are related to OOB Read and Write. Additionally, like rust, fbounds-safety can remove redundant checks if it can determine the bounds. My question is how likely can it be adopted in the kernel (likely high).
I will need to read their conversations more to see if it's the underlying fear, but formalization makes refactoring hard and code brittle (ie. having to start from scratch on a formal proof after substantially changing a subsystem). One of the key benefits of C/Kernel have been their malleability to new hardware and requirements.
> My question is how likely can it be adopted in the kernel (likely high).
My guess is, it cannot. The way -fbounds-safety works, as far as I understand, is that it aborts the program in case of an out-of-bounds read or write. This is similar to a Rust panic.
Aborting or panicking the kernel is absolutely not a better alternative to simply allowing the read/write to happen, even if it results in a memory vulnerability.
Turning people's computer off whenever a driver stumbles on a bug is not acceptable. Most people cannot debug a kernel panic, and won't even have a way to see it.
Rust can side-step this with its `.get()` (which returns an Option, which can be converted to an error value), and with iterators, which often bypass the need for indexing in the first place.
Unfortunately, Rust can still panic in case of a normal indexing operation that does OOB access; my guess is that the index operation will quickly be fixed to be completely disallowed in the kernel as soon as the first such bug hits production servers and desktop PCs.
Alternatively, it might be changed to always do buf[i % buf.size()], so that it gives the wrong answer, but stays within bounds (making it similar to other logic errors, as opposed to a memory corruption error).
Yes, panicking in kernels is bad. I've followed the whole R4L fight about working around it.
https://github.com/apple-oss-distributions/xnu/blob/main/doc...
https://github.com/apple-oss-distributions/xnu/blob/main/doc...
Upstream fbounds in xnu has options for controlling if it panics or is just a telemetry event. They are in a kernel situation and have the exact same considerations on trying to keep the kernel alive.
2 replies →
Here are some Linus's thoughts on why security hardening efforts should never break the program: https://lkml.org/lkml/2017/11/21/356
1 reply →
For GCC I have a patch (maybe 10 lines of code) that emits a warning whenever the compiler inserts a trap. You could use a sanitizer, i.e. bounds checking or signed overflow, add code that turns the warning into an error, and so ensure that your code does not have a signed overflow or OOB.
4 replies →
So out of bounds access leading to data loss and possible security vulnerability is better than crashing the kernel? That doesn't make sense to me.
4 replies →
the problem is that Rust sucks the air out of the programming ecosystem because its proponents throw down the safety hammer, and research on other safe alternatives is slow. we do have an alternative low level memory safe language (Ada) but for whatever reason that's a nonstarter... there's no compelling reason that rust has to be the only way to achieve memory safety (much less in the OS domain where for example you don't have malloc/free so rust's default heap allocation can't be trivially used).
it might do to wait until some other memory safe alternative appears.
Linus doesn't like ADA much, and the talent pool is FAR smaller and also FAR older on average. The compelling reason to use Rust over other languages is precisely that it hit escape velocity where others failed to do so, and it did that partially by being accessible to less senior programmers.
And I don't understand how you can go from opining that Rust shouldn't be the only other option, to opining that they should have waited before supporting Rust. That doesn't make sense unless you just have a particular animus towards Rust.
yeah i do! rust does a lot of things right but protocols and proc macros are awful, as is raii.
3 replies →
> there's no compelling reason that rust has to be the only way to achieve memory safety
I don't think anyone is saying that Rust is the only way to achieve that. It is a way to achieve it, and it's a way that enough people are interested in working on in the context of the Linux kernel.
Ada just doesn't have enough developer momentum and community around it to be suitable here. And even if it did, you still have to pick one of the available choices. Much of that decision certainly is based on technical merits, but there's still enough weight put toward personal preference and more "squishy" measures. And that's fine! We're humans, and we don't make decisions solely based on logic.
> it might do to wait until some other memory safe alternative appears.
Perhaps, but maybe people recognize that it's already late to start making something as critical as the Linux kernel more safe from memory safety bugs, and waiting longer will only exacerbate the problem. Sometimes you need to work with what you have today, not what you hope materializes in the future.
> research on other safe alternatives is slow
It's slow because the potential benefits are slim and the costs of doing that research are high. The simple reality is that there just isn't enough funding going into that research to make it happen faster.
> there's no compelling reason that rust has to be the only way to achieve memory safety
The compelling reason is that it's the only way that has worked, that has reached a critical mass of talent and tooling availability that makes it suitable for use in Linux. There is no good Rust alternative waiting in the wings, not even in the kind of early-hype state where Rust was 15 years ago (Zig's safety properties are too weak), and we shouldn't let an imaginary better future stop us from making improvements in the present.
> it might do to wait until some other memory safe alternative appears.
That would mean waiting at least 10 years, and how many avoidable CVEs would you be subjecting every Linux user to in the meantime?
> The compelling reason is that it's the only way that has worked
because it's hard enough that people don't try. and then they settle for rust. this is what i mean by "rust sucks the air out of the room".
however, its clearly not impossible, for example this authors incomplete example:
https://github.com/ityonemo/clr
> That would mean waiting at least 10 years,
what if it's not ten years, what if it could be six months? is or worth paying all the other downstream costs of rust?
youre risking getting trapped in a local minimum.
2 replies →
> for whatever reason that's a nonstarter... there's no compelling reason
Before rejecting a reason you at least have to know what it is!
ok... what's the compelling reason why rust's strategy has to be the only way to achieve memory safety?
i think some people would argue RAII but you could trivially just make all deacquisition steps an explicit keyword that must take place in a valid program, and have something (possibly the compiler, possibly not) check that they're there.
23 replies →
After all the Ada threads last week, I read their pdf @ Adacore's site (the Ada for Java/C++ Programmers version), and there were a lot of surprises.
A few that I found: logical operators do not short-circuit (so both sides of an or will execute even if the left side is true); it has two types of subprograms (subroutines and functions; the former returns no value while the latter returns a value); and you can't fall through on the Ada equivalent of a switch statement (select..case).
There are a few other oddities in there; no multiple inheritance (but it offers interfaces, so this type of design could just use composition).
I only perused the SPARK pdf (sorry, the first was 75 pages; I wasn't reading another 150), but it seemed to have several restrictions on working with bare memory.
On the plus side, Ada has explicit invariants that must be true on function entry & exit (can be violated within), pre- and post- conditions for subprograms, which can catch problems during the editing phase, and it offers sum types and product types.
Another downside is it's wordy. I won't go so far as to say verbose, but compared to a language like Rust, or even the C-like languages, there's not much shorthand.
It has a lot of the features we consider modern, but it doesn't look modern.
> logical operators do not short-circuit (so both sides of an or will execute even if the left side is true)
There are two syntaxes: `and` which doesn't short circuit, and `and then` which does. Ditto for `or` and `or else`.
3 replies →
> you can't fall through on the Ada equivalent of a switch statement (select..case).
C is actually more of an odd one here, and the fallthrough semantics is basically a side effect of it being a glorified computed goto (with "case" being literally labels, hence making things like Duff's device a possibility). Coincidentally, this is why it's called "switch", too - the name goes back all the way to the corresponding Algol-60 construct.
> the readability and aesthetics of Rust code
I've been writing C/C++ code for the last 16 years and I think a lot of mental gymnastics is required in order to call C "more readable" than Rust. C syntax is only "logical" and "readable" because people have been writing it for the last 60 years, most of it is literally random hacks made due to constraints ({ instead of [ because they thought that array would be more common than blocks, types in front of variables because C is just B with types, wonky pointer syntax, ...). It's like claiming that English spelling is "rational" and "obvious" only because it's the only language you know IMHO.
Rust sure has more features but it also way more regular and less quirky. And it has real macros, instead of insane text replacement, every C project over 10k lines I've worked on has ALWAYS had some insane macro magic. The Linux kernel itself is full of function-like macros that do any sort of magic due to C not having any way to run code at compile-time at all.
> The impression I get from simply reading these various discussions, is that some folks are not convinced that the pain from accepting Rust is worth the gain.
You're correct that there is a honest-to-god split of opinion by smart people who can't find a consensus opinion. So it's time for Linus to step up and mandate and say "discussion done, we are doing x". No serious organization of humans can survive without a way to break a deadlock, and it seems long past the time this discussion should have wrapped up with Linus making a decree (or whatever alternative voting mechanism they want to use).