Become a fan of Slashdot on Facebook

 



Forgot your password?
typodupeerror
×
Open Source Operating Systems Linux

Linus Torvalds Is Cautiously Optimistic About Bringing Rust Into Linux Kernel's Next Release (zdnet.com) 123

slack_justyb shares a report from ZDNet: For over three decades, Linux has been written in the C programming language. Indeed, Linux is C's most outstanding accomplishment. But the last few years have seen a growing momentum to make the Rust programming language Linux's second Linux language. At the recent Open Source Summit in Austin, Texas, Linux creator Linus Torvald said he could see Rust making it into the Linux kernel as soon as the next major release. "I'd like to see the Rust infrastructure merging to be started in the next release, but we'll see." Linux said after the summit. "I won't force it, and it's not like it's going to be doing anything really meaningful at that point -- it would basically be the starting point. So, no promises."

Now, you may ask: "Why are they adding Rust at all?" Rust lends itself more easily to writing secure software. Samartha Chandrashekar, an AWS product manager, said it "helps ensure thread safety and prevent memory-related errors, such as buffer overflows that can lead to security vulnerabilities." Many other developers agree with Chandrashekar. Torvalds also agrees and likes that Rust is more memory-safe. "There are real technical reasons like memory safety and why Rust is good to get in the kernel." Mind you, no one is going to be rewriting the entire 30 or so million lines of the Linux kernel into Rust. As Linux developer Nelson Elhage said in his summary of the 2020 Linux Plumber's meeting on Rust in Linux: "They're not proposing a rewrite of the Linux kernel into Rust; they are focused only on moving toward a world where new code may be written in Rust." The three areas of potential concern for Rust support are making use of the existing APIs in the kernel, architecture support, and dealing with application binary interface (ABI) compatibility between Rust and C.

This discussion has been archived. No new comments can be posted.

Linus Torvalds Is Cautiously Optimistic About Bringing Rust Into Linux Kernel's Next Release

