Rust heads into the kernel?
Rust heads into the kernel?
Posted Apr 21, 2021 19:07 UTC (Wed) by wtarreau (subscriber, #51152)In reply to: Rust heads into the kernel? by josh
Parent article: Rust heads into the kernel?
I agree on this.
> But I don't think "another language might hypothetically come along in the future that's even better" is a good argument against adopting a language that's a substantial improvement over the current state, assuming people agree that it's a substantial improvement.
That's not my point. My point is I suspect that a few years from now it will have changed so much to adapt to the real needs that it will be abandonned (except by a few fanboys) and will end up like plenty of previous languages that lasted only a decade.
> I also don't think there's value in maintaining parallel versions of the same code.
If that's the only way to keep people who understand some code parts that could end up being abandoned, there definitely is some value. If it takes a decade to reach the same level of stability or performance as the original ones, it makes sense. If the required toolchains end up being a total mess to deploy in field, it makes sense as well. The new IDE driver probably took a decade to replace the old one and there's nothing wrong with this. As you said, time will tell.
Posted Apr 21, 2021 22:07 UTC (Wed)
by josh (subscriber, #17465)
[Link]
That's certainly a viewpoint one could hold. I can understand where that assumption would come from, given that there have been a large number of languages that thought they could replace C, many of which don't exist anymore. I think Rust specifically fits in a way all of those languages didn't, but rather than try to argue the case for that here, I'll stick with "time will tell", and continue working to make sure the language adapts to the needs of various real users, including kernel developers.
Posted Apr 21, 2021 23:18 UTC (Wed)
by roc (subscriber, #30627)
[Link] (15 responses)
> becoming too tricky to use with all the necessary tricks added to make it suitable for the task
I wonder what you have in mind here. I can't think of any examples of this over the last several years. In fact Rust has become less tricky to use, for example supporting non-lexical lifetimes. Rust community commitment to backwards compatibility is high so even if some new features (const generics, generic associated types?) make the language more complex, you don't have to use them.
Posted Apr 22, 2021 2:54 UTC (Thu)
by wtarreau (subscriber, #51152)
[Link] (14 responses)
> I wonder what you have in mind here. I can't think of any examples of this over the last several years.
I mean that gcc and even C evolved when facing the reality of the linux kernel. When 1 out of 10 lines was in fact an inline function calling an asm statement it shows there were some limitations. I don't see how Rust will avoid this. There will be tons of "unsafe" blocks everywhere making the code very hard to read and preventing the compiler from holding its promises, and I suspect some new constructs will have to be invented to improve this situation, and that the language will be less appealing to newcomers.
Quite frankly, look at Linux's C code. There area tons of READ_ONCE(), likely(), atomic_inc(), smp_rmb(), readb(), iowrite{8,16,32}(), div64_* etc everywhere that rely on asm and need to be applied not directly because of the language but because of the underlying hardware constraints, that make C code less easy to write. I don't see why it wouldn't be the case in another language since it's not a matter of expressing code, but a matter of semantics. What Rust proponents complain about in C will quickly arrive in their language.
Posted Apr 22, 2021 3:55 UTC (Thu)
by Wol (subscriber, #4433)
[Link]
And if Rust forces programmers to step back, and think about their code, and NOT FORGET all of this stuff, then that makes it the better language.
And how much of that stuff, also, is not there because C can't do it natively, but because given the chance the C optimiser will screw things up? How much of that stuff is there to get round undefined or implementation-defined behaviour?
Cheers,
Posted Apr 22, 2021 11:53 UTC (Thu)
by moltonel (guest, #45207)
[Link] (5 responses)
It seems likely that initial kernel Rust code will have more 'unsafe' and less convenience than we can hope for 10 years down the line. If 10% of kernel "C functions" were initially asm, we can expect similar growing pains with Rust. So what ? Nobody is claiming that enabling Rust in the kernel will enable all Rust developers to become kernel developers. The main goal of Rust in the kernel is to make the kernel code better, not to attract Rust fans and newcomers.
Posted Apr 22, 2021 20:11 UTC (Thu)
by wtarreau (subscriber, #51152)
[Link] (4 responses)
Sorry but this is exactly how I understood it: make it easier to write drivers (implicit "for rust developers" as not everyone is fluent in it and even those used to it say the learning curve is pretty steep).
> The main goal of Rust in the kernel is to make the kernel code better, not to attract Rust fans and newcomers.
Better in terms of what ? Maintainability, with only 1% of kernel developers being able to review and fix that code instead of the previous 100% ? Ease of use, with everyone having to install two separate toolchains, some combinations of which will possibly cause trouble that will have to be detected and rejected ? Portability, with a number of existing architectures not even being implemented by the language ? Fame and ego for rust fanboys for having won a victory over Linux, maybe.
Posted Apr 22, 2021 20:36 UTC (Thu)
by josh (subscriber, #17465)
[Link]
We wouldn't be working to enable Rust in the kernel if we didn't think it was an improvement *for the kernel*. The goal is to provide safety and productivity improvements. If you believe that Rust isn't actually achieving those goals, or that it does but that there are other factors outweighing that, by all means you're welcome to make the case for that.
Half your arguments would apply to *any* non-C language, no matter how much of an improvement it would otherwise be. Those arguments would effectively say that the kernel can never consider anything but C, and that "it isn't C" is a factor outweighing other considerations in any language evaluation.
Yes, a new toolchain and a new language has a baseline cost; the only reason Rust is being seriously considered is because *despite* that cost many people still think it'd be an improvement. I have confidence that kernel developers are quite *capable* of using something new, if it's deemed worthwhile. That evaluation, of whether it's actually worthwhile, will be an ongoing process. I'm certain that one of many factors in that evaluation will be "is this not just better, but substantially better, to the point that it's worth the expectation that kernel developers will have to deal with it in the kernel tree". That's a very reasonable question, and it's not one with a pre-determined answer.
Posted Apr 22, 2021 20:38 UTC (Thu)
by mathstuf (subscriber, #69389)
[Link] (1 responses)
Please don't just make up numbers. I wouldn't trust 100% of kernel developers reviewing sched, mm, rcu, or arch code because those domains are way more specific than just "it's C code, I'm a C programmer, I'll be fine". If maintainers of a domain don't want to learn Rust, then don't let it into your corner. Right now, it appears as though it will just be for device drivers. Over time, sure, maybe it'll do more. I don't forsee the wisdom of subsystem maintainers to all of a sudden being untrustworthy if introducing Rust into a corner is not actually ready (no different than any other patch that shows up).
> Portability, with a number of existing architectures not even being implemented by the language ?
The language supports it. The prevailing toolchain doesn't support every arch. There are those working on getting GCC to compile Rust which should resolve this issue.
Posted Apr 22, 2021 22:23 UTC (Thu)
by josh (subscriber, #17465)
[Link]
There's also a project to use GCC as the code-generation backend for the existing frontend (which will avoid code duplication and divergence), as well as efforts to add LLVM backends for more architectures that people care about (there's now an m68k backend, so props to the m68k people for putting forth that effort).
Posted Apr 23, 2021 1:18 UTC (Fri)
by roc (subscriber, #30627)
[Link]
If you think 99% of kernel developers will be unable or uninterested in learning Rust then you have dimmer view of kernel devs than I do.
Posted Apr 22, 2021 13:55 UTC (Thu)
by mss (subscriber, #138799)
[Link] (4 responses)
Full agreement on that.
Which resulted in a hilarious number of recent memory-corruption CVEs for a language that has memory safety as its biggest selling point:
For extra fun try to find mentions of them in the Rust release notes page:
Posted Apr 22, 2021 16:22 UTC (Thu)
by kleptog (subscriber, #1183)
[Link] (2 responses)
That's to be expected though. The standard library provides the abstractions so that the programs using them don't need any unsafe blocks. This works quite well in practice.
I would expect the kernel implementation to be the same. There would be a core that provides the abstractions (containing many unsafe blocks) and the drivers using these abstractions would be without any unsafe blocks. That would be ideal, the question is how close they can get to this goal.
Posted Apr 22, 2021 20:06 UTC (Thu)
by wtarreau (subscriber, #51152)
[Link] (1 responses)
It could very well be that Linux is the last project adopting rust in the end... That's a dangerous move for it.
Posted May 17, 2021 9:06 UTC (Mon)
by tao (subscriber, #17563)
[Link]
To answer your question, yes, it's a lot better to have 100% of the Rust drivers vulnerable because they all use the same function if that means that 100% of the drivers are simultaneously fixed when an issue is remedied in the common library, rather than having each driver have its own implementation.
I know there are people who think static linking and bundling is a good idea, but I certainly don't belong to that camp.
Posted Apr 23, 2021 1:25 UTC (Fri)
by roc (subscriber, #30627)
[Link]
This is a much higher bar than C even attempts to reach. The answer to "which C library APIs can be used to do something unsafe if I write malicious code that uses them?" is "pretty much all of them". It's hardly even a well-formed question.
Posted Apr 23, 2021 1:16 UTC (Fri)
by roc (subscriber, #30627)
[Link] (1 responses)
These are either already available in Rust or can mostly be added as library APIs. No real increase in language complexity or difficulty of writing Rust code.
> What Rust proponents complain about in C will quickly arrive in their language.
The existence of these features is not what "Rust proponents complain about in C".
But atomics and memory-mapped I/O do provide good examples of the deficiencies of C. Rust defines specific types for atomic variables (e.g. AtomicU32) and you *cannot* read or write them with non-atomic operations (without explicitly writing "unsafe"). That eliminates the class of "forgot to use an atomic operation" bugs. Something very similar can be done for memory-mapped I/O registers (and I assume has been for embedded Rust already).
Unfortunately C doesn't provide these guarantees.
Posted Apr 23, 2021 8:31 UTC (Fri)
by farnz (subscriber, #17727)
[Link]
Suitable tricks for MMIO have indeed been implemented by the Rust Embedded people - these tricks exploit the borrow checker to confirm invariants are met. For peripherals with access requirements (e.g. GPIOs, where output drive level is nonsense in input mode), there's also a common state machine pattern in Rust. There's a collection of interesting crates to look at if you want to see what embedded Rust people have done to maximise the benefit from using Rust.
And note that with unsafe you can still write code that has as few guarantees as C - it's just that Rust style encourages you to use a compile-time abstraction (no runtime cost) that turns access mistakes into compile failures.
Rust heads into the kernel?
Rust heads into the kernel?
Rust heads into the kernel?
Rust heads into the kernel?
Wol
Rust heads into the kernel?
Rust heads into the kernel?
Rust heads into the kernel?
Rust heads into the kernel?
Rust heads into the kernel?
Rust heads into the kernel?
Rust heads into the kernel?
It looks like even basic Rust standard library can't be reasonably implemented without a lot of "unsafe" blocks.
> CVE-2020-36317:
> In the standard library in Rust before 1.49.0, String::retain() function has a panic safety problem. It allows creation of a non-UTF-8 Rust string when the provided closure panics. This bug could result in a memory safety violation when other string APIs assume that UTF-8 encoding is used on the same string.
>
> CVE-2021-36318:
> In the standard library in Rust before 1.49.0, VecDeque::make_contiguous has a bug that pops the same element more than once under certain condition. This bug could result in a use-after-free or double free.
>
> CVE-2021-28875:
> In the standard library in Rust before 1.50.0, read_to_end() does not validate the return value from Read in an unsafe context. This bug could lead to a buffer overflow.
>
> CVE-2021-28877:
> In the standard library in Rust before 1.51.0, the Zip implementation calls __iterator_get_unchecked() for the same index more than once when nested. This bug can lead to a memory safety violation due to an unmet safety requirement for the TrustedRandomAccess trait.
>
> CVE-2021-28876:
> In the standard library in Rust before 1.52.0, the Zip implementation has a panic safety issue. It calls __iterator_get_unchecked() more than once for the same index when the underlying iterator panics (in certain conditions). This bug could lead to a memory safety violation due to an unmet safety requirement for the TrustedRandomAccess trait.
>
> CVE-2021-28878:
> In the standard library in Rust before 1.52.0, the Zip implementation calls __iterator_get_unchecked() more than once for the same index (under certain conditions) when next_back() and next() are used together. This bug could lead to a memory safety violation due to an unmet safety requirement for the TrustedRandomAccess trait.
>
> CVE-2021-28879:
> In the standard library in Rust before 1.52.0, the Zip implementation can report an incorrect size due to an integer overflow. This bug can lead to a buffer overflow when a consumed Zip iterator is used again.
>
> CVE-2021-31162:
> In the standard library in Rust before 1.53.0, a double free can occur in the Vec::from_iter function if freeing the element panics.
https://github.com/rust-lang/rust/blob/master/RELEASES.md
Rust heads into the kernel?
Rust heads into the kernel?
Rust heads into the kernel?
Rust heads into the kernel?
Rust heads into the kernel?
Rust heads into the kernel?