7 ms·

So Rust it is then, eh? Could work through the kernel module by module to rewrite it in rust, but it'd be a multi-year process (like Firefox's rewrite has been)

So Rust it is then, eh? Could work through the kernel module by module to rewrite it in rust, but it'd be a multi-year process (like Firefox's rewrite has been).

DigitalJack 9y ago
it's 20 million lines of code.
- monocasa 9y ago
  You could triage. Zorro bus support can probably wait until someone has a specific itch to scratch.
- vilhelm_s 9y ago
  Firefox is 17 million!
  - alphaalpha101 9y ago
    And is not written in Rust, and won't be written in Rust any time soon.
  - mundanevoice 9y ago
    The whole Firefox codebase has not been ported to Rust and will not be anytime soon. So your argument doesn't hold true.
    - daveFNbuck 9y ago
      Isn't that a point in the rewrite's favor? You don't have to port everything to gain a lot of the benefits.
      - mundanevoice 9y ago
        > You don't have to port everything to gain a lot of the benefits. I agree with this. But just saying Firefox has X millions of lines of code doesn't say anything about the possibility for Linux to be ported to Rust.
        craftyguy 9y ago
        you're comparing apples and rutabagas. code line count is a hilariously inaccurate way to measure the complexity required for a portable OS kernel vs a userspace application.
        mundanevoice 9y ago
        > code line count is a hilariously inaccurate way to measure the complexity required for a portable OS kernel vs a userspace application I never said that. My whole premise is that you can't say anything like this by just saying code count on two very different projects. Maybe you didn't read my comments properly.
        daveFNbuck 9y ago
        It does say that the 20 million lines statistic isn't sufficient to dismiss the idea. That's not saying much, but I think it's a valid response to someone pointing out that the Linux kernel is 20 million lines.
      - mfukar 9y ago
        What benefits, precisely, though? New bugs? http://insert-script.blogspot.de/2017/11/firefox-settings-cookie-via-domparser.html http://insert-script.blogspot.de/2017/11/firefox-settings-co...
        irishsultan 9y ago
        What's the relation with Rust? I don't see it mentioned in the post, it affects Firefox before version 57, but not 57 (not that there wasn't any Rust code in Firefox before 57) and it seems to be a bug in DOMParser, which as far as I know is not written in Rust.
        jhasse 9y ago
        Better security. Oh wait ... Chrome still wins although it's written in C++.
  - akmittal 9y ago
    They rewrote 160,000 lines and it took them more than a year > It replaces approximately 160,000 lines of C++ with 85,000 lines of Rust. https://blog.rust-lang.org/2017/11/14/Fearless-Concurrency-In-Firefox-Quantum.html https://blog.rust-lang.org/2017/11/14/Fearless-Concurrency-I...
- staticassertion 9y ago
  Right, but you don't have to rewrite it at once. There are certain areas of the kernel that have historically had more issues, are at higher risk of attack, etc. Those will make up far less code than 20 million lines, and you can start there.
ynezz 9y ago
You mean rewriting unsafe C code to Rust by annotating it with `unsafe` keyword? :-) Try to write in Rust something which would touch bare metal hardware. It would be PITA, it would be full of unsafe keywords and assembler code so it would possibly result in similar amount of bugs in the end, just in different parts.
- dikaiosune 9y ago
  This is empirically not true if you look at the usage of unsafe in pure Rust kernels. Yes, there is assembly needed, and some unsafe Rust code, but it's very possible to wrap up unsafe operations in safe APIs. For example, the kernel repository for Redox (a written-in-Rust OS project) appears to have 242 usages of the unsafe keyword (including comments bc lazy), out of 18205 lines of Rust source.
- red75prime 9y ago
  I can't come up with a situation where C doesn't need inline assembly, while Rust does. Do you have some specific example on your mind?
- zaarn 9y ago
  It's actually not that much unsafe. You can wrap most unsafe operations to be safe with proper checks, I've done it myself and it's much less than you would expect since a lot of the memory accesses can be made safe trivially.
