Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Linux

The ISRG Wants To Make the Linux Kernel Memory-safe With Rust (arstechnica.com) 124

Posted by msmash from the moving-forward dept.
mrflash818 writes: The Internet Security Research Group (ISRG) -- parent organization of the better-known Let's Encrypt project -- has provided prominent developer Miguel Ojeda with a one-year contract to work on Rust in Linux and other security efforts on a full-time basis. Rust is a low-level programming language offering most of the flexibility and performance of C -- the language used for kernels in Unix and Unix-like operating systems since the 1970s -- in a safer way. Efforts to make Rust a viable language for Linux kernel development began at the 2020 Linux Plumbers conference, with acceptance for the idea coming from Linus Torvalds himself. Torvalds specifically requested Rust compiler availability in the default kernel build environment to support such efforts -- not to replace the entire source code of the Linux kernel with Rust-developed equivalents, but to make it possible for new development to work properly. Using Rust for new code in the kernel -- which might mean new hardware drivers or even replacement of GNU Coreutils -- potentially decreases the number of bugs lurking in the kernel. Rust simply won't allow a developer to leak memory or create the potential for buffer overflows -- significant sources of performance and security issues in complex C-language code.
This discussion has been archived. No new comments can be posted.

The ISRG Wants To Make the Linux Kernel Memory-safe With Rust More

The ISRG Wants To Make the Linux Kernel Memory-safe With Rust

