Re: Rust kernel policy - Greg KH
lore.kernel.org

But for new code / drivers, writing them in rust where these types of bugs just can’t happen (or happen much much less) is a win for all of us, why wouldn’t we do this? C++ isn’t going to give us any of that any decade soon, and the C++ language committee issues seem to be pointing out that everyone better be abandoning that language as soon as possible if they wish to have any codebase that can be maintained for any length of time.

Rust also gives us the ability to define our in-kernel apis in ways that make them almost impossible to get wrong when using them. We have way too many difficult/tricky apis that require way too much maintainer review just to “ensure that you got this right” that is a combination of both how our apis have evolved over the years (how many different ways can you use a ‘struct cdev’ in a safe way?) and how C doesn’t allow us to express apis in a way that makes them easier/safer to use. Forcing us maintainers of these apis to rethink them is a GOOD thing, as it is causing us to clean them up for EVERYONE, C users included already, making Linux better overall.

And yes, the Rust bindings look like magic to me in places, someone with very little Rust experience, but I’m willing to learn and work with the developers who have stepped up to help out here. To not want to learn and change based on new evidence (see my point about reading every kernel bug we have.)

Rust isn’t a “silver bullet” that will solve all of our problems, but it sure will help in a huge number of places, so for new stuff going forward, why wouldn’t we want that?

    • HiddenLayer555@lemmy.mlEnglish
      21·
      10 hours ago

      If even senior C developers can and regularly do write critical memory vulnerabilities that can give attackers remote code execution as root, then I’d say it’s indeed already broken.

    • desktop_user@lemmy.blahaj.zone
      41·
      14 hours ago

      that same logic was used by American auto manufacturers, then their vehicles became obsolete as the competition had been improving their designs to be more efficient.

    • OsrsNeedsF2P@lemmy.ml
      41·
      15 hours ago

      People have commented on the stability side, but there’s also the new implementation side. Seasoned developers have hailed Rust as being better for development - look no further than the GPU drivers for an example

    • atzanteol@sh.itjust.worksEnglish
      412·
      2 days ago

      Sounds like something is broken.

      As someone who has seen almost EVERY kernel bugfix and security issue for the past 15+ years (well hopefully all of them end up in the stable trees, we do miss some at times when maintainers/developers forget to mark them as bugfixes), and who sees EVERY kernel CVE issued, I think I can speak on this topic.

      The majority of bugs (quantity, not quality/severity) we have are due to the stupid little corner cases in C that are totally gone in Rust. Things like simple overwrites of memory (not that rust can catch all of these by far), error path cleanups, forgetting to check error values, and use-after-free mistakes. That’s why I’m wanting to see Rust get into the kernel, these types of issues just go away, allowing developers and maintainers more time to focus on the REAL bugs that happen (i.e. logic issues, race conditions, etc.)

    • algernon@lemmy.ml
      311·
      2 days ago

      Considering the amount of CVEs the kernel puts out, I’d argue there’s plenty there that’s broken, and could be fixed by implementing them in a language less broken than C.

      • Auli@lemmy.caEnglish
        31·
        19 hours ago

        But I know my language and never make mistakes. Don’t know how many times I hear that. If that was true we wouldn’t be having by these problems.