pjmlp 9y ago
Not necessarily, Google's approach has been to forbid kernel access (ChromeOS), to make a big pain to use native code only for specific use cases (Android) or to develop a new microkernel in a mix of C++/Rust/Go/Dart (Fuchsia).
- Rusky 9y ago
  Fuchsia doesn't use Rust.
  - pjmlp 9y ago
    Better inform yourself before posting. https://fuchsia.googlesource.com/garnet/+/HEAD/public/rust/crates https://fuchsia.googlesource.com/garnet/+/HEAD/public/rust/c...
    - Rusky 9y ago
      Those are bindings.
IcePic 9y ago
..and of course Rust needs to be ported and have its .. "runtime" fixed for all platforms linux runs on. Otherwise this will be a decent way to kill off a bunch of platforms.
- koffiezet 9y ago
  Was going to point this out too... Having the Rust compiler support all platforms GCC is able to target is going to be a massive task - nevermind maintaining them. That's one of the main advantages of C - it runs on pretty much everything.
Varriount 9y ago
Seriously? What is it worth people thinking that Rust is the only choice for such things? Memory safety is nothing new. Languages like D, Nim, and Swift all allow for the possibility of both memory safety and low-level access.
- mkesper 9y ago
  Memory safety without GC and with zero-cost abstractions is the combination rust enables. Nim and swift (and Go) strictly require a GC and D without GC doesn't work without heavy lifting.
  - dom96 9y ago
    > Nim and swift (and Go) strictly require a GC and D without GC doesn't work without heavy lifting. I think Nim belongs with D here. You can freely disable the GC in Nim. Full disclosure: I'm a Nim core dev.
  - Varriount 9y ago
    What's wrong with garbage collectors? Depending on the type, you can get performance characteristics better than or similar to destructor-based management. Even current operating systems use forms of garbage collection (such as refcounting) to track resources.
    - jhasse 9y ago
      Most things get moved to the heap.
      - pjmlp 9y ago
        Only in GC languages that don't offer good language features for value types, which usually isn't the case with the ones targeted for low level systems development.
        Rusky 9y ago
ksec 9y ago
Well at least someone is already trying to write an OS with Rust. https://github.com/redox-os/redox https://github.com/redox-os/redox
Santosh83 9y ago
Just to turn this discussion towards the practical aspect: does anyone know if a concrete effort has been made to sound out Torvalds and the other senior kernel devs about accepting Rust into the kernel? I would imagine that initially as PoC one can start by implementing a simple module... obviously a small portion of the Rust stdlib and runtime needs to be ported and of course rustc needs to be integrated into the kernel toolchain... Perhaps someone has done it privately (i.e., without attempting to submit patches back to source)?
- steeleduncan 9y ago
  In [1] (from 2016) he says I don't think you actually solve any of the really hard kernel problems with your choice of programming language. The big problems tend to be about hardware support (all those drivers, all the odd details about different platforms, all the subtleties in memory management and resource accounting) I think what he is saying is that rewriting c->(e.g.) rust doesn't improve make progress on any of the design problems in the linux kernel. In [2] (2013) he expands on that, essentially explaining how well C maps to machine instructions, and how that helps optimise the kernel. Personally I think Rust maps very well to machine code, and although it doesn't solve design problems, I do think it saves a lot of time debugging the security flaws and bugs that can result from memory bugs. [1] https://www.infoworld.com/article/3109150/linux/linux-at-25-linus-torvalds-on-the-evolution-and-future-of-linux.html https://www.infoworld.com/article/3109150/linux/linux-at-25-... [2] https://www.reddit.com/r/programming/comments/1t0gfy/linus_torvalds_on_the_question_if_there_is_a/ https://www.reddit.com/r/programming/comments/1t0gfy/linus_t...
  - Santosh83 9y ago
    I tend to agree with his point that you may perhaps not solve design and driver problems just changing language, but can anyone dispute that a memory-safe language can at least help eliminate routine programming pitfalls like off-by-one, null deferences, double-free and so on? And these are the types of innocuous and inadvertent errors that are exploited by black-hats, sometimes with costly consequences. I don't see a strong argument against a memory-safe language, although granted it won't solve architectural and hardware issues. Perhaps the effort to support, say Rust, in the kernel is just not worth the trade-off at this point? Perhaps no one has taken on the mantle for doing so? But I can't see how one can categorically argue against it...
rurban 9y ago
Rust is not safe. ATS, Pony, C#, Java, lisp come to my mind. But maybe even D, Nim, swift, crystal. Singularity/Midori or the LispM were good candidates. And it cannot be a monolithic kernel of course.

