17 ms·

Rust in the Linux Kernel: Just the Beginning

222 points by arunc 4y ago

noncoml 4y ago
- krzat 4y ago
  Not sure if it's useful distinction, even if unsafe was removed from the language, it would still need an ability to use libraries written in C.
- Asdrubalini 4y ago
  It’s pretty obvious that the article was talking about safe Rust, which is the default behaviour unless opted out with the scary “unsafe” keyword.
  - Gigachad 4y ago
    We should extend GCC so that every line must be prefixed with "unsafe" so C devs stop getting their knickers in a knot when they see it in Rust.
- noncoml 4y ago
  Why are you booing me? I’m right
  - Ygg2 4y ago
    Just because you write unsafe it's not out of jail free card. Point of unsafe is to say these things _can_ break. Not that these things _will_ break. Calling into unsafe still has to maintain all invariants, so that safe fn wrapping unsafe fn is safe for all possible safe inputs. Point of safe is unless someone fucked in unsafe, these things will never break.
mikymoothrowa 4y ago
- shmerl 4y ago
  Alternatively one can consider that fast adoption driven by marketing isn't a sign of best quality. Take a look at Java.
  - homarp 4y ago
    or Java Script
    - jholman 4y ago
      Weird example. JS took a long time to take off, and had virtually no marketing budget. Or is your point that JS took off despite that, and so maybe is high quality? I think that's wrong too.
      - homarp 4y ago
        JS name was based on Java. Pure marketing name. Launched by Netscape with Sun approval (they used to own the trademark, now it is Oracle) in 95. Netscape had money and marketshare. It was adopted by competing browsers (IE in 96, Opera end of 97) and removed alternatives (perl, tcl, python in browsers (eg https://www.foo.be/docs/tpj/issues/vol2_3/tpj0203-0004.html https://www.foo.be/docs/tpj/issues/vol2_3/tpj0203-0004.html ))
        homarp 4y ago
        As for the quality of JS, there was a reason "JS the good parts" was popular. JS was a quickly made (in 10 days). It showed.
  - winrid 4y ago
    Java is anything but low quality...
orangepanda 4y ago
Is Javascript in Linux kernel an end?
- sph 4y ago
  Of course it is. https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript https://www.destroyallsoftware.com/talks/the-birth-and-death... Jokes aside, I wouldn't be surprised to see WASM in the kernel one day, perhaps to replace eBPF.
  - api 4y ago
    There is at least one WASM runtime for the kernel but not to run WASM in the kernel. It's to have a platform-independent WASM user space.
  - lioeters 4y ago
    > WASM in the kernel This may not be too crazy of an idea, it would enable fine-grained secure sandboxing like what Firefox is doing. Securing Firefox with WebAssembly - https://hacks.mozilla.org/2020/02/securing-firefox-with-webassembly/ https://hacks.mozilla.org/2020/02/securing-firefox-with-weba... Practical third-party library sandboxing with RLBox - https://rlbox.dev/ https://rlbox.dev/
    - mmis1000 4y ago
      Yep. The wasm don't even have a primitive to access to its own executable. Let alone modification and cause RCE. Bound checking definitely have overheads so you wouldn't expect it to suit all workloads, but for most workload the trade-off would be probably acceptable. And it would probably enable a universal linux driver that runs independent to cpu arch.
  - Teknoman117 4y ago
    I highly doubt that. The whole point of eBPF is that it's a limited subset of an execution environment that not only provides a memory safe environment, but just as crucially all eBPF programs are guaranteed to terminate. It's not a general purpose computation environment in a strict sense.
unsafecast 4y ago
I'm opposed to this, and it's not because of some idiologic kernel-should-be-pure-c thing. I'm opposed to it because the rust compiler is slow. And the rust compiler is written in rust. Compiling rust is a nightmare if you don't have a high-end PC. I want to be able to actually compile my software if I wish so. This is becoming increasingly difficult. Rust is adding to the problem.
- _ph_ 4y ago
  While I lack personal experience with Rust and I really appreciate fast compilers (that is why I am a Go user), over all features and characteristics, Rust seems to be the best choice for safe kernel development. Other posters have described well how urgent it is, to improve the security of kernel code. So just not doing anything about this, doesn't seem to be a good option. It seems, there is a wide group of developers which thinks that Rust is the best candidate as a kernel development language. If you see issues with that choice, now would be the time to propose an alternative and try to find momentum in the developer community supporting that alternative. While I also lack practical experience there, by all what I heard, ADA could be one. But I don't know how it exactly compares to Rust and what the trade offs are. But so far, no one has pushed for ADA as a possible kernel implementation language.
- cube00 4y ago
  I'm not sure it's realistic to expect a safety focused compiler to compete with one that doesn't offer those checks. We should aspire to make it as fast but in the short term a slower compiler in exchange for less CVEs and random buffer overrun crashes seems like a reasonable trade off to me. Distributions such as Fedora offer build infrastructure[1] that you can use to compile packages to use in your system for testing if you feel your local hardware isn't powerful enough. [1]: https://copr.fedorainfracloud.org https://copr.fedorainfracloud.org
  - raverbashing 4y ago
    I think it's more related to the grammatical complexity of the language than to safety itself (Same reason why C with typedefs is slower to compile than plain C, why C++ is slower, etc) (that and cargo dependencies, etc - also C compilers have some +30yrs of optimizations)
kalekold 4y ago
Here's Linus' take: You need to realize that (a) reality trumps fantasy (b) kernel needs trump any Rust needs And the reality is that there are no absolute guarantees. Ever. The "Rust is safe" is not some kind of absolute guarantee of code safety. Never has been. Anybody who believes that should probably re-take their kindergarten year, and stop believing in the Easter bunny and Santa Claus. https://lkml.org/lkml/2022/9/19/1105#1105.php https://lkml.org/lkml/2022/9/19/1105#1105.php If you cannot get over the fact that the kernel may have other requirements that trump any language standards, we really can't work together. https://lkml.org/lkml/2022/9/19/1250 https://lkml.org/lkml/2022/9/19/1250
- ducktective 4y ago
  > The "Rust is safe" is not some kind of absolute guarantee of code safety Exactly. Some people act like we don't have the whole branch of "formal proofs" in CS. Memory safety is just once aspect of program safety. Like, IMO, programs written in Coq, F* or even C programs verified by Frama-C are much more "safe" than Rust programs that advertise their "safety" on the mere fact that they are written in Rust.
  - UltraViolence 4y ago
    The reality is that people are adding critical code to the kernel and surrounding infrastructure (OpenSSL) on a Friday night after a long weeks work and never bother to look at it again. We absolutely need something like Rust to cover our backs!
    - pclmulqdq 4y ago
      The idea that Rust can solve this problem is ridiculous to me. The types of bugs that sleep-deprived contributors writing fire-and-forget code will make will just shift to something that the borrow checker doesn't help with.
      - UltraViolence 4y ago
peoplefromibiza 4y ago
isn't this a bit too optimistic? Rust as a language to write kernel drivers for <POPULAR ARCHITECTURE> is a great achievement, but what about all the other architectures that only have a C compiler and do not want/can't to depend on LLVM? What about the billions poured into LLVM that made writing an optimizing Rust compiler possible in reasonable time, that is still written in C++? Lastly, I hope to be wrong on this, but watching at Google history being backed by them is, unfortunately, a course,
- arunc 4y ago
  Compilers are just short running tools. They can hog as much memory for the short period during compilation and die away after that. But a kernel is a critical piece of long software that can have CVE. The criticality is not to have the CVE in the first place.
  - peoplefromibiza 4y ago
    > The criticality is not to have the CVE in the first place. I guess the most critical part of a Linux Kernel is being able to compile it in the first place for the architecture you're using. Virtually every platform/architecture out there provides a C compiler. Can't answer on the CVE part, we have no data to discuss the matter in a meaningful way. There's certainly hope, it doesn't mean data will prove us right.
    - hardware2win 4y ago
      >Can't answer on the CVE part, we have no data to discuss the matter in a meaningful way. We have https://msrc-blog.microsoft.com/2019/07/22/why-rust-for-safe-systems-programming/ https://msrc-blog.microsoft.com/2019/07/22/why-rust-for-safe... https://www.chromium.org/Home/chromium-security/memory-safety/ https://www.chromium.org/Home/chromium-security/memory-safet...
      - peoplefromibiza 4y ago
        There's literally no single data point regarding Rust. You can't compare the number of bugs in a 20 years old C software (C++ in the case of Chrome, which is another beast entirely) with wishful thinking.
irusensei 4y ago
Is that a threat? (don't come at me its just a joke)
- bakugo 4y ago
  It absolutely is written as a threat though, likely intentionally (probably out of spite against anyone who isn't a rust evangelist) and I'm taking it as one.
  - insanitybit 4y ago
    Yes, we are coming for you. Watch your back, HN user "bakugo".
- deleted 4y ago
  [deleted]
- hoseja 4y ago
  Sure sounds like one.
fredoralive 4y ago
I can't wait for all the fun new bugs introduced when subsystems are rewritten in Rust for the sake of it. (OK, a bit sarky, but still, Rust isn't a magic bullet...)
- deleted 4y ago
  [deleted]
- UltraViolence 4y ago
  You're wrong. It IS a magic bullet. Of course it won't fix all those half-assed logical bugs, but it will put an end to memory and thread related bugs, of which there are many.
  - pitaj 4y ago
    Rust also provides a lot of tools that make it easier to avoid logic bugs, like algebraic data types.
  - kalekold 4y ago
    Linus Torvalds disagrees. And the reality is that there are no absolute guarantees. Ever. The "Rust is safe" is not some kind of absolute guarantee of code safety. Never has been. Anybody who believes that should probably re-take their kindergarten year, and stop believing in the Easter bunny and Santa Claus. https://lkml.org/lkml/2022/9/19/1105#1105.php https://lkml.org/lkml/2022/9/19/1105#1105.php
    - UltraViolence 4y ago
      This has nothing to do with 'absolute safety' (whatever that entails) but about vastly increased memory and thread safety compared to C. Torvalds is merely stating the obvious and being a obnoxious dick-head at the same time.
- alkonaut 4y ago
  A bad rewrite from an unsafe to a safe language would mean safety issues traded for logical errors in most cases. Which sounds like a win if you ask me. So even the "rewrite it in Rust, badly" has a decent ring to it tbh (although I'm not arguing there should be a rush to so).
zelly 4y ago
So when do we get the worldwide 0-day caused by a malicious crates package?
- deleted 4y ago
  [deleted]
- nevi-me 4y ago
  The Kernel and say Chromium, don't use crates.io. They (will) vendor what they need, which they can update when they need to and when they've reviewed the dependencies. Unless that 0-day comes from some other software, it seems unlikely that we'll get such a worldwide supply chain issue.
  - bscphil 4y ago
    Firefox, on the other hand, seems to download a ton of Rust packages during the build as opposed to vendoring. (Debian maintains a bunch of hacks to allow vendoring all the Rust components, but this isn't the default or the approach taken by other distros, e.g. Arch Linux.)
    - glandium 4y ago
      No, Firefox vendors everything it uses. Debian has no patches wrt vendoring of Rust code in Firefox. Source: I work for Mozilla and maintain the Debian Firefox package.
      - bscphil 4y ago
        Thank you, I appreciate the correction. Did this change at some point in the past? I seem to remember the Arch Linux package downloading a ton of Rust stuff at one point.
        glandium 4y ago
        No, it has always used vendored crates. Well, technically, it wasn't using vendored crates until https://bugzilla.mozilla.org/show_bug.cgi?id=1298422 https://bugzilla.mozilla.org/show_bug.cgi?id=1298422 , but before that, there were only a limited number of crates in use, and their only dependencies were local, so practically, that's the same thing.
danwee 4y ago
> Miguel has been doing his work under contract with our Prossimo project, which was made possible with generous financial support from Google. Does anyone know how much Google pays for this kind of stuff? And is it like a limited-in-time kind of contract or something similar?
BlinkenBlinken 4y ago
Doesn't solve sloppy programming practices. Being programmed in C or Rust is a non discussion. Using both in the same kernel source complicates code unnecessarily.
- nevi-me 4y ago
  There hasn't been a convincing argument so far that Rust is a net negative for the Rust kernel from a security perspective. Sloppy programming practices and say sloppy review practices will exist in any language. What we're hoping for is fewer "oops, I used that thing after it no longer existed". "Complicates code unnecessarily" can be met with a counter that it's necessary for the memory safety of the future millions of devices out there. If Microsoft and the Linux Kernel release security updates periodically, and people's research says that around 70% of those updates are addressing memory safety issues, "unnecessarily" starts to sound more like a necessity. We have to get to a point where resistance for the sake of resistance becomes unproductive.
- pornel 4y ago
  Rust does prevent a lot of cases of "sloppy" code. In the safe subset sloppy use of pointers won't compile. Destructors run automatically, so even sloppy code is unlikely to leak. Optional and Result types make it harder to be sloppy with error handling. The type system won't let you handwave immutability or thread-safety.
- UltraViolence 4y ago
  I always tend to think: "C is merely high-level assembly" with all the warts and bumps that come with it. C is a poor choice for large software projects, because of its fragility (high-level assembly, remember). The real problem lies in the fact that some obstinate developers refuse to trade even one iota of performance for security. Without that we wouldn't have the mess we're in today! It's relatively easy to develop a programming language that's memory and thread safe, but at the cost of some performance. That's why Rust was developed: to get the same performance as C without the drawbacks. It does this by simply disallowing you to write dangerous code. Underneath it's simply C code, if you will.
dusted 4y ago
Next up, BASIC!
- dusted 4y ago
rust_is_dead 4y ago
kris-nova 4y ago
I’d like to get involved with contributing to the prossimo project like the blog suggested, however there doesn’t seem to be any more information anywhere on memorysafety.org to do so.
UltraViolence 4y ago
IMHO the entire Linux kernel should be rewritten as a microkernel in Rust. Another option would be to use the seL4 kernel and salvage parts of Linux to become device drivers and services.
- deleted 4y ago
  [deleted]
- abenga 4y ago
  No. Write a microkernel in Rust and convince the rest of us to use it.
- smolder 4y ago
  Go ahead, then, and RiiR. (Rewrite it in Rust.) It's not really a novel thought that X thing might be better leveraging Rust's features. The novel thing is actually doing it.
- richard_todd 4y ago
  This comment reminded me of Redox (rust microkernel), which I haven’t looked at in a while. It’s an impressive project, but it was funny to see that in their top news post, one of the items is about tracking down memory-corruption/use-after-free bugs: > “After having thoroughly debugged the orbital/orblogin memory corruption bug with little success, I decided to go as far as phase out the old paging code (ActivePageTable/InactivePageTable/Mapper etc.) in favor of RMM (Redox Memory Manager). Surprisingly, this fixed the bug entirely in the process, and it turns out the issue was simply that parent page tables were not properly unmapped (causing use-after-free), most likely due to the coexistence of RMM and the old paging code, which did not agree on how the number of page table entries were counted.” (https://www.redox-os.org/news/drivers-and-kernel-7/ https://www.redox-os.org/news/drivers-and-kernel-7/) This project surely uses rust more thoroughly and idiomatically than the Linux kernel ever will. And yet here we are with memory corruption and use after free bugs. And the text indicates the bug was so hard to track down that they basically gave up and just replaced the old code. Rust may prove to be beneficial to Linux, but there is too much over-promising hype at this point.
erty546ertey 4y ago

222 points by arunc 4y ago

noncoml 4y ago

krzat 4y ago
Not sure if it's useful distinction, even if unsafe was removed from the language, it would still need an ability to use libraries written in C.
Asdrubalini 4y ago
It’s pretty obvious that the article was talking about safe Rust, which is the default behaviour unless opted out with the scary “unsafe” keyword.
- Gigachad 4y ago
  We should extend GCC so that every line must be prefixed with "unsafe" so C devs stop getting their knickers in a knot when they see it in Rust.
noncoml 4y ago
Why are you booing me? I’m right
- Ygg2 4y ago
  Just because you write unsafe it's not out of jail free card. Point of unsafe is to say these things _can_ break. Not that these things _will_ break. Calling into unsafe still has to maintain all invariants, so that safe fn wrapping unsafe fn is safe for all possible safe inputs. Point of safe is unless someone fucked in unsafe, these things will never break.

mikymoothrowa 4y ago

shmerl 4y ago
Alternatively one can consider that fast adoption driven by marketing isn't a sign of best quality. Take a look at Java.
- homarp 4y ago
  or Java Script
  - jholman 4y ago
    Weird example. JS took a long time to take off, and had virtually no marketing budget. Or is your point that JS took off despite that, and so maybe is high quality? I think that's wrong too.
    - homarp 4y ago
      JS name was based on Java. Pure marketing name. Launched by Netscape with Sun approval (they used to own the trademark, now it is Oracle) in 95. Netscape had money and marketshare. It was adopted by competing browsers (IE in 96, Opera end of 97) and removed alternatives (perl, tcl, python in browsers (eg https://www.foo.be/docs/tpj/issues/vol2_3/tpj0203-0004.html https://www.foo.be/docs/tpj/issues/vol2_3/tpj0203-0004.html ))
      - homarp 4y ago
        As for the quality of JS, there was a reason "JS the good parts" was popular. JS was a quickly made (in 10 days). It showed.
- winrid 4y ago
  Java is anything but low quality...

orangepanda 4y ago

Is Javascript in Linux kernel an end?

sph 4y ago
Of course it is. https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript https://www.destroyallsoftware.com/talks/the-birth-and-death... Jokes aside, I wouldn't be surprised to see WASM in the kernel one day, perhaps to replace eBPF.
- api 4y ago
  There is at least one WASM runtime for the kernel but not to run WASM in the kernel. It's to have a platform-independent WASM user space.
- lioeters 4y ago
  > WASM in the kernel This may not be too crazy of an idea, it would enable fine-grained secure sandboxing like what Firefox is doing. Securing Firefox with WebAssembly - https://hacks.mozilla.org/2020/02/securing-firefox-with-webassembly/ https://hacks.mozilla.org/2020/02/securing-firefox-with-weba... Practical third-party library sandboxing with RLBox - https://rlbox.dev/ https://rlbox.dev/
  - mmis1000 4y ago
    Yep. The wasm don't even have a primitive to access to its own executable. Let alone modification and cause RCE. Bound checking definitely have overheads so you wouldn't expect it to suit all workloads, but for most workload the trade-off would be probably acceptable. And it would probably enable a universal linux driver that runs independent to cpu arch.
- Teknoman117 4y ago
  I highly doubt that. The whole point of eBPF is that it's a limited subset of an execution environment that not only provides a memory safe environment, but just as crucially all eBPF programs are guaranteed to terminate. It's not a general purpose computation environment in a strict sense.

unsafecast 4y ago

I'm opposed to this, and it's not because of some idiologic kernel-should-be-pure-c thing. I'm opposed to it because the rust compiler is slow. And the rust compiler is written in rust. Compiling rust is a nightmare if you don't have a high-end PC. I want to be able to actually compile my software if I wish so. This is becoming increasingly difficult. Rust is adding to the problem.

_ph_ 4y ago
While I lack personal experience with Rust and I really appreciate fast compilers (that is why I am a Go user), over all features and characteristics, Rust seems to be the best choice for safe kernel development. Other posters have described well how urgent it is, to improve the security of kernel code. So just not doing anything about this, doesn't seem to be a good option. It seems, there is a wide group of developers which thinks that Rust is the best candidate as a kernel development language. If you see issues with that choice, now would be the time to propose an alternative and try to find momentum in the developer community supporting that alternative. While I also lack practical experience there, by all what I heard, ADA could be one. But I don't know how it exactly compares to Rust and what the trade offs are. But so far, no one has pushed for ADA as a possible kernel implementation language.
cube00 4y ago
I'm not sure it's realistic to expect a safety focused compiler to compete with one that doesn't offer those checks. We should aspire to make it as fast but in the short term a slower compiler in exchange for less CVEs and random buffer overrun crashes seems like a reasonable trade off to me. Distributions such as Fedora offer build infrastructure[1] that you can use to compile packages to use in your system for testing if you feel your local hardware isn't powerful enough. [1]: https://copr.fedorainfracloud.org https://copr.fedorainfracloud.org
- raverbashing 4y ago
  I think it's more related to the grammatical complexity of the language than to safety itself (Same reason why C with typedefs is slower to compile than plain C, why C++ is slower, etc) (that and cargo dependencies, etc - also C compilers have some +30yrs of optimizations)

kalekold 4y ago

Here's Linus' take: You need to realize that (a) reality trumps fantasy (b) kernel needs trump any Rust needs And the reality is that there are no absolute guarantees. Ever. The "Rust is safe" is not some kind of absolute guarantee of code safety. Never has been. Anybody who believes that should probably re-take their kindergarten year, and stop believing in the Easter bunny and Santa Claus. https://lkml.org/lkml/2022/9/19/1105#1105.php https://lkml.org/lkml/2022/9/19/1105#1105.php If you cannot get over the fact that the kernel may have other requirements that trump any language standards, we really can't work together. https://lkml.org/lkml/2022/9/19/1250 https://lkml.org/lkml/2022/9/19/1250

ducktective 4y ago
> The "Rust is safe" is not some kind of absolute guarantee of code safety Exactly. Some people act like we don't have the whole branch of "formal proofs" in CS. Memory safety is just once aspect of program safety. Like, IMO, programs written in Coq, F* or even C programs verified by Frama-C are much more "safe" than Rust programs that advertise their "safety" on the mere fact that they are written in Rust.
- UltraViolence 4y ago
  The reality is that people are adding critical code to the kernel and surrounding infrastructure (OpenSSL) on a Friday night after a long weeks work and never bother to look at it again. We absolutely need something like Rust to cover our backs!
  - pclmulqdq 4y ago
    The idea that Rust can solve this problem is ridiculous to me. The types of bugs that sleep-deprived contributors writing fire-and-forget code will make will just shift to something that the borrow checker doesn't help with.
    - UltraViolence 4y ago

peoplefromibiza 4y ago

isn't this a bit too optimistic? Rust as a language to write kernel drivers for <POPULAR ARCHITECTURE> is a great achievement, but what about all the other architectures that only have a C compiler and do not want/can't to depend on LLVM? What about the billions poured into LLVM that made writing an optimizing Rust compiler possible in reasonable time, that is still written in C++? Lastly, I hope to be wrong on this, but watching at Google history being backed by them is, unfortunately, a course,

arunc 4y ago
Compilers are just short running tools. They can hog as much memory for the short period during compilation and die away after that. But a kernel is a critical piece of long software that can have CVE. The criticality is not to have the CVE in the first place.
- peoplefromibiza 4y ago
  > The criticality is not to have the CVE in the first place. I guess the most critical part of a Linux Kernel is being able to compile it in the first place for the architecture you're using. Virtually every platform/architecture out there provides a C compiler. Can't answer on the CVE part, we have no data to discuss the matter in a meaningful way. There's certainly hope, it doesn't mean data will prove us right.
  - hardware2win 4y ago
    >Can't answer on the CVE part, we have no data to discuss the matter in a meaningful way. We have https://msrc-blog.microsoft.com/2019/07/22/why-rust-for-safe-systems-programming/ https://msrc-blog.microsoft.com/2019/07/22/why-rust-for-safe... https://www.chromium.org/Home/chromium-security/memory-safety/ https://www.chromium.org/Home/chromium-security/memory-safet...
    - peoplefromibiza 4y ago
      There's literally no single data point regarding Rust. You can't compare the number of bugs in a 20 years old C software (C++ in the case of Chrome, which is another beast entirely) with wishful thinking.

irusensei 4y ago

Is that a threat? (don't come at me its just a joke)

bakugo 4y ago
It absolutely is written as a threat though, likely intentionally (probably out of spite against anyone who isn't a rust evangelist) and I'm taking it as one.
- insanitybit 4y ago
  Yes, we are coming for you. Watch your back, HN user "bakugo".
deleted 4y ago
[deleted]
hoseja 4y ago
Sure sounds like one.

fredoralive 4y ago

I can't wait for all the fun new bugs introduced when subsystems are rewritten in Rust for the sake of it. (OK, a bit sarky, but still, Rust isn't a magic bullet...)

deleted 4y ago
[deleted]
UltraViolence 4y ago
You're wrong. It IS a magic bullet. Of course it won't fix all those half-assed logical bugs, but it will put an end to memory and thread related bugs, of which there are many.
- pitaj 4y ago
  Rust also provides a lot of tools that make it easier to avoid logic bugs, like algebraic data types.
- kalekold 4y ago
  Linus Torvalds disagrees. And the reality is that there are no absolute guarantees. Ever. The "Rust is safe" is not some kind of absolute guarantee of code safety. Never has been. Anybody who believes that should probably re-take their kindergarten year, and stop believing in the Easter bunny and Santa Claus. https://lkml.org/lkml/2022/9/19/1105#1105.php https://lkml.org/lkml/2022/9/19/1105#1105.php
  - UltraViolence 4y ago
    This has nothing to do with 'absolute safety' (whatever that entails) but about vastly increased memory and thread safety compared to C. Torvalds is merely stating the obvious and being a obnoxious dick-head at the same time.
alkonaut 4y ago
A bad rewrite from an unsafe to a safe language would mean safety issues traded for logical errors in most cases. Which sounds like a win if you ask me. So even the "rewrite it in Rust, badly" has a decent ring to it tbh (although I'm not arguing there should be a rush to so).

zelly 4y ago

So when do we get the worldwide 0-day caused by a malicious crates package?

deleted 4y ago
[deleted]
nevi-me 4y ago
The Kernel and say Chromium, don't use crates.io. They (will) vendor what they need, which they can update when they need to and when they've reviewed the dependencies. Unless that 0-day comes from some other software, it seems unlikely that we'll get such a worldwide supply chain issue.
- bscphil 4y ago
  Firefox, on the other hand, seems to download a ton of Rust packages during the build as opposed to vendoring. (Debian maintains a bunch of hacks to allow vendoring all the Rust components, but this isn't the default or the approach taken by other distros, e.g. Arch Linux.)
  - glandium 4y ago
    No, Firefox vendors everything it uses. Debian has no patches wrt vendoring of Rust code in Firefox. Source: I work for Mozilla and maintain the Debian Firefox package.
    - bscphil 4y ago
      Thank you, I appreciate the correction. Did this change at some point in the past? I seem to remember the Arch Linux package downloading a ton of Rust stuff at one point.
      - glandium 4y ago
        No, it has always used vendored crates. Well, technically, it wasn't using vendored crates until https://bugzilla.mozilla.org/show_bug.cgi?id=1298422 https://bugzilla.mozilla.org/show_bug.cgi?id=1298422 , but before that, there were only a limited number of crates in use, and their only dependencies were local, so practically, that's the same thing.

danwee 4y ago

> Miguel has been doing his work under contract with our Prossimo project, which was made possible with generous financial support from Google. Does anyone know how much Google pays for this kind of stuff? And is it like a limited-in-time kind of contract or something similar?

BlinkenBlinken 4y ago

Doesn't solve sloppy programming practices. Being programmed in C or Rust is a non discussion. Using both in the same kernel source complicates code unnecessarily.

nevi-me 4y ago
There hasn't been a convincing argument so far that Rust is a net negative for the Rust kernel from a security perspective. Sloppy programming practices and say sloppy review practices will exist in any language. What we're hoping for is fewer "oops, I used that thing after it no longer existed". "Complicates code unnecessarily" can be met with a counter that it's necessary for the memory safety of the future millions of devices out there. If Microsoft and the Linux Kernel release security updates periodically, and people's research says that around 70% of those updates are addressing memory safety issues, "unnecessarily" starts to sound more like a necessity. We have to get to a point where resistance for the sake of resistance becomes unproductive.
pornel 4y ago
Rust does prevent a lot of cases of "sloppy" code. In the safe subset sloppy use of pointers won't compile. Destructors run automatically, so even sloppy code is unlikely to leak. Optional and Result types make it harder to be sloppy with error handling. The type system won't let you handwave immutability or thread-safety.
UltraViolence 4y ago
I always tend to think: "C is merely high-level assembly" with all the warts and bumps that come with it. C is a poor choice for large software projects, because of its fragility (high-level assembly, remember). The real problem lies in the fact that some obstinate developers refuse to trade even one iota of performance for security. Without that we wouldn't have the mess we're in today! It's relatively easy to develop a programming language that's memory and thread safe, but at the cost of some performance. That's why Rust was developed: to get the same performance as C without the drawbacks. It does this by simply disallowing you to write dangerous code. Underneath it's simply C code, if you will.

dusted 4y ago

Next up, BASIC!

dusted 4y ago

rust_is_dead 4y ago

kris-nova 4y ago

I’d like to get involved with contributing to the prossimo project like the blog suggested, however there doesn’t seem to be any more information anywhere on memorysafety.org to do so.

UltraViolence 4y ago

IMHO the entire Linux kernel should be rewritten as a microkernel in Rust. Another option would be to use the seL4 kernel and salvage parts of Linux to become device drivers and services.

deleted 4y ago
[deleted]
abenga 4y ago
No. Write a microkernel in Rust and convince the rest of us to use it.
smolder 4y ago
Go ahead, then, and RiiR. (Rewrite it in Rust.) It's not really a novel thought that X thing might be better leveraging Rust's features. The novel thing is actually doing it.
richard_todd 4y ago
This comment reminded me of Redox (rust microkernel), which I haven’t looked at in a while. It’s an impressive project, but it was funny to see that in their top news post, one of the items is about tracking down memory-corruption/use-after-free bugs: > “After having thoroughly debugged the orbital/orblogin memory corruption bug with little success, I decided to go as far as phase out the old paging code (ActivePageTable/InactivePageTable/Mapper etc.) in favor of RMM (Redox Memory Manager). Surprisingly, this fixed the bug entirely in the process, and it turns out the issue was simply that parent page tables were not properly unmapped (causing use-after-free), most likely due to the coexistence of RMM and the old paging code, which did not agree on how the number of page table entries were counted.” (https://www.redox-os.org/news/drivers-and-kernel-7/ https://www.redox-os.org/news/drivers-and-kernel-7/) This project surely uses rust more thoroughly and idiomatically than the Linux kernel ever will. And yet here we are with memory corruption and use after free bugs. And the text indicates the bug was so hard to track down that they basically gave up and just replaced the old code. Rust may prove to be beneficial to Linux, but there is too much over-promising hype at this point.

erty546ertey 4y ago