Comments Filter:

  • Inaccurate summary (Score:5, Informative)

    by AlexanderPatrakov ( 6166150 ) on Tuesday June 22, 2021 @01:55PM (#61510750)

    "Replacement of GNU Coreutils" has nothing to do with the kernel. And also, "Rust simply won't allow a developer to leak memory" is a false statement, see https://doc.rust-lang.org/book... [rust-lang.org]

    • Re:Inaccurate summary (Score:5, Insightful)

      by slack_justyb ( 862874 ) on Tuesday June 22, 2021 @03:44PM (#61511022)

      "Replacement of GNU Coreutils" has nothing to do with the kernel.

      Absolutely. As someone who is a big supporter of Rust, this whole thing from start to finish sounds like someone who has no idea what Rust is about made it up. Additionally we already have a GNU coreutil in Rust with uutils [github.com]. Is a really neat project, not exactly ready for prime-time, but is absolutely a project that's got some really enthusiastic people behind it. Additionally, what they do have done is quite good.

      And also, "Rust simply won't allow a developer to leak memory" is a false statement

      Absolutely. Rust will prevent you from SOME kinds of leaks, but shoot. There's literally a Box::leak [rust-lang.org] that literally allows you to on purpose leak memory. Getting around the Rust compiler to leak memory is done in very obvious and easy to find ways, so if your code review requires that you not do those things, you going unsafe/using a leak method/not using weak reference is going to stand out like a klaxon in a cucumber patch. However, outside of a code review, there's literally nothing stopping you from telling the compiler to stop being such a snob on the code.

      Everything in this article is bad, bad, bad, and double bad. There are zero reasons at this time to whole hog swap the Linux Kernel over to Rust. There's still tons of work to do in the compiler to make it really shine and perhaps one day Rust will be ready to take on something as complex as the Linux kernel, but it is not this day.

      • if your code review requires that you not do those things, you going unsafe/using a leak method/not using weak reference is going to stand out like a klaxon in a cucumber patch. However, outside of a code review, there's literally nothing stopping you from telling the compiler to stop being such a snob on the code.

        That's true for now and for Rust.

        It's never been true of C# or Java. C# runs in a virtual machine called the CLR, and the CLR can verify when loading a program whether or not it has anything unsafe in it. Several platforms using the CLR have had a policy of no unsafe code, namely Silverlight, Windows Phone 7, and Xbox Live Indie Games. Likewise, the Java platform has JNI to segregate "unsafe" things, and several Java profiles (applet, MIDP, and the like) ban JNI. If Rust gets ported to such a virtual machin

      • There's literally a Box::leak [rust-lang.org] that literally allows you to on purpose leak memory.

        Why would such a thing exist? Shouldn't something somewhere have a reference to the memory for it to be useful?

        • How about: Your device needs a section of main memory allocated to it for working space but you don't do anything with it after the allocation.

      • one day Rust will be ready to take on something as complex as the Linux kernel, but it is not this day

        You seem to be a bit out of touch. A simple device driver in Rust has already been posted to LKML [lwn.net] and Linus is basically on board with the project.

        • I would counter that you are the one who seems to be out of touch. From the actual email [lkml.org]:

          Please note that the Rust support is intended to enable writing drivers and similar "leaf" modules in Rust, at least for the foreseeable future. In particular, we do not intend to rewrite the kernel core nor the major kernel subsystems (e.g. `kernel/`,`mm/`, `sched/`...). Instead, the Rust support is built on top of those.

          So when I say as complex as the kernel itself, that's backed up by statements from the actual kernel maintainers. You can present your arguments on technical merit, but if you're diving into semantics of what "something as complex as the Linux kernel" means, you can go fuck off. I don't deal with semantic peons.

          • You must be a lot of fun at parties. You sure beat that straw man all to pieces. Rust is targeted at drivers for the time being, not core. Nobody with a clue thinks even that will be a walk in the park, but there is significant momentum behind the experiment.

            My, this topic does seem to flush the antisocials out into the open.

            • You must be a lot of fun at parties

              I am because I go to the parties that have people who know what they are talking about in attendance.

              Nobody with a clue thinks even that will be a walk in the park, but there is significant momentum behind the experiment.

              So you think the comment:

              one day Rust will be ready to take on something as complex as the Linux kernel, but it is not this day

              applies here, good to know that you are not above the fray of changing your mind when presented evidence.

              My, this topic does seem to flush the antisocials out into the open.

              Yes, accurate description of me, thank you. To counter, time has value. So before you begin opining on "how out of touch I am", perhaps you can save us all some time and read the email that you yourself linked in your pointing out of "how out of touch I am" and come to the posit

    • Right, the Rust "safety" involves run time overhead. In a lean and mean kernel (which really doens't apply to the big Linux kernel :-) you don't want extra run time overhead. So Rust allows you to turn off the safety when you need to, which is needed in this case. Rust would be used in the same way that C is used, only with a different syntax and with mostly the same level of safety as a late model GCC. Any benefits would accrue solely from static analysis and stricter type rules.

      Rust has no idea whatso

      • Right, the Rust "safety" involves run time overhead.

        Mostly false. The rust runtime is actually comparable in size and complexity to the C runtime. It's quite small. Just like C, there are a few minor safety checks at runtime, (for example, heap integrity checking) but not many. Most of the safety guarantees happen at compile time. But also like C, the runtime can be skipped entirely or replaced, just as the Linux kernel already does in favor of its own panic handler.

        So Rust allows you to turn off the safety when you need to, which is needed in this case.

        Only in some parts, but even so, unsafe rust actually offers more safety guarantees at compil

      • Even a NULL pointer is perfectly valid many times because "0" is a valid memory location (the trick to avoid the first 1MB on Linux applies only to PCs).

        NULL pointers are valid, because C says you can have a pointer to any location. The trouble only comes when you try to dereference it. C also has the extra "guarantee" that 1-past-the-end pointers are valid for comparison with other pointers derived from that underlying object/array, but that pointer can never be dereferenced safely.

      • Re: (Score:3)

        by DrXym ( 126579 )
        Actually most of Rust's safety has ZERO runtime overhead. The compiler does the checking of unsafe code and fails until you fix the code. Code that passes compilation does not need runtime checks because it is safe. Rust does have runtime checks on some actions such as random access to arrays to ensure they are in bounds. The usual practice in Rust is to use slices and iterators as appropriate and avoid random access which again compile to code similar to C or C++.

        As for kernel vs application code, Rust a

        • As for kernel vs application code, Rust already compiles against baremetal, and kernels and user land. The global allocator can be changed as appropriate.

          Actually, that's a big problem for Rust in kernel - kernel doesn't just have one global allocator, it has many different allocators, including slab, pages, pools, limited heap-like vmalloc, others. Rust will need to learn some fundamental new tricks to accommodate these. Box simply isn't enough. Not to worry, bright minds are involved and it shall be done, but it's not just a matter of changing "the global allocator", far from it.

    • "Replacement of GNU Coreutils" has nothing to do with the kernel.

      -5, Reading Comprehension.

      Supporting Miguel Ojeda’s Work on Rust in the Linux Kernel [memorysafety.org]

  • First thing ... (Score:5, Funny)

    by PPH ( 736903 ) on Tuesday June 22, 2021 @02:02PM (#61510768)

    ... do systemd.

    • I still don't understand how systemd managed to take over Linux. I assume it has something to do with RedHat, but with all I've read, I just get more confused how they managed to pull it off on a system that's supposed to be open source.

      • Re: (Score:2)

        by jythie ( 914043 )
        Well, as the saying goes, standard is better than the best solution. Systemd hit a critical mass where, if developers and distributions wanted to make efficient use of their time and resources, it was better to adopt it than not. The more distros that used it, package maintainers had an incentive to use it, and as more package maintainers used it, more distros had an incentive to do the same.

      • Re:First thing ... (Score:4, Insightful)

        by Anonymous Coward on Tuesday June 22, 2021 @04:01PM (#61511068)

        I still don't understand how systemd managed to take over Linux.

        Lots of admins can't actually program. A couple of bash scripts confuse them. They'd rather set up a configuration file and hope that whatever reads and executes based on its settings accounted for all the possible use cases. If not, too bad. NOTABUG. WONTFIX.

        Poettering's laptop boots just fine. He doesn't understand why your datacenter servers do not.

        • Yeah, it feels like there's room in the world for "SensibleD" - systemd without the stupid. Just enough to get the system to boot but no more than that. If you want all of Poettering's crap, then you can install it as add-ons, but otherwise, you get to boot and do no more. Timers, DNS, pluseaudio and that crap he was talking about for home directory permissions - forget all of it.

          FWIW, I do rather appreciate having my process's STDOUT go straight to syslog, and not having to do that whole double fork malarc

      • Re: (Score:3)

        by jabuzz ( 182671 )

        Listen to what Benno Rice has to say about the tragedy of systemd

        https://youtube.com/watch?v=o_... [youtube.com]

        The concept is good. My biggest bug bear is that its systemctl action service rather than systemctl service action. If you don't understand the issue with that you don't understand the problem. Also when running in a terminal it should give you some fecking feedback as to whether the service started or not.

        One does get the feeling that Pottering has never actually had to look after a bunch of servers. I think t

        • One does get the feeling that Pottering has never actually had to look after a bunch of servers. I think the proposal to have all your screen/tmux/nohup killed when you logout is extremely illuminating.

          Wait...what?!

      • Systemd *almost* took over. Devuan, Gentoo and Funtoo all fully support openrc and Devuan still supports sysv init. It works just fine on my modern Dell xps laptop. Support those distros and keep them alive.

      • Re: (Score:2)

        by DrXym ( 126579 )
        Because it works better than what it replaces and despite all the bitching and moaning is completely fine.

  • i detect a fork of the kernel coming (Score:3)

    by FudRucker ( 866063 ) on Tuesday June 22, 2021 @02:10PM (#61510784)
    or would that be a rusty fork? the kernel developers better get a tetanus shot so they dont get lockjaw

  • Why Rust? (Score:5, Funny)

    by Joce640k ( 829181 ) on Tuesday June 22, 2021 @02:34PM (#61510840) Homepage

    They should use JavaScript for this. It's more mature and provides all the same guarantees.

  • False and exaggerated Rust claims (Score:5, Insightful)

    by iggymanz ( 596061 ) on Tuesday June 22, 2021 @02:56PM (#61510906)

    Rust would have to use unsafe mode for kernel and drivers, the claims of Rust safety extending to this type of systems programming are utter rubbish. Rust devs might even introduce all manner of new kinds of bugs since their language not intended for OS kernel. (please don't bother linking cute little toy projects)

    • Actually even "unsafe" rust offers more safety guarantees than C.

      • And kernels written with unsafe Rust crash just as much: https://gitlab.redox-os.org/re... [redox-os.org]

        • Actually that's impressive considering that it's very much a beta right now, and even then that is from 3 years ago.

          Also, rust doesn't guarantee no crashes. In fact, it's easy to make your program crash:

          let foo: Option<i32> = None;
          foo.unwrap();

          And that's a good thing, it did exactly what we told it to do, and we'd way rather our programs crash than do unexpected things.

          There are ways of making it freeze as well:

          loop {};

          But that isn't undefined behavior, which is what Rust is good at preventing.

          • Intentional panic is arguably not really a crash. You have to work a bit harder to make Rust segfault.

      • Assertion made without a shred of proof. When or if someone makes a production grade OS out of Rust we'll see.

        • https://doc.rust-lang.org/book... [rust-lang.org]

          You can take five actions in unsafe Rust, called unsafe superpowers, that you canâ(TM)t in safe Rust. Those superpowers include the ability to:

          Dereference a raw pointer
          Call an unsafe function or method
          Access or modify a mutable static variable
          Implement an unsafe trait
          Access fields of unions

          Itâ(TM)s important to understand that unsafe doesnâ(TM)t turn off the borrow checker or disable any other of Rustâ(TM)s safety checks: if you use a reference in unsafe code, it will still be checked. The unsafe keyword only gives you access to these five features that are then not checked by the compiler for memory safety. Youâ(TM)ll still get some degree of safety inside of an unsafe block.

          In addition, unsafe does not mean the code inside the block is necessarily dangerous or that it will definitely have memory safety problems: the intent is that as the programmer, youâ(TM)ll ensure the code inside an unsafe block will access memory in a valid way.

          • You must know nothing of kernel and systems programming if you think that's an argument for Rust affording any protection

            • You must know nothing of kernel and systems programming if you think that's an argument for Rust affording any protection

              Generally when one wants to argue...they make an actual argument.

              • kernel and systems level programming requires all of those unsafe things.

                the only one not understanding the argument is you the utterly ignorant Rust shill.

                • kernel and systems level programming requires all of those unsafe things.

                  Yes...nobody said it doesn't...

                  By the way, has anybody ever mentioned to you that you may be a few cards short of a full deck? Just so you know, they're not actually talking about cards.

                  the only one not understanding the argument is you the utterly ignorant Rust shill.

                  Oh noes you figured me out! Now how will I collect my shill money from some forces unknown that have a financial stake in people not paying any money to use Rust...

                  But seriously, I really doubt ISRG, Google, Microsoft, Linus Torvalds, and many more groups/people that know a hell of a lot more about systems programming than y

      • Re: (Score:2)

        by gweihir ( 88907 )

        Actually even "unsafe" rust offers more safety guarantees than C.

        1. Empty claim, no proof given. Just like any cult that claims that of course _they_ have the best beliefs.
        2. Does not matter. When doing C or unsafe Rust, you need to understand what you are doing.

        • Heathens...

          1. Empty claim, no proof given. Just like any cult that claims that of course _they_ have the best beliefs.

          Well you can just try it for yourself if you want. Here's an example:

          unsafe {
          let foo;
          {
          let bar = "bar";
          foo = &bar;
          }
          foo.len();
          }

          Spoiler: It won't compile. If it did, that would be a dangling pointer. Even though it's defined in an unsafe block, that safety feature remains intact. Just one among many that don't even exist in C at all.

    • Re: (Score:2)

      by gweihir ( 88907 )

      Indeed. These people are persistent idiots and liars. Their fetish language _cannot_ deliver what they claim it can. And unsafe mode in Rust will be far worse, because a C coder actually knows of the dangers and has experience with them, while the Rust disciples are used to being protected and coddled. Without their safety-net, they will just keep screwing up badly.

      My take is that Linux is actually just giving them enough rope to hang themselves. And they will.

    • Re: (Score:2)

      by DrXym ( 126579 )
      Actually no it's not rubbish. If you write a kernel in C or C++ then 100% of your code is unsafe. ALL of it. If you were to write a kernel in Rust then only a fraction of it is unsafe. It is therefore far easier to identify what caused a panic and worry less about the code that didn't. And the fact you want to handwave actual kernels written in Rust as "toy projects" shows how disingenuous you are being.

      • Plus, the only unsafe parts of your kernel code that may well be hived off behind a safe API, already written for you.

    • Apparent that you haven't looked at the Rust in kernel project, nor are you familiar with Rust. The plan is to provide device driver authors with a safe API by shelling unsafe kernel APIs with mostly zero-cost safe abstractions. As a typical example, spinlock release can be guaranteed when it goes out of scope. Of course there are many complexities and it is highly unlikely that every unsafe hole will be plugged. But when the kernel community decides to do a thing, that thing usually gets done. Git for exam

  • All they are is rust in the wind!

  • Why are they looking at Linux; why not Windows? Oh yeah, they can't do that, can they?

    • Why are they looking at Linux; why not Windows?

      Actually, Microsoft itself is integrating Rust into their Windows OS and apps.

    • Re: (Score:2)

      by Mascot ( 120795 )

      But Microsoft can, and are. They are a part of the Rust Foundation and have been adopting Rust for internal use for a number of years now. Their main motivation, from what I've seen in talks, is the 70% or so of Windows vulnerabilities coming from memory safety issues. They seem to feel a significant portion of that can be eliminated by using a safer language like Rust.

      Even if you have to use unsafe to accomplish some specific operation in Rust, people seem to forget that the "unsafe" keyword is a bit of a

  • Its not the language thats the problem (Score:3)

    by JustNiz ( 692889 ) on Tuesday June 22, 2021 @07:43PM (#61511660)

    Its people not following good coding principles.

    • Re: (Score:2)

      by gweihir ( 88907 )

      Its people not following good coding principles.

      Indeed. But there is a lot of bad coders that are blaming their tools and keep hoping for that one "silver bullet" language that finally will make their code not suck. Of course, that will never happen as it is fundamentally impossible. These people just keep avoiding facing the truth.

    • And how do you fix this ? By using a language that enforce more good coding principles like Rust for example.

  • You cannot make an OS kernel memory safe. I think these people have no clue what they are talking about.

    • Rust in kernel is targeted at device drivers, not core. It should be possible to provide safe APIs for the vast majority of things device drivers need to do. Linus is at least on side with the experiment.

Slashdot Top Deals

Top Ten Things Overheard At The ANSI C Draft Committee Meetings: (10) Sorry, but that's too useful.

Close