Slashdot is powered by your submissions, so send in your scoop

 


Forgot your password?
Close
typodupeerror
×
Linux

Linus Torvalds Says Rust For The Kernel Could Possibly Be Merged For Linux 5.20 (phoronix.com) 157

Posted by msmash from the closer-look dept.
Speaking this week at the Linux Foundation's Open-Source Summit, Linus Torvalds talked up the possibilities of Rust within the Linux kernel and that it could be landing quite soon -- possibly even for the next kernel cycle. From a report: Linus Torvalds and Dirk Hohndel had their usual Open-Source Summit keynote/chat where Linus commented on Rust programming language code within the kernel. Torvalds commented that real soon they expect to have the Rust infrastructure merged within the kernel, possibly even for the next release -- meaning Linux 5.20. There hasn't yet been any Rust for Linux pull request sent in or merged yet, but things have begun settling down in the initial Rust enablement code for the kernel with the basic infrastructure, a few basic sample drivers, etc. Last month saw the most recent Rust Linux kernel patches posted that got more functionality into shape and additional reviews completed. As noted plenty of times before, this Rust support within the Linux kernel will remain optional when building the kernel depending upon whether you want the support or any of the kernel features to be implemented just in Rust code.
This discussion has been archived. No new comments can be posted.

Linus Torvalds Says Rust For The Kernel Could Possibly Be Merged For Linux 5.20 More

Linus Torvalds Says Rust For The Kernel Could Possibly Be Merged For Linux 5.20

