45 ms·

Rust in the 6.2 kernel

253 points by biorach 4y ago

biorach 4y ago
> The merge window for the 6.1 release brought in basic support for writing kernel code in Rust — with an emphasis on "basic". It is possible to create a "hello world" module for 6.1, but not much can be done beyond that. There is, however, a lot more Rust code for the kernel out there; it's just waiting for its turn to be reviewed and merged into the mainline. Miguel Ojeda has now posted the next round of Rust patches, adding to the support infrastructure in the kernel.
tux3 4y ago
If I'm writing my own out of tree Rust module (for the sole purpose of fun), I wonder how hard it would be to bring in external no-std crates? Rust as a language feels unusually high level for something running in kernelspace, although it never really sacrifices any control. But I wonder how far we can reasonably go in making kernelspace feel like userspace, by importing more of the language's 'vocabulary types', and maybe a few of the best utility crates for comfort. But besides people having fun out of tree, the kernel has plenty of fundamental complexity that can't very well be reduced. That tends to be the good complexity, the meat of it. What I would like to see is things that aren't essential complexity becoming nicer. Simple cultural things like better error messages when the tooling fails, or documentation becoming more common rather than the exception. None of this is guaranteed to magically happen just because there's a bit of infrastructure where Make can call rustc. But here's to hoping =)
- gmadsen 4y ago
  if I was curious, what would be a couple of the good complexities?
  - mikepurvis 4y ago
    Not the OP, but I would assume that necessary complexity is at least where the complexity mirrors whatever real world complexity it is implementing, thinking particularly of protocol stacks like usb, networking, etc.
  - tux3 4y ago
    Depends on what kind of problems you you find interesting, but since it's so close to the metal, and since people want their kernel to be fast, there tends to be a lot of clever algorithms, intricate locking, architecture-specific considerations, dealing with the hardware, all sorts of pretty interesting things you wouldn't usually find in regular business logic. Take filesystem code for example. It can sound like a conceptually simple and well trodden topic, but if you try writing one there's a pretty large design space and tons of interesting problems to try to solve. And then because of concurrency and the need for performance, there can be very intricate locking to the point it can be challenging to hold the whole model in your head all at once (you can have truncates, writes, mmap, all sorts of very different operations in flight in parallel that interract in funny ways). Or memory models. Reading memory-barriers.txt is a lesson in humility, I believe you can count on your fingers and toes the number of people in this world who can truly claim intimate familiarity with all the corner-cases and details implied by the model in that little text file =) But take practically any big subsystem of the kernel, and there tends to be plenty of interesting domain-specific problems and challenges.
  - quirino 4y ago
    I believe they're referring to the essential complexity of the domain. An operating system has some "lower bound" on how complex it can be, which is rather high. But some stuff doesn't _have_ to be hard. Like OP said, there's no inherent reason for error messages and failures to be cryptic or documentation to be sparse. The system could be more transparent or modular, easier to debug/analyze, etc. I think there's an example in GCC vs Clang here, but I'm not qualified to comment.
- biorach 4y ago
  This is more a question of policy than mechanism - I'd imagine at least a provisional policy is in place, but the only to be found somewhere in the relevant kernel mailing lists.
- consp 4y ago
  > I wonder how hard it would be to bring in external no-std crates Wasn't this a thing that would not happen at all? at least that is what I remember from previous discussions. Another question would be how do you avoid an explosion of crates with different versions for each module.
  - danhor 4y ago
    Policy decisions for linux itself don't (necessarily) apply out-of-tree modules?