Comments Filter:
  • hmmmm (Score:2, Interesting)

    by Anonymous Coward
    my only concern here is more bloat and more attack surface. The amount of bloat making its way into the kernel space is getting a bit beyond a joke at this point.
    • Re: (Score:2, Funny)

      by thsths ( 31372 )

      Well, you can always run GNU Hurd. Which, as we all know, is superior to Linux in every way, except for practical ones.

    • by Anonymous Coward

      I'm sort-of waiting for the first linux kernel exploit enabled by the presence of rust. That much code, there's bound to be some exploitable holes in it.

      linus' wording looks like he might be thinking that if someone really wants it to happen he's not going to stand in the way, rather than that he's actively supporting it. It's still being taken as active support by the rust evangelisation strike force and the fawning press. Which goes to show what they know.

      In either case, his long-term stewardship fitnes

      • I'm sort-of waiting for the first linux kernel exploit enabled by the presence of rust.

        I'm waiting for the first kernel exploit discovered by Rust.

      • I'm sort-of waiting for the first linux kernel exploit enabled by the presence of rust.

        Well, there's plenty of rot in there, so the rust probably won't amount to much. Oh, wait...

    • Twenty years ago I was surprised at how bloated the kernel was even at the lowest core. But that's ok, it's not mean for tiny systems, and a full virtual memory system is fundamental to modern Unix. The upshot means that for many embedded systems where there are some real time requirements that much of the system work gets shoved down into the kernel. And the modern kernel is designed to let this happen with various features. Still though, if you're taking an embedded RTOS based system and migrating to Li

      • It's not as bloated as it looks. A lot of kernel code is conditional compilation. But yeah, we usually err in favor of performance and scalability over terseness.

        • I am hoping that most of it is in obscure device drivers.

          It is a testament to the developers that on the one hand they are clever enough to get a single blob of 30 million lines of code to work, but on the other hand are crazy enough to try. But there is no way Linus or anyone else really understands it any more.

          And I hope that your comment about conditional code is wrong. Code riddled with #if is a mess. Hopefully well designed interfaces with option modules. Takes a bit more thought, but the only way

          • Yes, by far the majority of kernel code is in drivers. Core kernel is tiny by comparison and that is where you will often find large amounts of source that may compile down to a tiny amount of object code or no object code at all if some kernel option is configged off.

    • Rust has far more powerful tools for automated analysis than C does. Ever tried to read a cpp macro of any complexity, much less develop one?

      • Oh boy. Yep. I have a couple for helping with boilerplate that comes with some template classes and they flat out crash visual studio when it tries to parse them, presumably for intellisense. I now edit those headers using notepad++ ;)
    • by jythie ( 914043 )
      yeah, multi language binaries tend to be nightmares of attack surfaces and maintenance issues... for systems that require stability, you really need to have a strong use case for doing something like that.
  • by enriquevagu ( 1026480 ) on Tuesday June 28, 2022 @02:24AM (#62656494)

    like he was five days ago [slashdot.org] in the exact same conference you are reporting now.

  • by Sarusa ( 104047 ) on Tuesday June 28, 2022 @02:28AM (#62656498)

    Rust is definitely more annoying to write in than C (it's half-way to Java), though it's certainly no more annoying than C++. But in return you get nearly guaranteed safety running 99% as fast.

    I don't want to say 100% guaranteed because poop happens, but scaremongers crying about 'additional attack surfaces' are just missing the point. There are 30M existing lines of linux C/C++ code that are just completely riddled with vulnerabilities that are exploited every single day. Most of them would be neutralized with Rust, and FUD aside every bit of kernel that's in Rust and not C/C++ will improve that.

    • Re: (Score:3, Interesting)

      You make a religious argument, not an engineering one. Good Rust is far safer than C, without a doubt. Superficial fashions are meaningless compared to the pragmatic assurances delivered. Perhaps use it and understand it before throwing Monday night armchair quarterback shade.

      If someone wanted to make a safer Linux kernel, they might write a formally-verifiable one in Rust on top of seL4. The beauty of seL4 is being able to add other architectural pieces to the mix after-the-fact like compatibility layers f

      • Safety isn't free (Score:5, Insightful)

        by Viol8 ( 599362 ) on Tuesday June 28, 2022 @04:38AM (#62656642) Homepage

        It doesn't happen by magic , extra instructions have to be inserted by the compiler in the binary to do all the runtime bounds checking. That might be fine in a desktop application but it is most definately not fine in parts of the kernel that could be in a tight realtime loop where microseconds (sometimes even nanoseconds) matter.

        • It doesn't happen by magic , extra instructions have to be inserted by the compiler in the binary to do all the runtime bounds checking.

          Rust does bounds check in the runtime, but many uses of Rust that you might expect to bounds check do not actually do so. If you access a single element of an array using square bracket and an index, that will bounds check. If you use iterators to loop through part or all of an array, it will not bounds check, because it is known to be safe. Rust calls this a zero-cost abstraction because, well, it is zero-cost at runtime. Likewise, use-after-free detection, race-condition detection and many parts of the ty

          • by Viol8 ( 599362 )

            "Likewise, use-after-free detection, race-condition detection ... .... They are all enforced at compile time"

            Neither of those can be reliably enforced at compile time unless their use cases are severely restricted which rather defeats the point.

            • by vadim_t ( 324782 )

              Rust does it by forcing you to code in a very particular way.

              Eg, when you pass a bunch of data to a function, it now belongs to it, and it's a compile-time error to do anything with it afterwards. So you can't have a situation where you do (in pseudocode):

              frobnicate(x); // We don't know that this will actually free x
              print(x); // Segfault!

              Because as of the first line, you gave up your ownership of x. In Rust, you have to either explicitly let "frobnicate" to borrow the variable, which then forces it to giv

            • Yes this is the compromise. Rust gets around this problem by having two parts to it. A safe part (which is the main part) and the unsafe part (which gives you just a few extra things). In safe code a use-after-free cannot happen, while in unsafe code it can. The latter has to explicitly declared and is often a very small part of the code base.

              In a kernel it might be more. We don't know yet. If it works well, though, it should limit the sections of code where bad things can happen. No magic bullet, but possi

      • this claimed "safety" is just a meme until proven. Plenty of ways to cause a disaster in the kernel even with Rust's features.

        • Not like you are ever going to, having never coded a line of kernel code in your life.

          • False, had to do that in grad school.

            If you don't know a thing about someone's background best not to make up cocky b.s. eh?

            Let me guess, you're a butthurt Rust fanboi wishing something of significance would be done with your pet language that mostly isn't used for the infrastructure of our world?

    • Most of Linux is drivers for obscure hardware. The core of Linux is very small.

    • Re: (Score:3, Interesting)

      by Joce640k ( 829181 )

      There are 30M existing lines of linux C/C++ code that are just...(snip)

      a) Never trust anybody who writes "C/C++".
      b) Against all common sense, Linus has never allowed a single line of C++ in the kernel.

    • There are 30M existing lines of linux C/C++ code that are just completely riddled with vulnerabilities that are exploited every single day

      Wrong on multiple levels. First, there is not C++ code in the kernel because Linus does not like C++. Second, it is not riddled with vulnerabilities, rather it is considered one of the most thoroughly debugged large bodies of code in the known universe. Third, it is big news when a Linux kernel vulnerability is found because this is a rare thing indeed. If a Linux kernel is exploited it is almost never because of an open kernel vulnerability, but rather because an attacker got root access because of poor se

  • by quonset ( 4839537 ) on Tuesday June 28, 2022 @05:47AM (#62656710)

    It's the degradation of iron. It flakes off in dark brown bits leaving a mess, structural integrity is compromised, and requires replacement unless you want a total collapse.

    *whisper* *whisper* *whisper*

    Never mind.

  • Except on Spotify
    • I'd for for Unix, which is still around and of which Linux and GNU utilities are a work-alike.

      • which is still around

        We're not handing out participation awards here. My grandpa doesn't get credit for me getting an engineering degree either. Unix may be "still around" but it hasn't had remotely the direct impact on people's lives that Linux has.

        Posted from my phone, which ... you know ... is not running a Unix kernel.

        • Oh so you're not using one of the 55 percent the phone market which is iPhone?

          You're funny, Mac OSX is Unix, so are the BSD including the tons of embedded stuff in everything from elevator controls to network switches to printers.

          Seems you have a case of ignorance about just how much Unix (not to be confused with Unix TM) that is out there

  • Rust has many good qualities but it is changing and does not have the type of support that commercial and matching open source platforms like Ada and C++. Ada/Spark have a long track record and features that would benefit Linux like contracts that can be used to prove that a program will do what you say it will before you run it. There are more features that would be useful as well.

    Check out 11 Myths About Ada [electronicdesign.com] if you think Ada/Spark is not a viable option. You can learn and try Ada and Spark at learn.ada [adacore.com]
  • Indeed, Linux is C's most outstanding accomplishment.

    If you ignore all the versions of Unix that came before and since.

Do you suffer painful hallucination? -- Don Juan, cited by Carlos Casteneda

Working...