So Rust it is then, eh? Could work through the kernel module by module to rewrite it in rust, but it'd be a multi-year process (like Firefox's rewrite has been).

DigitalJack 9y ago

it's 20 million lines of code.

monocasa 9y ago
You could triage. Zorro bus support can probably wait until someone has a specific itch to scratch.
vilhelm_s 9y ago
Firefox is 17 million!
- alphaalpha101 9y ago
  And is not written in Rust, and won't be written in Rust any time soon.
- mundanevoice 9y ago
  The whole Firefox codebase has not been ported to Rust and will not be anytime soon. So your argument doesn't hold true.
  - daveFNbuck 9y ago
    Isn't that a point in the rewrite's favor? You don't have to port everything to gain a lot of the benefits.
    - mundanevoice 9y ago
      > You don't have to port everything to gain a lot of the benefits. I agree with this. But just saying Firefox has X millions of lines of code doesn't say anything about the possibility for Linux to be ported to Rust.
      - craftyguy 9y ago
        you're comparing apples and rutabagas. code line count is a hilariously inaccurate way to measure the complexity required for a portable OS kernel vs a userspace application.
        mundanevoice 9y ago
        > code line count is a hilariously inaccurate way to measure the complexity required for a portable OS kernel vs a userspace application I never said that. My whole premise is that you can't say anything like this by just saying code count on two very different projects. Maybe you didn't read my comments properly.
      - daveFNbuck 9y ago
        It does say that the 20 million lines statistic isn't sufficient to dismiss the idea. That's not saying much, but I think it's a valid response to someone pointing out that the Linux kernel is 20 million lines.
    - mfukar 9y ago
      What benefits, precisely, though? New bugs? http://insert-script.blogspot.de/2017/11/firefox-settings-cookie-via-domparser.html http://insert-script.blogspot.de/2017/11/firefox-settings-co...
      - irishsultan 9y ago
        What's the relation with Rust? I don't see it mentioned in the post, it affects Firefox before version 57, but not 57 (not that there wasn't any Rust code in Firefox before 57) and it seems to be a bug in DOMParser, which as far as I know is not written in Rust.
      - jhasse 9y ago
        Better security. Oh wait ... Chrome still wins although it's written in C++.
- akmittal 9y ago
  They rewrote 160,000 lines and it took them more than a year > It replaces approximately 160,000 lines of C++ with 85,000 lines of Rust. https://blog.rust-lang.org/2017/11/14/Fearless-Concurrency-In-Firefox-Quantum.html https://blog.rust-lang.org/2017/11/14/Fearless-Concurrency-I...
staticassertion 9y ago
Right, but you don't have to rewrite it at once. There are certain areas of the kernel that have historically had more issues, are at higher risk of attack, etc. Those will make up far less code than 20 million lines, and you can start there.

ynezz 9y ago

You mean rewriting unsafe C code to Rust by annotating it with `unsafe` keyword? :-) Try to write in Rust something which would touch bare metal hardware. It would be PITA, it would be full of unsafe keywords and assembler code so it would possibly result in similar amount of bugs in the end, just in different parts.

dikaiosune 9y ago
This is empirically not true if you look at the usage of unsafe in pure Rust kernels. Yes, there is assembly needed, and some unsafe Rust code, but it's very possible to wrap up unsafe operations in safe APIs. For example, the kernel repository for Redox (a written-in-Rust OS project) appears to have 242 usages of the unsafe keyword (including comments bc lazy), out of 18205 lines of Rust source.
red75prime 9y ago
I can't come up with a situation where C doesn't need inline assembly, while Rust does. Do you have some specific example on your mind?
zaarn 9y ago
It's actually not that much unsafe. You can wrap most unsafe operations to be safe with proper checks, I've done it myself and it's much less than you would expect since a lot of the memory accesses can be made safe trivially.

pjmlp 9y ago

Not necessarily, Google's approach has been to forbid kernel access (ChromeOS), to make a big pain to use native code only for specific use cases (Android) or to develop a new microkernel in a mix of C++/Rust/Go/Dart (Fuchsia).