- kibwen 4y ago
  Not a kernel hacker, but if it's just for fun, I don't know if you'd need to limit yourself to no_std crates. Allocation is supported (if it wasn't, then Rust's stdlib wouldn't be adding fallible allocation APIs to support the kernel usecase (and even if crates in the wild aren't using these APIs and abort on OOM, again, this is just for fun)). Meanwhile, I feel like OS-specific stuff performed by libstd (e.g. threads, networking) must surely be supportable somehow, since the OS is right there and all its facilities still exist, even if you might need to adjust codegen to account for the difference between kernelspace and userspace (I assume you would need to compile against a specific target?).
  - tialaramex 4y ago
    Although Rust for Linux has its own alloc, that isn't really alloc. It is like if you wanted Coke and got Pepsi, if you just wanted fizzy brown beverage you're fine, but if you actually cared this isn't OK. Rust's String (the mutable owned string type from alloc) implements AddAssign meaning you can write fname += ".txt" and that works, but Rust for Linux doesn't allow that. This is just a really obvious example, there are many other differences
  - nextaccountic 4y ago
    You can't use methods that may panic on OOM like Vec::push or Box::new. This means that close to 100% of crates that use the stdlib won't be usable in the kernel without modifications.
    - mcronce 4y ago
      My understanding isn't that you _can't_, but that you _aren't allowed to_ by kernel policy. (The risk being that the kernel will panic on OOM, which is not an acceptable way for the kernel to deal with OOM conditions.) If this is out of tree, AFAIK you can use these all you want. Whether or not you _should_ is obviously a different matter.
      - tialaramex 4y ago
        No, you can't - they don't exist in Rust for Linux. In Rust the alloc library's Vec has a function Vec::push(&mut self, value: T) https://doc.rust-lang.org/std/vec/struct.Vec.html#method.push https://doc.rust-lang.org/std/vec/struct.Vec.html#method.pus... In Rust for Linux their custom alloc library does not have that function offering instead Vec::try_push(&mut self, value: T) -> Result<(), TryReserveError> https://rust-for-linux.github.io/docs/alloc/vec/struct.Vec.html#method.try_push https://rust-for-linux.github.io/docs/alloc/vec/struct.Vec.h...
- G4E 4y ago
  Having third party crates in ring 0 is kind of terrifiying when you think about supply chain attacks...
  - kibwen 4y ago
    So few people actually do their development/testing in truly-sandboxed environments that I don't think that there's actually much of a difference in practice between malicious code running in userspace vs malicious running in kernelspace ( https://xkcd.com/1200/ https://xkcd.com/1200/ ). Of course, I'd love if sandboxed dev environments became more usable and widespread.
  - rowanG077 4y ago
    I would never expect them to do that without vendoring the package. Which mitigates that risk.
  - esarbe 4y ago
    They don't use cargo.
- sanxiyn 4y ago
  I expect it to be possible in near future that you develop, say, a web server in Rust in userspace, and with a few changes run it in kernelspace, with improved performance.
  - ilovecaching 4y ago
    We already have eBPF.
    - intelVISA 4y ago
      io_uring too
  - tga_d 4y ago
    Running things in kernel space doesn't make them faster.
    - insanitybit 4y ago
      It can absolutely make things faster. If your program is running on data that exists in the kernel you don't need to copy it over to userland/ perform expensive context switching.
      - tga_d 4y ago
        It can make things faster is not the same as simply running it in the kernel will make it faster. There are definitely certain situations that making use of fewer context switches helps with, and where page mapping isn't sufficient, but if you just write an entire user-space web server, then just compile it as a kernel module, expecting it to see a notable performance improvement, you're going to be disappointed. edit to clarify: the reason it won't help (much) is because most of the things it would help with have already been optimized via features like CoW pages, the VDSO, sendfile, etc.
        insanitybit 4y ago
- LAC-Tech 4y ago
  although it never really sacrifices any control. It feels like it sacrifices control wrt when you allocate and free-memory. I understand it's deterministic in rust, but it's not explicitly controllable - or at least I've seen it be.
  - loeg 4y ago
    You have to bring your own memory in no-std. Implicit alloc is provided by the alloc crate (part of std).
  - Others 4y ago
    I don’t follow. It’s exactly like C in this regard, except with Box::new instead of malloc.
    - conradev 4y ago
      The key difference as outlined in the article is that Box::new cannot fail in Rust, but the underlying malloc can. In userspace it is rare enough that a Rust panic is considered acceptable behavior, but this is not the case for the kernel. But, it is controllable for sure
      - tialaramex 4y ago
        Unsurprisingly the kernel's Box does not have Box::new it provides instead Box::try_new which is fallible.
  - kaba0 4y ago
    Rust is a manual memory managed language, it literally has nothing inexpressible that C could do. Hell, C is a “higher level” language in that it doesn’t have any way for SIMD instructions. To add something concrete, you can manually free memory as well based on some dynamic property if you wish.
ilovecaching 4y ago
I think bringing Rust into Linux was a really bad idea. IMO Rust has yet to prove it isn’t another overly complicated C++ waiting to make projects almost incomprehensible to understand. It does not provide the same easy ramp up that C provided when working on most of the system software stack on Linux. There’s also still too few standalone projects using it to consider it a proper candidate for folding into such a large project forever. I am surprised Linus agreed to this given that he doesn’t like C++ and usually errs on the side of clear over clever, and we have yet to see tangible benefits of using Rust.
- sedeki 4y ago
  I have worked as a C++ dev, but am definitely not a C++ expert by any means. My take however is that C++ is inherently a complex language due to deliberately not sacrificing backwards-compatability of the syntax and semantics, which has been creating a mess as the language has evolved: there are many, many things to define semantically in order to "fit" a new piece in this old already-elaborate puzzle that is the C++ standard. You cannot say the same thing about Rust. Please correct me if you see things differently.
  - noselasd 4y ago
    > You cannot say the same thing about Rust. At least not yet. My fear is it's _very_ easy to fall in to the same trap as C++ has, and become a big mess. Scott Meyers have a very nice talk here: https://www.youtube.com/watch?v=KAWA1DuvCnQ https://www.youtube.com/watch?v=KAWA1DuvCnQ about all these traps and pifalls that we have to deal with in C++. That said, I'm starting a bit with rust and enjoy it so a lot, especially the tooling alone is worth it - and if I never have to write another line of C++, I would be very happy (ofc the real world argues I have a lot of C++ code that will need maintenance).
    - cassepipe 4y ago
      When I tried Rust I came from Python and it was clearly too much for me to comprehend but after 2 years of C programming and 1 year of C++ programming, the problem Rust tries to solve make a lot more sense and I know understand the problem it's trying to solve. I am trying to use it again things like the borrow checker and Traits now make a lot of sense to me. I am also looking forward at not having to write C++ again. I haven't looked into C++17 and beyond though I must admit.
oxff 4y ago
Genuinely did not expect this to happen, a feature of not only software engineering, but management and organization too to make it happen.
jrimbault 4y ago
I'm really happy about the inclusion of Rust in the linux kernel. Not because it is Rust but because it shows that we can evolve. And I hope in a thousand years we aren't still stuck on C or Rust but "moved on" to even better things. It would make me quite hypothetically sad if in a thousand years we were still using tools designed by hackers in the infancy of computer science.
- ArcMex 4y ago
  >As can be seen, these patches are slowly building the in-kernel Rust code up so that real functionality can be implemented in Rust, but this process has some ground to cover yet. It's not clear whether more Rust code will be proposed for 6.2, or whether this is the full set. The pace of change may seem slow to developers who would like to start doing real work in Rust, but it does have the advantage of moving in steps that can be understood — and reviewed — by the kernel community. The Rust-for-Linux work has been underway for a few years already; getting up to full functionality may well take a while longer yet. Me too, I agree.
- ilovecaching 4y ago
  I'm really tired of the cargo culted idea that Rust is a silver bullet and C hasn't evolved since the 1970s. Neither of those things are true. The vast majority of people spouting opinions on Rust don't even write systems software, and have never even compiled a kernel driver. Linux, systemd, grub are all written in C and continue to have fewer flaws than trivial userland applications that allow for privilege escelation. The kernel core is incredibly high quality C, and time would be better spent working on the actual kernel security model. Dennis Ritchie himself wrote a paper about the deficiencies of the Unix security model which was designed for a trusting and shared computing environment. But of course updating the API surface isn't as sexy as writing in a new cool programming language. Cargo culting this notion that Rust is good because it is a security silver bullet is both ignorant AND dangerous because it moves the focal point away from the areas that actually need work to make Linux more secure. It's also completely asinine to assume that poorly written Rust will have fewer flaws than expertly written C that has been vetted for literally decades. Iterative improvement has ALWAYS been the answer over throw everything away and start fresh. C tooling has gotten better over the decades, the C standard has evolved, and people will continue to successfully write secure and performant applications in C. Edit: Also are you upset that people still use hammers in 2022? I guess if we aren't throwing away all of our tools instead of improving on their design we aren't really seeing any *Progress*
Wowfunhappy 4y ago
What does the relatively slow pace of Rust integration mean for the Apple Silicon GPU driver, which appears to be largely functional at this point but is written in Rust? Will the developers have to maintain a separate kernel branch with more robust Rust support for an extended period?
- sanxiyn 4y ago
  Yes. I don't think pace is slow. I am actually surprised how fast it is going. Code review is a good practice, and I think Rust patches are being reviewed nearly as fast as possible.
  - Wowfunhappy 4y ago
    > I don't think pace is slow. I am actually surprised how fast it is going. Just to be clear, I agree--"relative" is the key word! It is slow if you're currently using Rust to develop a driver.
phendrenad2 4y ago
Now taking bets on how long until we can point to one subsystem or module in the kernel that's written in Rust. I'm betting 3 more years.
- yjftsjthsd-h 4y ago
  Hopefully not before they've sorted out the architecture support. It's fine to write drivers that only target one platform in a compiler that only targets that platform, but core systems need to be able to run on all the CPU architectures that Linux supports, which I understand is still a superset of the ones that rust supports.
- pjmlp 4y ago
  Enjoy the bluetooth stack, written in Rust, since Android 12. https://android.googlesource.com/platform//system/bt/+/83498aa554aea220fcff30b6310a0a7b4557969f/gd/rust https://android.googlesource.com/platform//system/bt/+/83498...
  - phendrenad2 4y ago
    Oh, nice. I wonder how much work it would be to get that working on desktop Linux.
wly_cdgr 4y ago
I am growing closer to being convinced that Rust is here to stay and will actually become the main systems programming language of the next few decades.
- deleted 4y ago
  [deleted]
- throwaway894345 4y ago
  I think there's a couple of compatible perspectives that are both correct but often framed as mutually exclusive: 1. Rust will become the main language for new projects 2. There will still be an enormous amount of C that will be maintained for many decades and the majority of "lines of (systems) code" will be C rather than Rust for decades
titzer 4y ago
This is a good development and shows that there is appetite to move on to new, safer languages. What would be even better, IMHO, would be to bring full software fault isolation (SFI) into the kernel and move to a model where many kernel services are implemented as Wasm modules.
gigel82 4y ago
Is there an explanation somewhere on what the plans for ABI are? Are they exporting just pure C functions from the Rust code?
- tialaramex 4y ago
  ABI to what? The kernel internally makes no promises about ABI even in C, why would that change for Rust? For userspace, Rust doesn't export anything new to userspace. The kernel APIs remain as they were, and Linus has the same view as ever about whether it's OK to break userspace.
  - mananaysiempre 4y ago
    > The kernel internally makes no promises about ABI even in C There might be two different definitions of “ABI” in this thread. The kernel indeed makes no promises regarding e.g. the order in which structure members are declared or the stability of that order from version to version. It probably can be said, though, to promise (through its interaction with the C compiler) that if you take a structure declaration as it appears in the source code, then in a normally-compiled kernel that structure will be laid out in a manner that’s predictable and most probably even described in a human-readable document. Those rules usually have not changed for decades (even if I sometimes wish they were different). As far as I know, unless you ask for that specifically, the Rust compiler does not promise any of that, the only documentation for what it will do by default is the source code, and it is free to change the rules from version to version with no notice.
  - gigel82 4y ago
    I mean how do they plan to interop between C and Rust code. Either in the same library or across shared libraries (if written in Rust, what does it export on the API surface such that C code can call into it)?
    - TheCoelacanth 4y ago
      Rust's C FFI has a stable ABI.
booleandilemma 4y ago
Wouldn't it make more sense for the Linux kernel developers to adopt a programming language that is the modern equivalent of C? I thought they liked C for its simplicity. Why would they adopt the modern version of C++? (a language they, or at least Linus, look down upon) Shouldn't they wait for a language with Rust's safety guarantees but with a more minimal feature set?
- throwaway894345 4y ago
  It's all a balance. Rust is simpler than C++, and the complexity it adds relative to C pays for itself pretty significantly in correctness (C++ is more complex and provides fewer/weaker correctness guarantees). Moreover, there aren't many systems languages to choose from--at least not many that are not super-niche. Even Ada is pretty niche with little mindshare/enthusiasm.
- strangescript 4y ago
  I think there is a question of "Wait till when?" Its not like these kind of languages pop up all the time, let alone get adoption. Rust checks most of the important boxes, and the few it doesn't do well they are working on.
- pjmlp 4y ago
  That would be Modula-2 in 1978.
synergy20 4y ago
Unless rust can link to its stdlib dynamically by default, its size is the biggest problem for any mid-range embedded boards(there are lots of them) due to the static link with rust's stdlib. Nowadays a few simple rust binaries will be close to 50MB when there are only 16MB or 64MB storage(if using c/c++, 1MB will suffice, rust is 40x larger). writing a busybox-like all-in-one rust binary could be a workaround but it is hard to do in practice.
- throwaway894345 4y ago
  For embedded, don’t you typically use no_std? Presumably that means you don’t link the stdlib?
  - synergy20 4y ago
    mid range boards needs stdlib
- pjmlp 4y ago
  Just like with using C and C++ on such scenarios, the standard library doesn't come for the party.
- newpavlov 4y ago
  Are you talking about binaries compiled for bare-metal embedded? In such cases you usually simply do not have `std`. And how do you think dynamic linking would help here? If anything, it will make total size bigger since compiler will not be able to perform dead code elimination. When people talk about big Rust binaries they often forget to strip debug information. Doing it can easily shed half of the binary size. And there are other relatively well known ways of reducing binary size (such as strategically using dynamic dispatch instead of monomorphization, using abort for panics, compiling with opt-level=z/s, etc.).
  - synergy20 4y ago
    no,i specifically said mid range boards,no-std is for bare metal mcu boards
mharig 4y ago
A language that has no stable ABI should not be in the kernel.
- insanitybit 4y ago
  Why?
  - mharig 4y ago
    Ever tried to use a C++ library from another language? Or from a binary compiled with another C++ compiler than the library?
    - insanitybit 4y ago
      What does that have to do with the kernel?
      - mharig 4y ago
        Support and spreading of a bad habit. As long as there is just one Rust compiler (Or are there two? How about the ABI of the second?),it doesn't matter much. But one day it will.
        insanitybit 4y ago
        I don't see how it has any impact on kernel development.
        mharig 4y ago
        You will, when in 5 years some proprietary Rust kernel module compiled with the IBM Rustbelt Rust compiler does not work together with other Rust kernel modules compiled with the standard Rust compiler.
- esarbe 4y ago
  Linux itself doesn't have a stable ABI, afaik.
jmull 4y ago
> most salient lines of code I wonder what that's supposed to mean? Hm... I could screenshot a single character and say: "I chose this character because if it's removed, the no one can log into twitter, and the whole system stops working. Or maybe I'd show a line of code that initiates advertiser charges, and say: "without this line of code we'd just be giving away as space, and we would lose most our revenue! But actually, I'd probably try to find a fiendishly complex snarl of logic (yeah, I sometimes do those, on my bad days) to befuddle the poor fella with.
user8501 4y ago
Why would the first non-c language allowed in the kernel be a language that doesn’t even have a standard? Also we’re bringing NPM style supply chain problems to the kernel now? And this is done in the name of security? It’s not the language itself I don’t like, I would like rust a lot more if it had a standard and didn’t have a supply chain (aptly named cargo) problem. It’s pretty obvious to me that software took a nosedive when finding a package became considered a good way write high quality software.
- iudqnolq 4y ago
  > Also we’re bringing NPM style supply chain problems to the kernel now? Nope. They've thought that through. (In fact, cargo is only used to build test helpers. https://github.com/Rust-for-Linux/linux/blob/rust/Documentation/rust/quick-start.rst#cargo https://github.com/Rust-for-Linux/linux/blob/rust/Documentat...)
  - user8501 4y ago
    Well that’s good.

253 points by biorach 4y ago

> The merge window for the 6.1 release brought in basic support for writing kernel code in Rust — with an emphasis on "basic". It is possible to create a "hello world" module for 6.1, but not much can be done beyond that. There is, however, a lot more Rust code for the kernel out there; it's just waiting for its turn to be reviewed and merged into the mainline. Miguel Ojeda has now posted the next round of Rust patches, adding to the support infrastructure in the kernel.

tux3 4y ago

If I'm writing my own out of tree Rust module (for the sole purpose of fun), I wonder how hard it would be to bring in external no-std crates? Rust as a language feels unusually high level for something running in kernelspace, although it never really sacrifices any control. But I wonder how far we can reasonably go in making kernelspace feel like userspace, by importing more of the language's 'vocabulary types', and maybe a few of the best utility crates for comfort. But besides people having fun out of tree, the kernel has plenty of fundamental complexity that can't very well be reduced. That tends to be the good complexity, the meat of it. What I would like to see is things that aren't essential complexity becoming nicer. Simple cultural things like better error messages when the tooling fails, or documentation becoming more common rather than the exception. None of this is guaranteed to magically happen just because there's a bit of infrastructure where Make can call rustc. But here's to hoping =)

gmadsen 4y ago
if I was curious, what would be a couple of the good complexities?
- mikepurvis 4y ago
  Not the OP, but I would assume that necessary complexity is at least where the complexity mirrors whatever real world complexity it is implementing, thinking particularly of protocol stacks like usb, networking, etc.
- tux3 4y ago
  Depends on what kind of problems you you find interesting, but since it's so close to the metal, and since people want their kernel to be fast, there tends to be a lot of clever algorithms, intricate locking, architecture-specific considerations, dealing with the hardware, all sorts of pretty interesting things you wouldn't usually find in regular business logic. Take filesystem code for example. It can sound like a conceptually simple and well trodden topic, but if you try writing one there's a pretty large design space and tons of interesting problems to try to solve. And then because of concurrency and the need for performance, there can be very intricate locking to the point it can be challenging to hold the whole model in your head all at once (you can have truncates, writes, mmap, all sorts of very different operations in flight in parallel that interract in funny ways). Or memory models. Reading memory-barriers.txt is a lesson in humility, I believe you can count on your fingers and toes the number of people in this world who can truly claim intimate familiarity with all the corner-cases and details implied by the model in that little text file =) But take practically any big subsystem of the kernel, and there tends to be plenty of interesting domain-specific problems and challenges.
- quirino 4y ago
  I believe they're referring to the essential complexity of the domain. An operating system has some "lower bound" on how complex it can be, which is rather high. But some stuff doesn't _have_ to be hard. Like OP said, there's no inherent reason for error messages and failures to be cryptic or documentation to be sparse. The system could be more transparent or modular, easier to debug/analyze, etc. I think there's an example in GCC vs Clang here, but I'm not qualified to comment.
biorach 4y ago
This is more a question of policy than mechanism - I'd imagine at least a provisional policy is in place, but the only to be found somewhere in the relevant kernel mailing lists.
consp 4y ago
> I wonder how hard it would be to bring in external no-std crates Wasn't this a thing that would not happen at all? at least that is what I remember from previous discussions. Another question would be how do you avoid an explosion of crates with different versions for each module.
- danhor 4y ago
  Policy decisions for linux itself don't (necessarily) apply out-of-tree modules?
kibwen 4y ago
Not a kernel hacker, but if it's just for fun, I don't know if you'd need to limit yourself to no_std crates. Allocation is supported (if it wasn't, then Rust's stdlib wouldn't be adding fallible allocation APIs to support the kernel usecase (and even if crates in the wild aren't using these APIs and abort on OOM, again, this is just for fun)). Meanwhile, I feel like OS-specific stuff performed by libstd (e.g. threads, networking) must surely be supportable somehow, since the OS is right there and all its facilities still exist, even if you might need to adjust codegen to account for the difference between kernelspace and userspace (I assume you would need to compile against a specific target?).
- tialaramex 4y ago
  Although Rust for Linux has its own alloc, that isn't really alloc. It is like if you wanted Coke and got Pepsi, if you just wanted fizzy brown beverage you're fine, but if you actually cared this isn't OK. Rust's String (the mutable owned string type from alloc) implements AddAssign meaning you can write fname += ".txt" and that works, but Rust for Linux doesn't allow that. This is just a really obvious example, there are many other differences
- nextaccountic 4y ago
  You can't use methods that may panic on OOM like Vec::push or Box::new. This means that close to 100% of crates that use the stdlib won't be usable in the kernel without modifications.
  - mcronce 4y ago
    My understanding isn't that you _can't_, but that you _aren't allowed to_ by kernel policy. (The risk being that the kernel will panic on OOM, which is not an acceptable way for the kernel to deal with OOM conditions.) If this is out of tree, AFAIK you can use these all you want. Whether or not you _should_ is obviously a different matter.
    - tialaramex 4y ago
      No, you can't - they don't exist in Rust for Linux. In Rust the alloc library's Vec has a function Vec::push(&mut self, value: T) https://doc.rust-lang.org/std/vec/struct.Vec.html#method.push https://doc.rust-lang.org/std/vec/struct.Vec.html#method.pus... In Rust for Linux their custom alloc library does not have that function offering instead Vec::try_push(&mut self, value: T) -> Result<(), TryReserveError> https://rust-for-linux.github.io/docs/alloc/vec/struct.Vec.html#method.try_push https://rust-for-linux.github.io/docs/alloc/vec/struct.Vec.h...
G4E 4y ago
Having third party crates in ring 0 is kind of terrifiying when you think about supply chain attacks...
- kibwen 4y ago
  So few people actually do their development/testing in truly-sandboxed environments that I don't think that there's actually much of a difference in practice between malicious code running in userspace vs malicious running in kernelspace ( https://xkcd.com/1200/ https://xkcd.com/1200/ ). Of course, I'd love if sandboxed dev environments became more usable and widespread.
- rowanG077 4y ago
  I would never expect them to do that without vendoring the package. Which mitigates that risk.
- esarbe 4y ago
  They don't use cargo.
sanxiyn 4y ago
I expect it to be possible in near future that you develop, say, a web server in Rust in userspace, and with a few changes run it in kernelspace, with improved performance.
- ilovecaching 4y ago
  We already have eBPF.
  - intelVISA 4y ago
    io_uring too
- tga_d 4y ago
  Running things in kernel space doesn't make them faster.
  - insanitybit 4y ago
    It can absolutely make things faster. If your program is running on data that exists in the kernel you don't need to copy it over to userland/ perform expensive context switching.
    - tga_d 4y ago
      It can make things faster is not the same as simply running it in the kernel will make it faster. There are definitely certain situations that making use of fewer context switches helps with, and where page mapping isn't sufficient, but if you just write an entire user-space web server, then just compile it as a kernel module, expecting it to see a notable performance improvement, you're going to be disappointed. edit to clarify: the reason it won't help (much) is because most of the things it would help with have already been optimized via features like CoW pages, the VDSO, sendfile, etc.
      - insanitybit 4y ago
LAC-Tech 4y ago
although it never really sacrifices any control. It feels like it sacrifices control wrt when you allocate and free-memory. I understand it's deterministic in rust, but it's not explicitly controllable - or at least I've seen it be.
- loeg 4y ago
  You have to bring your own memory in no-std. Implicit alloc is provided by the alloc crate (part of std).
- Others 4y ago
  I don’t follow. It’s exactly like C in this regard, except with Box::new instead of malloc.
  - conradev 4y ago
    The key difference as outlined in the article is that Box::new cannot fail in Rust, but the underlying malloc can. In userspace it is rare enough that a Rust panic is considered acceptable behavior, but this is not the case for the kernel. But, it is controllable for sure
    - tialaramex 4y ago
      Unsurprisingly the kernel's Box does not have Box::new it provides instead Box::try_new which is fallible.
- kaba0 4y ago
  Rust is a manual memory managed language, it literally has nothing inexpressible that C could do. Hell, C is a “higher level” language in that it doesn’t have any way for SIMD instructions. To add something concrete, you can manually free memory as well based on some dynamic property if you wish.

ilovecaching 4y ago

I think bringing Rust into Linux was a really bad idea. IMO Rust has yet to prove it isn’t another overly complicated C++ waiting to make projects almost incomprehensible to understand. It does not provide the same easy ramp up that C provided when working on most of the system software stack on Linux. There’s also still too few standalone projects using it to consider it a proper candidate for folding into such a large project forever. I am surprised Linus agreed to this given that he doesn’t like C++ and usually errs on the side of clear over clever, and we have yet to see tangible benefits of using Rust.

sedeki 4y ago
I have worked as a C++ dev, but am definitely not a C++ expert by any means. My take however is that C++ is inherently a complex language due to deliberately not sacrificing backwards-compatability of the syntax and semantics, which has been creating a mess as the language has evolved: there are many, many things to define semantically in order to "fit" a new piece in this old already-elaborate puzzle that is the C++ standard. You cannot say the same thing about Rust. Please correct me if you see things differently.
- noselasd 4y ago
  > You cannot say the same thing about Rust. At least not yet. My fear is it's _very_ easy to fall in to the same trap as C++ has, and become a big mess. Scott Meyers have a very nice talk here: https://www.youtube.com/watch?v=KAWA1DuvCnQ https://www.youtube.com/watch?v=KAWA1DuvCnQ about all these traps and pifalls that we have to deal with in C++. That said, I'm starting a bit with rust and enjoy it so a lot, especially the tooling alone is worth it - and if I never have to write another line of C++, I would be very happy (ofc the real world argues I have a lot of C++ code that will need maintenance).
  - cassepipe 4y ago
    When I tried Rust I came from Python and it was clearly too much for me to comprehend but after 2 years of C programming and 1 year of C++ programming, the problem Rust tries to solve make a lot more sense and I know understand the problem it's trying to solve. I am trying to use it again things like the borrow checker and Traits now make a lot of sense to me. I am also looking forward at not having to write C++ again. I haven't looked into C++17 and beyond though I must admit.

oxff 4y ago

Genuinely did not expect this to happen, a feature of not only software engineering, but management and organization too to make it happen.

jrimbault 4y ago

I'm really happy about the inclusion of Rust in the linux kernel. Not because it is Rust but because it shows that we can evolve. And I hope in a thousand years we aren't still stuck on C or Rust but "moved on" to even better things. It would make me quite hypothetically sad if in a thousand years we were still using tools designed by hackers in the infancy of computer science.

ArcMex 4y ago
>As can be seen, these patches are slowly building the in-kernel Rust code up so that real functionality can be implemented in Rust, but this process has some ground to cover yet. It's not clear whether more Rust code will be proposed for 6.2, or whether this is the full set. The pace of change may seem slow to developers who would like to start doing real work in Rust, but it does have the advantage of moving in steps that can be understood — and reviewed — by the kernel community. The Rust-for-Linux work has been underway for a few years already; getting up to full functionality may well take a while longer yet. Me too, I agree.
ilovecaching 4y ago
I'm really tired of the cargo culted idea that Rust is a silver bullet and C hasn't evolved since the 1970s. Neither of those things are true. The vast majority of people spouting opinions on Rust don't even write systems software, and have never even compiled a kernel driver. Linux, systemd, grub are all written in C and continue to have fewer flaws than trivial userland applications that allow for privilege escelation. The kernel core is incredibly high quality C, and time would be better spent working on the actual kernel security model. Dennis Ritchie himself wrote a paper about the deficiencies of the Unix security model which was designed for a trusting and shared computing environment. But of course updating the API surface isn't as sexy as writing in a new cool programming language. Cargo culting this notion that Rust is good because it is a security silver bullet is both ignorant AND dangerous because it moves the focal point away from the areas that actually need work to make Linux more secure. It's also completely asinine to assume that poorly written Rust will have fewer flaws than expertly written C that has been vetted for literally decades. Iterative improvement has ALWAYS been the answer over throw everything away and start fresh. C tooling has gotten better over the decades, the C standard has evolved, and people will continue to successfully write secure and performant applications in C. Edit: Also are you upset that people still use hammers in 2022? I guess if we aren't throwing away all of our tools instead of improving on their design we aren't really seeing any *Progress*

Wowfunhappy 4y ago

What does the relatively slow pace of Rust integration mean for the Apple Silicon GPU driver, which appears to be largely functional at this point but is written in Rust? Will the developers have to maintain a separate kernel branch with more robust Rust support for an extended period?

sanxiyn 4y ago
Yes. I don't think pace is slow. I am actually surprised how fast it is going. Code review is a good practice, and I think Rust patches are being reviewed nearly as fast as possible.
- Wowfunhappy 4y ago
  > I don't think pace is slow. I am actually surprised how fast it is going. Just to be clear, I agree--"relative" is the key word! It is slow if you're currently using Rust to develop a driver.

phendrenad2 4y ago

Now taking bets on how long until we can point to one subsystem or module in the kernel that's written in Rust. I'm betting 3 more years.

yjftsjthsd-h 4y ago
Hopefully not before they've sorted out the architecture support. It's fine to write drivers that only target one platform in a compiler that only targets that platform, but core systems need to be able to run on all the CPU architectures that Linux supports, which I understand is still a superset of the ones that rust supports.
pjmlp 4y ago
Enjoy the bluetooth stack, written in Rust, since Android 12. https://android.googlesource.com/platform//system/bt/+/83498aa554aea220fcff30b6310a0a7b4557969f/gd/rust https://android.googlesource.com/platform//system/bt/+/83498...
- phendrenad2 4y ago
  Oh, nice. I wonder how much work it would be to get that working on desktop Linux.

wly_cdgr 4y ago

I am growing closer to being convinced that Rust is here to stay and will actually become the main systems programming language of the next few decades.

deleted 4y ago
[deleted]
throwaway894345 4y ago
I think there's a couple of compatible perspectives that are both correct but often framed as mutually exclusive: 1. Rust will become the main language for new projects 2. There will still be an enormous amount of C that will be maintained for many decades and the majority of "lines of (systems) code" will be C rather than Rust for decades

titzer 4y ago

This is a good development and shows that there is appetite to move on to new, safer languages. What would be even better, IMHO, would be to bring full software fault isolation (SFI) into the kernel and move to a model where many kernel services are implemented as Wasm modules.

gigel82 4y ago

Is there an explanation somewhere on what the plans for ABI are? Are they exporting just pure C functions from the Rust code?

tialaramex 4y ago
ABI to what? The kernel internally makes no promises about ABI even in C, why would that change for Rust? For userspace, Rust doesn't export anything new to userspace. The kernel APIs remain as they were, and Linus has the same view as ever about whether it's OK to break userspace.
- mananaysiempre 4y ago
  > The kernel internally makes no promises about ABI even in C There might be two different definitions of “ABI” in this thread. The kernel indeed makes no promises regarding e.g. the order in which structure members are declared or the stability of that order from version to version. It probably can be said, though, to promise (through its interaction with the C compiler) that if you take a structure declaration as it appears in the source code, then in a normally-compiled kernel that structure will be laid out in a manner that’s predictable and most probably even described in a human-readable document. Those rules usually have not changed for decades (even if I sometimes wish they were different). As far as I know, unless you ask for that specifically, the Rust compiler does not promise any of that, the only documentation for what it will do by default is the source code, and it is free to change the rules from version to version with no notice.
- gigel82 4y ago
  I mean how do they plan to interop between C and Rust code. Either in the same library or across shared libraries (if written in Rust, what does it export on the API surface such that C code can call into it)?
  - TheCoelacanth 4y ago
    Rust's C FFI has a stable ABI.

booleandilemma 4y ago

Wouldn't it make more sense for the Linux kernel developers to adopt a programming language that is the modern equivalent of C? I thought they liked C for its simplicity. Why would they adopt the modern version of C++? (a language they, or at least Linus, look down upon) Shouldn't they wait for a language with Rust's safety guarantees but with a more minimal feature set?

throwaway894345 4y ago
It's all a balance. Rust is simpler than C++, and the complexity it adds relative to C pays for itself pretty significantly in correctness (C++ is more complex and provides fewer/weaker correctness guarantees). Moreover, there aren't many systems languages to choose from--at least not many that are not super-niche. Even Ada is pretty niche with little mindshare/enthusiasm.
strangescript 4y ago
I think there is a question of "Wait till when?" Its not like these kind of languages pop up all the time, let alone get adoption. Rust checks most of the important boxes, and the few it doesn't do well they are working on.
pjmlp 4y ago
That would be Modula-2 in 1978.

synergy20 4y ago

Unless rust can link to its stdlib dynamically by default, its size is the biggest problem for any mid-range embedded boards(there are lots of them) due to the static link with rust's stdlib. Nowadays a few simple rust binaries will be close to 50MB when there are only 16MB or 64MB storage(if using c/c++, 1MB will suffice, rust is 40x larger). writing a busybox-like all-in-one rust binary could be a workaround but it is hard to do in practice.

throwaway894345 4y ago
For embedded, don’t you typically use no_std? Presumably that means you don’t link the stdlib?
- synergy20 4y ago
  mid range boards needs stdlib
pjmlp 4y ago
Just like with using C and C++ on such scenarios, the standard library doesn't come for the party.
newpavlov 4y ago
Are you talking about binaries compiled for bare-metal embedded? In such cases you usually simply do not have `std`. And how do you think dynamic linking would help here? If anything, it will make total size bigger since compiler will not be able to perform dead code elimination. When people talk about big Rust binaries they often forget to strip debug information. Doing it can easily shed half of the binary size. And there are other relatively well known ways of reducing binary size (such as strategically using dynamic dispatch instead of monomorphization, using abort for panics, compiling with opt-level=z/s, etc.).
- synergy20 4y ago
  no,i specifically said mid range boards,no-std is for bare metal mcu boards

mharig 4y ago

A language that has no stable ABI should not be in the kernel.

insanitybit 4y ago
Why?
- mharig 4y ago
  Ever tried to use a C++ library from another language? Or from a binary compiled with another C++ compiler than the library?
  - insanitybit 4y ago
    What does that have to do with the kernel?
    - mharig 4y ago
      Support and spreading of a bad habit. As long as there is just one Rust compiler (Or are there two? How about the ABI of the second?),it doesn't matter much. But one day it will.
      - insanitybit 4y ago
        I don't see how it has any impact on kernel development.
        mharig 4y ago
        You will, when in 5 years some proprietary Rust kernel module compiled with the IBM Rustbelt Rust compiler does not work together with other Rust kernel modules compiled with the standard Rust compiler.
esarbe 4y ago
Linux itself doesn't have a stable ABI, afaik.

jmull 4y ago

> most salient lines of code I wonder what that's supposed to mean? Hm... I could screenshot a single character and say: "I chose this character because if it's removed, the no one can log into twitter, and the whole system stops working. Or maybe I'd show a line of code that initiates advertiser charges, and say: "without this line of code we'd just be giving away as space, and we would lose most our revenue! But actually, I'd probably try to find a fiendishly complex snarl of logic (yeah, I sometimes do those, on my bad days) to befuddle the poor fella with.

user8501 4y ago

Why would the first non-c language allowed in the kernel be a language that doesn’t even have a standard? Also we’re bringing NPM style supply chain problems to the kernel now? And this is done in the name of security? It’s not the language itself I don’t like, I would like rust a lot more if it had a standard and didn’t have a supply chain (aptly named cargo) problem. It’s pretty obvious to me that software took a nosedive when finding a package became considered a good way write high quality software.

iudqnolq 4y ago
> Also we’re bringing NPM style supply chain problems to the kernel now? Nope. They've thought that through. (In fact, cargo is only used to build test helpers. https://github.com/Rust-for-Linux/linux/blob/rust/Documentation/rust/quick-start.rst#cargo https://github.com/Rust-for-Linux/linux/blob/rust/Documentat...)
- user8501 4y ago
  Well that’s good.