Comments Filter:

  • Most secure OS ever, incoming. (Score:2, Funny)

    by Anonymous Coward
    As Rust by nature prevents many types of programming errors, once the entire kernal is re-written in Rust it should greatly decrease the attack surface of the Linux kernal and finally will overtake Windows as the OS of choice among the corporate world.

    • Re: (Score:2, Insightful)

      by Malc ( 1751 )

      I think you're being a little fanciful with that idea. If people cared about issues caused by the size of the attack surface, Windows would have been sidelined years ago.

    • Lol no. Mostly one problem, same as modem C (Score:5, Informative)

      by raymorris ( 2726007 ) on Thursday June 23, 2022 @10:09AM (#62644612) Journal

      I track and report on vulnerabilities as part of my job, and have for a long time.

      No, it will not "greatly decrease" anything. Mostly Rust attempts to protect against one type of error that matters. Modern C, for at least the last 11 years, also protects against the same type of error. Then Rust tries a couple other things that are not a significant percentage of security vulnerabilities.

      Rust might be a decent language. The Rust fanbois definitely make ridiculously over hyped security claims in decades. In the Slashdot tradition of car analogies, here's what their claims sound like to a career security professional:

      Rust project:
      The new Toyota Rust is so much faster than other cars! No more "are we there yet?"!
      * The Rust has a top speed of 92 MPH, vs 90 MPH for the competition.

      Rust fanbois, who mostly aren't even programmers and have never used the language:
      You're still driving to California? Why didn't you just use Rust so you'd get there instantly? Rust pretty much goes lightspeed, ya know.

      But the most fun is when they trumpet things that apply to most any language. Which is a like a car fan shouting "this car has cupholders!"

      • This is my gripe: the hype train. What immediately sets off my skeptic alarms is when something comes with all benefits and zero drawbacks. Then I know it's just marketing talk. There's a single person in our devices software department, with maybe 300+ actual developers around the world, and he's often pushing Rust at the highest levels. He goes on and on about how it will solve all our problems with bugs, but never once mentions any drawbacks: learning curve, rewriting millions of lines of code, testi

      • Re: (Score:2)

        by pavon ( 30274 )

        What class of bugs are talking about? Nothing in modern C and C++ standards do much to prevent memory access bugs, which are still the leading cause of exploitable bugs in all the surveys I've seen. Improved tooling like AddressSanitizer have greatly decreased the number of memory access bugs in my C/C++ code from getting to production, but some still do in my code, and in other large C/C++ code bases that I know are using best practices.

        Rust eliminates those entirely, except in unsafe blocks which I rarely

      • I think a better analogy would be: it comes with seatbelts, so now entire classes of crashes go from lethal to not a big deal.

        "But aren't seatbelts just a standard feature on cars?" Yes, yes they are. And people argued against them just like you're arguing against Rust now.

    • and finally will overtake Windows as the OS of choice among the corporate world

      Normally I'd say this is deserving of a funny mod, but honestly there's so much stupidity on Slashdot that I think this along with the rest of your post is actually you being serious. Wow.

    • Half of the kernel CVEs are attributable to the language (null pointers, double frees, buffer overflows etc) and would have been caught in Rust. So it doesn't mean the end of bugs to use Rust but it does mean a lot less bugs overall.

  • Welcome to our Rust overloads I guess (Score:5, Interesting)

    by brunoblack ( 7829338 ) on Thursday June 23, 2022 @09:13AM (#62644458)

    Like many here, I am a little reluctant to having Rust in the kernel but I guess Linus knows better.

    From what I read before, Rust would only be used for drivers and modules. Does anybody knows if it is planned to use Rust in the core of the kernel as well?

    I read about potential issues for platforms where the Linux kernel runs which don't support Rust. I guess the kernel could then be cross compiled for the target platform on another platform that supports Rust but it is a wild guess. Anybody knows more about that than I do?

    Anyway, having Rust in the kernel would be a good reason for me to learn it I guess.

    • You could cross compile the kernel, but if you were serious about it, you'd start by cross compiling the Rust compiler. Since it's an LLVM compiler the back end hard work is already done for any platform you're likely to come across, so it's just a matter of cross compiling the front end, then your platform is a rust native platform.

    • Rust isn't available for every architecture and has tons of dependencies for building. How do they plan to keep it from creeping into platforms that can't build the rust toolchain?

      • Until Rust can be compiled with gcc (there are two different approaches to making that happen currently in progress), Rust will be confined to writing device drivers for supported architectures.
      • Which architecture is missing on Rust? Sure Itanium is not supported but most major chip architectures are there.

    • Like many here, I am a little reluctant to having Rust in the kernel but I guess Linus knows better.

      Do not be reluctant, change is good. And memory safe languages are good as well. And, while Linus is human, and therefore fallible, in his domain of expertise (the Linux Kernel) he probably know better, so right you are.

      From what I read before, Rust would only be used for drivers and modules. Does anybody knows if it is planned to use Rust in the core of the kernel as well?

      For the time being, no, only drivers and modules. But hopefully, in the future, as both Linux and Rust evolve, maybe, the door is not locked, and dare I say, is not closed either (is ajar).

      Also, there is a parallel effort to move Linux out of GCC and into LLMV (a very worth and important eff

    • There's a difference between knowing better and caring. Linus used to have a reputation for being a hardass and putting technical correctness over peoples' feelings. Lately, I think he's been getting tired of the politics and has been conceding to too much nonsense.

      There's still a debate over the facts that Rust lacks a formal standard, core feature development is still in flux, and only has a single implementation available. I really, really don't think that's an acceptable platform to be using for an O

  • probably a good idea to get the Trademark issues resolved before that happens

    * https://lists.debian.org/debia... [debian.org]
    * https://news.ycombinator.com/i... [ycombinator.com]
    * https://news.ycombinator.com/i... [ycombinator.com]

    • Quick. Someone snag the trademark for "IronOxide".

    • And why are the Rust trademarks an issue in this case? Linux does not plan on releasing a modified version of Rust; they plan on using it to code parts of the kernel. No trademarks are required in that case any more than I need to ask Linus for permission to use my Linux machine.
      • Actually you do need to ask Linus' permission.

        He (and all other contributors) have already granted permission if you follow GPLv2. If you don't follow that the lawyers tend to get involved.

        • I do not have to "ask". Permission to use Linux is granted by the GPL. In the case of trademarks, why is there an issue if Linux only uses Rust in development? Linux is not modifying Rust nor distributing the entire language. Under Apache v2: "6. Trademarks. This License does not grant permission to use the trade names, trademarks, service marks, or product names of the Licensor, except as required for reasonable and customary use in describing the origin of the Work and reproducing the content of the NOTIC

    • Re: (Score:3)

      by Tablizer ( 95088 )

      Logical renaming:
      Linus + Unix = Linux
      Linus + Rust = Lust

      Nevermind, scratch that.

  • ... extend...extinguish. Lets see whether the Linux Kernel will eventually be on MS-crap level. It seems likely of this is not stopped.

    • Re: (Score:2)

      by vadim_t ( 324782 )

      What are you even on about? Rust is a Mozilla project.

    • And how will Rust "extinguish?" It is a programming language. Linux could choose to switch to a new language in the future or even go back to C.
  • You can argue that Rust brings security to the table but it's just an illusion.

    The main objective of Rust is safety, in particular in memory management. It's like saying that unsafe code resides just in the language in which software is implemented.

    Which is a big illusion since producing secure and safe code is not a panacea that lives in a programming language but it is an attitude.

    Rust will not prevent you from making an algorithm that is unsafe, dangerous and could make an airplane crash.

    Eve

    • Rust will not prevent you from making an algorithm that is unsafe, dangerous and could make an airplane crash.

      As far as I know no one has ever stated that the goal of Rust was to prevent all bad code. Certain features in Rust prevent common problems like null pointers by making them difficult to do.

      Even more, Rust will produce a new generation of software developers that will not know how a computer works. Until the computer is reinvented using another paradigm then it's mandatory that software developers get use to the unsafe situations of handling memory.

      Well that is a stretch of logic and a bit elitist. I know lots of programmers who have never coded in assembly or C or C++ but they know how computers work. Java and Python programmers never really concern themselves with garbage collection that C requires. Are they lesser programmers in your eyes?

      Adding in safety featur

      • Antilock braking and air bags does not mean that people no longer have to know how to drive.

        Furthermore ABS and Air bags have saved many thousands of lives. OP is following the same absurd logic that used to be prevalent in the safety industry.

        "Oh you were injured in a car crash? Well that's your fault, you must have been driving like a maniac!"

        It took Ralph Nader's "Unsafe at Any Speed" to cut through this bullshit corporate propaganda that you need to protect users even when they make stupid mistakes.

        Similarly 70% of security problems are memory safety. If Rust reduced our security vulnerabili

      • Re: (Score:2)

        by lsllll ( 830002 )

        I know lots of programmers who have never coded in assembly or C or C++ but they know how computers work.

        * In the voice of Mick Dundee * "That's not a knife. THAT'S a knife!"

        All joking aside, I will put my dollar against yours, in that someone who has never coded in assembly doesn't knows how computers work. How a computer works is in and of itself very multi-leveled. It's one thing to understand how you load a register with a number and use an ADD instruction to add to it, and then it's an entirely different thing to know what the processor actually does when it's running that ADD instruction. Of course m

      • Re: (Score:3)

        by narcc ( 412956 )

        Java and Python programmers never really concern themselves with garbage collection that C requires. Are they lesser programmers in your eyes?

        Yes. If you're using a gc language like Java or Python and you're not thinking about memory, you're definitely a lesser programmer.

      • Re: (Score:2)

        by lsllll ( 830002 )

        Java and Python programmers never really concern themselves with garbage collection that C requires.

        I want to give you the benefit of the doubt that this was a typo, but to make things clear, C does not have a garbage collector. C inherently doesn't have an issue with losing memory associated with objects. The programmer does the job of the garbage collector by freeing allocated memory at the end of routines, whether the routines were successful or not, as long as memory was allocated.

    • If you rely on humans to be perfect, you'll always fail.

      You're essentially saying Rust is pointless because a perfect human wouldn't make mistakes and therefore wouldn't need any of Rust's features. Ok... let the world know when you find this god like mythical developer who never makes a mistake.

      Rust will not prevent you from making an algorithm that is unsafe, dangerous and could make an airplane crash.

      Nobody has ever suggested that Rust will prevent code from crashing.

      Even more, Rust will produce a new generation of software developers that will not know how a computer works.

      These Compilers and high level languages like C will produce a generation of software developers that will not know how a computer works! Everythi

  • Overall, good news. (Score:4, Interesting)

    by Subsentient ( 6901388 ) on Thursday June 23, 2022 @11:02AM (#62644786)
    I like Rust. I also like C++ and C. But, vanilla C is a bit -- tedious -- for some things. As someone who keeps an open mind to both camps, the truth is that Rust is a good language with some serious growing pain issues. Overall, this is good, simply to have a language with support for destructors. I wouldn't be afraid of Rust, I would instead advise learning it and applying pressure to the Rust devs to make it a good systems language. Rust has some glaring issues that can only be addressed by reaching for unsafe, and there are easy-ish solutions to letting you do that stuff without unsafe or Arc or Rc reference-counted smartpointers etc, case in point, self-referential structs. Circular might be an issue, but most of the time I want to make a self-referential struct, I just want to store a child helper class with a reference to its parent in it, which is not, and can be addressed by the borrow checker. I write a lot of Rust and a lot of C++. This isn't nearly as scary as it sounds, and it might finally encourage me to write drivers for Linux.

  • Not C++, just C.

    I know that one big problem is memory management. But is that really an insurmountable issue?

    Sometimes OO is the only practical way to go. But for the Linux kernel, I am not sure it's the best solution.

    • kernels developers traditionally want very tight control over memory management. even with Rust you'll find that developers want to manually manage their allocations and have predictable and bounded behavior in the amount used.

    • The problem is not it is not "insurmountable " as much as why deal with something if you do not have to do so. Also safety features are about preventing or minimizing unforeseen situations. For example, if I do not follow other cars closely why do I need antilock braking? Well the other day, a car made a left turn into me and I almost side swiped it. It was broad daylight, and we were the only two cars on a small, empty neighborhood street. I can only surmise that the other driver was distracted somehow. An

  • Rust won't prevent security vulnerabilities... (Score:3)

    by blahplusplus ( 757119 ) on Thursday June 23, 2022 @12:03PM (#62645014)

    ... because the vulnerabilities stem from CPU design. The way pointers work on current x86 cpu's are the issue, and special secure processors that prevent you from accessing pointers directly and trying to attack and redirect program flow needs to be built into the processor and it costs performance.

    So modern CPU architecture is mostly concerned with speed, and most companies are not going to break compatibility with an entire software ecosystem.

    The whole problem is the way addressing works in most cpu's for most security issues. The rest of a lot of bugs are simply due to programmers not taking into account what variables or types will be passed or how much memory will need to be allocated because they aren't very good programmers. AKA predicting interactions with other programs at scale VS performance.

    In the early days of DOS win 3.1 and fat 16/32 you had to worry about files not writing to disk sometimes properly and you needed to run chkdisk, that mostly doesn't happen on modern NTFS.

Slashdot Top Deals

Economists state their GNP growth projections to the nearest tenth of a percentage point to prove they have a sense of humor. -- Edgar R. Fiedler

Close