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

 



Forgot your password?
typodupeerror
×
Programming Linux

Should the Linux Kernel Accept Drivers Written In Rust? (lwn.net) 169

Packt's recent story about Rust had the headline "Rust is the future of systems programming, C is the new Assembly."

But there was an interesting discussion about the story on LWN.net. One reader suggested letting people write drivers for the Linux kernel in Rust. ("There's a good chance that encouraging people to submit their wacky drivers in Rust would improve the quality of the driver, partly because you can focus attention on the unsafe parts.")

And that comment drew an interesting follow-up:

"I spoke with Greg Kroah-Hartman, and he said he'd be willing to accept a framework in the kernel for writing drivers in Rust, as long as 1) for now it wasn't enabled by default (even if you did "make allyesconfig") so that people don't *need* Rust to build the kernel, and 2) it shows real benefits beyond writing C, such as safe wrappers for kernel APIs."
This discussion has been archived. No new comments can be posted.

Should the Linux Kernel Accept Drivers Written In Rust?

Comments Filter:
  • No, just no (Score:3, Insightful)

    by Anonymous Coward on Saturday August 31, 2019 @05:49PM (#59144722)
    Not "hell no!" but "fuck no!!!". That way lies madness. And systemd and the like.
    • Re: No, just no (Score:2, Insightful)

      If one can not write a driver in C, they should not be near a computer.
      • by lsllll ( 830002 )
        I'm sure you meant to say "If a programmer trying to write a driver cannot write it in C, they should not be near a computer," but it kinda reads like computers should only be used by people who can write drivers in C.
      • If one can not write a driver in C,
        they should not be near a computer.

        I write drivers for a living. It's not hard, but most of them have bugs that are difficult to uncover in testing. The bugs aren't usually significant enough to keep you from getting your computer to work or to get an embedded platform shipped. Usually just horrible security flaws and similar classes of bugs we can ignore for business reasons.

      • In practice, very few people can write 100% correct C, even among Linux kernel developers. I think it's time that we accept that fact and deal with it.

        Take a random Linux driver and carefully check all of its error handlers. I'd say there is a 50% chance it doesn't respond properly or fails to clean up in at least one of them. And that's probably a conservative estimate. (I have actually found and fixed several bugs in Linux.)

        Of course Rust wouldn't be able to catch all of those problems, but cases where fo

      • Perhaps one can write a driver in C but doing so in Rust is more efficient for him.

        Honestly, if someone has an opinion like yours, he should probably not work in the software industry.

        • What you need is to output the intermediate "C" code that the Rust->C translator passes to the "C" compiler, since Rust is not actually a language that compiles to machine code without the aid of a "real" compiler.

  • Ada (Score:5, Informative)

    by Elledan ( 582730 ) on Saturday August 31, 2019 @05:53PM (#59144724) Homepage
    Are drivers written in Ada accepted? If no, then why in Linus' name would a new, unstable and immature language like Rust even be considered?
    • Re:Ada (Score:4, Insightful)

      by gQuigs ( 913879 ) on Saturday August 31, 2019 @06:12PM (#59144768) Homepage

      Someone was working on it... https://github.com/alkhimey/Ad... [github.com]

      If people try it with Ada or Rust or whatever and it's shown to be demonstrably better than C for some use case, more power to them.

    • Re:Ada (Score:4, Informative)

      by roca ( 43122 ) on Saturday August 31, 2019 @10:22PM (#59145126) Homepage

      Rust is significantly safer than Ada. For example, Ada doesn't guarantee freedom from use-after-free bugs, but Rust does. (Well, unless you use the latest Ada-SPARK preview, but that's a lot less mature than Rust, and more burdensome.) UAF is a major source of vulnerabilities both in the Linux kernel and in unsafe languages generally.

      • Which is hilarious because "use after free" bugs are one, single, kind of error.

        It'll stop a buffer from being overrun. It _wont_ stop a routine that assumes "no user id = root permissions". Which shipped in real, production code.

        • Re:Ada (Score:4, Insightful)

          by munch117 ( 214551 ) on Sunday September 01, 2019 @03:57AM (#59145632)

          It _wont_ stop a routine that assumes "no user id = root permissions". Which shipped in real, production code.

          What a terrible language Rust must be. It only stops most of the security problems in C code, not all of them.

    • by Phylter ( 816181 )
      Rust is very immature but it is promising. If it's promises of safer code hold up, and so far it seems to, then it would be a huge benefit to all involved. Maybe it's another 2 - 5 years before Rust is ready but with the support it's starting to gain it might be ideal in that time. It could also end up being a huge flop.
    • by Z00L00K ( 682162 )

      I would also like to consider a microkernel approach for Linux to a greater extent for the future which would make the bulk part of drivers located in userspace or in Ring 2 on Intel processors. (this would of course depend more on which processor architecture you work with.)

      But for the bread and butter part of the kernel I think that using any compiled language that won't create too much overhead and strain on memory management could work. Maybe Fortran for that part of the driver code could prove interest

      • Microkernels are shit. Writing multi-threaded drivers is very difficult, because the separate memory spaces result in decoherence between the threads. Imagine you have a single resource shared by a multi-threaded driver. When one driver thread makes a change to the resource, there is always a delay before this information is distributed to the other drivers, meaning that they will be running with partially outdated information.

        The standard solution by microkernel afficionados is to only implement single thr

        • by Z00L00K ( 682162 )

          That's the price to pay. You can get either high security or high performance, don't expect to get both at the same time. It's all about compromises.

    • by jma05 ( 897351 )

      Ada isn't a zero-cost language. Rust is.

  • Fuck. No. (Score:3, Informative)

    by Anonymous Coward on Saturday August 31, 2019 @05:55PM (#59144734)

    Don't start adding random fucking languages. Port it all together or piss off. Anything else is a maintenance nightmare and very likely doubles the weight of any system software and support infrastructure.

    • Re:Fuck. No. (Score:4, Informative)

      by roca ( 43122 ) on Saturday August 31, 2019 @10:25PM (#59145130) Homepage

      librsvg was recently rewritten in Rust. Did that create a maintenance nightmare and "double the weight of system software and support infrastructure"? No.

      • Re: (Score:3, Informative)

        by theCoder ( 23772 )

        That port has caused problems [lwn.net] for people on lesser used architectures where Rust is not available. That article was from almost a year ago, and I don't know how the issues was resolved, but it shows that changing the language to a new one can cause unexpected maintenance problems.

  • Lame power grab. (Score:5, Insightful)

    by Narcocide ( 102829 ) on Saturday August 31, 2019 @05:57PM (#59144740) Homepage

    WARNING: Some assholes are being paid to overhype Rust as a lame attempt to make everything dependent on it.

    • by roca ( 43122 )

      Who do you think is paying people to overhype Rust?

      • by Z00L00K ( 682162 )

        Today Rust, tomorrow it's Python that's going to be considered for the kernel and then someone thinks it's a good idea to realize Haskell in the kernel.

        Personally I think it could be nice to integrate Fortran in the kernel.

        • Personally I think it could be nice to integrate FORTRAN in the kernel.

          FORTRAN . . . ? What a puny plan! Some brave, daring and unafraid person should rewrite the Linux kernel in APL!

          And extra points for the folks who rewrite it in SNOBOL!

          • by Z00L00K ( 682162 )

            Considering that I have seen an operating system where parts were written in Cobol nothing is sacred.

    • by gweihir ( 88907 )

      Pretty much. Unfortunately, you cannot make fanatics go away. You can just ignore them and their lies.

    • Re:Lame power grab. (Score:4, Informative)

      by Austerity Empowers ( 669817 ) on Saturday August 31, 2019 @11:28PM (#59145266)

      I think they hadn't found a way to carpet bomb everything with "what about rust" in a week, so someone submitted a story with rust in it.

      At some point this stops being amusing and makes me want to avoid the language. If the people using the language are this annoying, I cannot imagine how annoying the language is.

    • WARNING: Some assholes are being paid to overhype Rust as a lame attempt to make everything dependent on it.

      There is definitely a lot of book authors going on frequent conference tours trying to build commercial interest in Rust.

      The functionality of Rust seems fine to me. It's trying to solve some problems that C doesn't address, so it's worth discussing. I think for a mature software codebase that has thousands of contributors we need to consider carefully about using languages that are likely to get breaking changes in the future like Rust (or C++, haha)

    • by jma05 ( 897351 )

      Why was completely unsubstantiated and transparently absurd charge modded up?

  • by CaptainLugnuts ( 2594663 ) on Saturday August 31, 2019 @06:06PM (#59144756)

    If you're too incompetent to write quality code in C you're too incompetent to write kernel code.

    • by ttfkam ( 37064 ) on Saturday August 31, 2019 @06:14PM (#59144772) Homepage Journal

      Right, because none of those Linux kernel coders (and patch reviewers) have ever let a bug get to production before. Certainly no security holes or crashing bugs. No siree!

      • by CaptainLugnuts ( 2594663 ) on Saturday August 31, 2019 @07:10PM (#59144860)

        You've completely missed the point.
        To write high quality kernel code you must fully understand what's going on down inside the processor. As soon as you use a language that tries to hide those necessary details you're going to have issues.

        • by That Ordinary Guy ( 6159720 ) on Saturday August 31, 2019 @07:45PM (#59144908)

          To write high quality kernel code you must fully understand what's going on down inside the processor.

          That's more the compiler or assembly language programmer job. Keep in mind that Linux runs on several types of processors and a kernel developer might not be familiar with all of them.

          But you still have a point; you have to understand basic principles on how machines work. An example of this; I often see developers fetching large result sets into memory then, sending it to the browser afterwards at the presentation layer which makes their applications memory pigs. I often instruct them to change it in code reviews and show them how to; basically, pass the database cursor to the presentation layer and have the presentation layer fetch results one at the time and stream them to the browser right away. The memory used by each result is then freed right away. With large result sets, you can reduce the application memory usage by a factor of 1000 or more thus being able to handle many more concurrent requests before the server runs out of memory. It also makes the application much quicker before it begins to send something to the user, enhancing user experience.

           

          • Re: (Score:3, Insightful)

            If you don't understand pointers or dynamic memory management, Rust is a good language choice because it hides those details.

            But if you don't understand those details, you should not be writing kernel code.

            When you are writing kernel code, you don't want those details hidden.

            • by PPH ( 736903 )

              To take this line of reasoning a bit further: When you are writing kernel code, you are actually implementing dynamic memory management. Using a language which abstracts this isn't going to work.

              It can't be turtles all the way down.

            • by roca ( 43122 ) on Saturday August 31, 2019 @10:35PM (#59145156) Homepage

              > But if you don't understand those details, you should not be writing kernel code.

              That is correct. However, Rust doesn't hide those details. It gives you control over when to dynamically allocate values and when those allocations are freed (e.g. using Box and drop()). You can decide whether you want to use schemes like reference counting (e.g. using Rc or Arc), and if you do, Rust gives you control over when references are acquired or released.

              But unlike C and C++, if you make a mistake that leads to a memory safety bug (e.g. use after free), Rust will reject the code.

        • You've completely missed the point.

          We got your point and it's flat out wrong.

          To write high quality kernel code you must fully understand what's going on down inside the processor.

          That's not even slightly correct. C is not an especially good representation of what is going on down inside the processor, no more than Rust or C++. All of them share a very similar abstract machine.

          As soon as you use a language that tries to hide those necessary details you're going to have issues.

          Well then you're screwed. Even

        • If that was true you would need to write everything in assembler as C indeed hides the processor completely from you.

      • It may be that Rust programmers are also capable of writing bugs. Just a thought.

        In which case, yeah, stick to one language in the kernel.

        • by roca ( 43122 )

          "No language can ensure perfect code, so they're all the same" is nonsense. Languages like Rust prevent important classes of bugs that are common in C, and that's a real advantage.

          • by gweihir ( 88907 )

            Your statement is clueless. Problematic code is written by problematic coders. Do away with one class of bugs and they will just find other ways to do damage.

    • by lucasnate1 ( 4682951 ) on Saturday August 31, 2019 @06:15PM (#59144776) Homepage

      Frankly, if a language appears that produces code as fast as C, but is safer, and faster to develop in, it would be stupid to stick to C just because of some principle that says that one must go through a challenge in order to prove oneself worthy.

      • C isn't more of a challenge than Rust is.

        Though to be fair, it is harder and harder to find good C programmers who aren't creeping up on retirement, especially good C programmers with low level experience (not just some interface glue between components). I don't think that's fixed by having some gung-ho Rust programmers show up and start proselytizing.

        • by roca ( 43122 ) on Saturday August 31, 2019 @10:52PM (#59145186) Homepage

          > C isn't more of a challenge than Rust is.

          Writing C code that is completely free of memory safety bugs and other exploitable vulnerabilities is a huge challenge. It's about as hard as always writing code that is perfectly bug-free. Basically no-one can do it at scale.

          Writing C code that works most of the time and has lots of vulnerabilities is indeed quite easy, and for a long time that was considered good enough. That needs to change.

      • by HiThere ( 15173 ) <charleshixsn@NOSpaM.earthlink.net> on Saturday August 31, 2019 @07:04PM (#59144852)

        Sorry, but no. Better code isn't the only criterion. It's also got to be portable to a wide variety of platforms.

        What they should do is create a Rust to C translation program. That way the "safe Rust code" can be translated into the "portable C code".

        Of course, there's also the problem of maintenance. So the code produced by that translator had better be intelligible. (Even some people produce C code that does the job properly, but is totally unintelligible. So this isn't an added requirement.)

        • What they should do is create a Rust to C translation program

          How is this any different from compiling to LLVM?

          • by HiThere ( 15173 )

            Good C code is directly intelligible to a large number of programmers, and it runs on a lot of computers that LLVM code doesn't run on.

        • by cb88 ( 1410145 )
          Rust is already portable to as many platforms as you can practically run Linux on.... the ones that aren't practical or are more hobbiest, or niche driven (68k , Sparc V8) and won't need drivers written in Rust.
      • The kernel devs need a protective order to keep dimwitted little shits like this away.

        These idiotic hipsters fanboys will sit in dev or other forums spamming their calls to use whatever shit tech they have latched onto relentlessly.

        But why...

        But why...

        But why...

        This is exactly how the systemd fiasco was able to rammed down the Linux world's throats.

      • Re: (Score:3, Interesting)

        Frankly, if a language appears that produces code as fast as C, but is safer, and faster to develop in, it would be stupid to stick to C just because of some principle that says that one must go through a challenge in order to prove oneself worthy.

        Honest question here: wouldn't you have to carry the RUST runtime libs inside the kernel? Or have every driver include its own RUST runtime? KInd of a la docker or what not?
        https://stackoverflow.com/ques... [stackoverflow.com]

        What would be the impact on the kernel? What should we do when the next language comes up? Add its runtime to the kernel too?

        • The honest answer to your question is yes. It is also fair to say that you could find people who don't think there would be any security or performance issues with that. Truthfully, you could probably find someone who would look you in the eye and tell you with a straight face that it would be OK to have the kernel incorporate Javascript and go out to jquery.org each time a particular bit of kernel code ran.
          • by PPH ( 736903 )

            The honest answer to your question is yes.

            Well then, Rust isn't going to be a good fit. Because even C needs to include kernel specific structures and libraries to build kernel components. Basically, a subset of (and different from) the stdlib stuff that userland apps need. I haven't seen any reasonable proposals to build this infrastructure for Rust.

        • by roca ( 43122 ) on Saturday August 31, 2019 @10:58PM (#59145194) Homepage

          Unlike most programming languages, but like C, the Rust standard library is optional. You can write Rust programs that don't use it, and people do.
          https://rust-embedded.github.i... [github.io]
          For example people are writing bootloaders in Rust.
          https://github.com/rust-osdev/... [github.com]

          The people actually working on writing Rust code for the kernel are implement Rust interfaces to the existing kernel libraries.

      • I'm not sure which you are suggesting / confused about.
        Are you thinking it would be a good idea for the kernel to be a mishmash of various languages, with assorted programming paradigms and different ways of doing things?

        Alternatively, is it unclear what the purpose of a kernel is?
        The kernel, of course, does things like translating the logical memory addresses used by userland software into actual physical addresses, controlling which programs can access which portions of memory - including memory locations

      • Frankly, if a language appears that produces code as fast as C, but is safer, and faster to develop in

        That's a woefully incomplete argument. It depends entirely on what you're trying to do with a language, and the lower the level you're working on the less abstract something should be. Rust is safe because it abstracts away and manages many of the things which make C flexible and predictable, not exactly the kind of language you want on the lowest level of the OS just because it is just as fast.

    • Comment removed based on user account deletion
      • by gweihir ( 88907 )

        I do write code that is solid and very security critical in C. It also has high, not negotiable performance requirements and must have both a custom memory management and a low memory footprint. Come to think of it, the Linux kernel would also have pretty much these requirements.

        If you are incompetent enough to call any engineer doing something you cannot do and you do not really understand "incompetent", then the problem is most definitely on your side.

  • Rust is still not compatible itself, it's constantly changing. Wait for the ABIs and the standard to stablize, afterwards, if Rust becomes as popular as C, sure, why not.

  • Nope! (Score:4, Insightful)

    by rlwinm ( 6158720 ) on Saturday August 31, 2019 @06:39PM (#59144800)
    35 year embedded systems veteran. All I have to say is: NOPE! Frankly, if writing in C is the obstacle then you probably shouldn't be down in those layers. Enjoy your HTML and CSS.
  • That won't happen (Score:2, Interesting)

    by guruevi ( 827432 )

    Rust by design won't let you talk directly to hardware. That by itself means you will never get true kernel components in Rust. You'd have to write a barebones module in C that then passes messages to Rust, you've now created basically a userland driver a la FUSE and the whole point of safety within Rust is moot.

    The same thing happened to Python and Java. Super-safe languages, type safety, VM's, safe memory/pointer/heap/stack management but anything relevant, anything interfacing hardware, anything that req

    • The same thing happened to Python and Java. Super-safe languages, type safety, VM's, safe memory/pointer/heap/stack management but anything relevant, anything interfacing hardware, anything that requires performance has to be written in (unsafe) C/C++ making the entire language safety features largely moot.

      Exactly, we have seen this before, there's nothing new here. Leave the kernel alone. Let it do one simple thing and not crowd it with many functionalities in a Jack of all trades scenario :)

      • by Hizonner ( 38491 )

        Um, I'm not saying that more languages should necessarily be thrown in, but the Linux kernel on my machine is like 9MB. Compressed. Plus modules.

        It would be nice to have a simple kernel that does one thing, but Linux would not be that kernel...

    • by gweihir ( 88907 )

      Python is very nice glue code for C modules though!

  • by maz2331 ( 1104901 ) on Saturday August 31, 2019 @07:50PM (#59144916)

    "Safe" languages add too much overhead for the compiled code to be an accurate reflection of what the programmer wrote. As for claims that "C is the new Assembler", that one is bogus - C has always been considered to be "portable Assembler" depending on which features are used.

    • Do you even know what Rust is?
    • I once used Ada to write the operating system and about a dozen drivers for a complex embedded system. It was a requirement. I told many afterwards that during those few years of programming at the device level in Ada, I had spent more time debugging at the assembly code level than when I wrote in any other language including assembly. The reason that happened is exactly as you indicate - the compiled code included a lot of unexpected hits that you just can't tolerate at the device programming level.

    • Rust doesn't add much overhead to the compiled code. The safety happens during compilation, not at runtime. In many cases it's faster than C because the constraints allow the compiler to optimize in ways a C compiler can't.

      I'm not a Rust fanatic. I've just looked into it to see what the fuss was about. You should too. Even if you don't like it, it's good to understand what another language does well.

      • by gweihir ( 88907 )

        I'm not a Rust fanatic. I've just looked into it to see what the fuss was about. You should too. Even if you don't like it, it's good to understand what another language does well.

        It is just one more "Silver Bullet" language that is unlikely to pan out. I have seen quite a few of those. No reason to believe this one is different.

  • I'm working on some new drivers written in LISP.

  • by LynnwoodRooster ( 966895 ) on Saturday August 31, 2019 @08:27PM (#59144962) Journal
    You talk about being close to the hardware, intelligence, consistency, other languages... All that matters is - was the driver written in an environment that was open and supportive of any lifestyle choices of anyone involved? What the driver written with love? Who cares HOW it works, what matters is how people were empowered, embraced, and lifted up when the code was written!
    • Well, I didn't actually write a driver but I was fully inclusive in my not writing of a driver and if anyone tries to imply I didn't write one then I will fully defend myself from the raw violence of their bigotry, racism, white supremacy, and micro aggressions and doxx them. All in the name of inclusiveness and tolerance, of course.
    • by gweihir ( 88907 )

      How can you do that? Is not the very idea of a "driver" that of a "slave driver", i.e. something that orders the hardware around? I think we need to get rid of drivers in the kernel! They are not a solution, they are a problem!

  • Because rust never sleeps.

  • When it comes to kernel development, and to paraphrase Ed Post [mit.edu]: If you can't write for the kernel in C, write it in assembly language. If you can't write for the kernel in assembly language, it isn't worth writing.
  • It would be a dreadful mistake to let in kernel code, inscrutable to most of the developers. C's best use is writing operating systems; use the right toolset for the job.
  • One of the more important and famously touted aspects of open source security that Linux benefits from is the number of eyes reviewing the code. It both makes it harder to plant intentional flaws and less likely for accidental ones to reach release.

    At least in initial deployment, wouldn't this benefit be reduced for Rust code? What percentage of the kernel developers are experts in Rust? What happens when a C developer in one area of the kernel has to debug a problem in which their code is interacting badly

    • by Z00L00K ( 682162 )

      That's why any other language in C should only be considered for userspace or Ring 2 drivers, then the other language module would be isolated.

  • Absolutely. Linux kernel should be coded using the best tool for the job. Which stopped being plain old C more than a decade ago. Linus's protestations notwithstanding. Linus's arguments are purely bogus, withstanding no real scrutiny, and only succeed on the strength of his personality and position, not logic. In other words, Linus is just being a dumb git about this. Again.

  • Just remember: https://en.wikipedia.org/wiki/... [wikipedia.org]

    And I like all the comment in the lwn article from peole that registered to lwn just to say "I love to help" even if they often don't know anything about kernel programming ...

    It looks like the people want it just to increase the visibility of rust, but they don't really care about linux.

  • The absolute majority of negative comments here seem to be from the people who have zero knowledge of Rust, with some pretty silly assumptions and statements that are simply not true, for example that there is a 'safety overhead', that Rust can't talk to hardware directly, that it's irrelevant and a toy language, that it's on CSS/HTML level, etc etc.
  • by lorinc ( 2470890 ) on Sunday September 01, 2019 @03:46AM (#59145614) Homepage Journal

    The linux kernel is currently about 25M lines of code, 2.5M of which are in arch (i.e. very low level code with inline assembly that is not currently supported officially by rust). Mixing language is not a sane option for any project of this size and rewriting the entire thing would cost billions of dollars.

    So the answer is simply no.

    Next (stupid) question (about rust)!

  • Fix the frigging kernel and make a repository system like PIP or maybe more like Nuget to build kernels.

    It's about damn time the Linux kernel was... JUST THE FRIGGING KERNEL and if we're never going to have a standard ABI, there should at the very least be a way to match versions to versions. So, when you open "make menuconfig" for example, it should make use of a repository listing (apt, npm, etc... style) and download a catalog of modules compatible with the given kernel version and when the build starts,
  • Re-read this thread in 5 years time, then again in 5 years time.

Computer programmers never die, they just get lost in the processing.

Working...