Rusky 9y ago
Fuchsia doesn't use Rust.
- pjmlp 9y ago
  Better inform yourself before posting. https://fuchsia.googlesource.com/garnet/+/HEAD/public/rust/crates https://fuchsia.googlesource.com/garnet/+/HEAD/public/rust/c...
  - Rusky 9y ago
    Those are bindings.

IcePic 9y ago

..and of course Rust needs to be ported and have its .. "runtime" fixed for all platforms linux runs on. Otherwise this will be a decent way to kill off a bunch of platforms.

koffiezet 9y ago
Was going to point this out too... Having the Rust compiler support all platforms GCC is able to target is going to be a massive task - nevermind maintaining them. That's one of the main advantages of C - it runs on pretty much everything.

Varriount 9y ago

Seriously? What is it worth people thinking that Rust is the only choice for such things? Memory safety is nothing new. Languages like D, Nim, and Swift all allow for the possibility of both memory safety and low-level access.

mkesper 9y ago
Memory safety without GC and with zero-cost abstractions is the combination rust enables. Nim and swift (and Go) strictly require a GC and D without GC doesn't work without heavy lifting.
- dom96 9y ago
  > Nim and swift (and Go) strictly require a GC and D without GC doesn't work without heavy lifting. I think Nim belongs with D here. You can freely disable the GC in Nim. Full disclosure: I'm a Nim core dev.
- Varriount 9y ago
  What's wrong with garbage collectors? Depending on the type, you can get performance characteristics better than or similar to destructor-based management. Even current operating systems use forms of garbage collection (such as refcounting) to track resources.
  - jhasse 9y ago
    Most things get moved to the heap.
    - pjmlp 9y ago
      Only in GC languages that don't offer good language features for value types, which usually isn't the case with the ones targeted for low level systems development.
      - Rusky 9y ago

ksec 9y ago

Well at least someone is already trying to write an OS with Rust. https://github.com/redox-os/redox https://github.com/redox-os/redox

Santosh83 9y ago

Just to turn this discussion towards the practical aspect: does anyone know if a concrete effort has been made to sound out Torvalds and the other senior kernel devs about accepting Rust into the kernel? I would imagine that initially as PoC one can start by implementing a simple module... obviously a small portion of the Rust stdlib and runtime needs to be ported and of course rustc needs to be integrated into the kernel toolchain... Perhaps someone has done it privately (i.e., without attempting to submit patches back to source)?

steeleduncan 9y ago
In [1] (from 2016) he says I don't think you actually solve any of the really hard kernel problems with your choice of programming language. The big problems tend to be about hardware support (all those drivers, all the odd details about different platforms, all the subtleties in memory management and resource accounting) I think what he is saying is that rewriting c->(e.g.) rust doesn't improve make progress on any of the design problems in the linux kernel. In [2] (2013) he expands on that, essentially explaining how well C maps to machine instructions, and how that helps optimise the kernel. Personally I think Rust maps very well to machine code, and although it doesn't solve design problems, I do think it saves a lot of time debugging the security flaws and bugs that can result from memory bugs. [1] https://www.infoworld.com/article/3109150/linux/linux-at-25-linus-torvalds-on-the-evolution-and-future-of-linux.html https://www.infoworld.com/article/3109150/linux/linux-at-25-... [2] https://www.reddit.com/r/programming/comments/1t0gfy/linus_torvalds_on_the_question_if_there_is_a/ https://www.reddit.com/r/programming/comments/1t0gfy/linus_t...
- Santosh83 9y ago
  I tend to agree with his point that you may perhaps not solve design and driver problems just changing language, but can anyone dispute that a memory-safe language can at least help eliminate routine programming pitfalls like off-by-one, null deferences, double-free and so on? And these are the types of innocuous and inadvertent errors that are exploited by black-hats, sometimes with costly consequences. I don't see a strong argument against a memory-safe language, although granted it won't solve architectural and hardware issues. Perhaps the effort to support, say Rust, in the kernel is just not worth the trade-off at this point? Perhaps no one has taken on the mantle for doing so? But I can't see how one can categorically argue against it...

rurban 9y ago

Rust is not safe. ATS, Pony, C#, Java, lisp come to my mind. But maybe even D, Nim, swift, crystal. Singularity/Midori or the LispM were good candidates. And it cannot be a monolithic kernel of course.