24 ms·

Rewrite Linux Kernel in Rust?

200 points by z3phyr 9y ago

wyldfire 9y ago
It would cease to be Linux, but by all means -- make it so! BTW Redox OS (written in rust) originally supported Linux syscalls which I thought was a super cool feature. Jorge Aparicio started steed, a libc implemented in rust for rust. It seems like a pretty interesting approach.
- fjallidergodur 9y ago
  Author said: Thank you. Actually, I have a series of articles about a libc written in Rust for Rust which I started writing before steed was published, and… isn’t finished yet. :-/ But maybe, I will finish and publish it eventually…
jlrubin 9y ago
This was a fun write up. On the off chance the author is reading the comments here, there are a couple security features they need to add for it to be more complete (I'm probably missing some things). 1) They should add a call to access_ok(VERIFY_WRITE, pointer, mem::size_of<Syscall>()) in rust_syscall_handle to ensures that the user space pointer points to valid userspace memory of the right shape for the syscall type. 2) They should sanitize (hopefully, using some zero-cost method) the Syscall type to guarantee that it is well-formed before calling handle. If the userspace constructs some normally impossible to construct Syscall, it's unclear how a rust match pattern handles it (i.e., if an enum has only 3 types and you pass in a falsely constructed variant with tag 100 is match guaranteed not to just be using a jump table and accidentally jump 100 instructions?)
- masklinn 9y ago
  Don't know about HN but a friend of the author posted this on reddit and was commenting there: https://www.reddit.com/r/programming/comments/6f235k/rewrite_the_linux_kernel_in_rust/dif9prj/ https://www.reddit.com/r/programming/comments/6f235k/rewrite... edit: they also submitted it on HN, but it looks like they didn't get the "winning" submission: https://news.ycombinator.com/submitted?id=fjallidergodur https://news.ycombinator.com/submitted?id=fjallidergodur
  - fjallidergodur 9y ago
    I am said friend, we're reading the discussion.
jclulow 9y ago
I wonder what makes AT&T assembly syntax "objectively crap".
- colejohnson66 9y ago
  You need to explicitly specify what the parameter sizes and types are. Plus, the parameters are backwards compared to Intel syntax: Intel: mov eax, 5 AT&T: movl $5, %eax In basically every C-like programming language, you assign 5 to eax with `eax=5` not `5=eax`. I can also tell that I'm working with the `long` variant of `mov` just by looking at the types involved. Intel's syntax for memory access seems more natural. If I don't want to add `ebx` to the address, I can leave it out; I can't in AT&T; I have to have this seemingly random comma. Plus, what's with the format? Intel: mov eax, [ds:eax*4+16] AT&T: movl ds:16(,%eax,4)
  - ajross 9y ago
    Interestingly, in the language you actually wrote that complaint in: > you assign 5 to eax AT&T speaks English, basically. We move A to B. Destination goes last. Both seem sane enough. And in fact both get really balled up when you have three and four-argument instructions.
    - colejohnson66 9y ago
      I'll grant that, but it's a programming language, so I kind of expect it to follow the order assignment does when I write in C++, C#, etc.
      - ajross 9y ago
        AT&T assembly style significantly predates C++ (and C# by like two decades), and co-evolved with C. And strictly this isn't an assignment, anyway. Assignment is an abstract operation in a programming language. This is a machine instruction[1] for a physical machine, which does exactly one thing. [1] Pause while the peanut gallery points out that in fact there are like ninety six different instructions in x86 called some variant of "MOV". Yeah, yeah, we know.
im_down_w_otp 9y ago
Pretty cool. I decided to take a similar path in trying to improve/ensafen parts of the BEAM VM by finding small chunks I could rewrite in Rust from C. Most of the headache was build toolchain integration stuff. I did manage to get a few simple things slotted in that appear to work transparently, which made me hopeful for future more complicated things to play with like new process mailbox implementations, etc. Anyway, great write up and a cool project!
- delhanty 9y ago
  That sounds like another nice idea. What happened to your project?
  - im_down_w_otp 9y ago
    Ongoing, but BEAM is no longer part of my day job (though Rust is), so it's slower going and only moves occasionally forward between the hours of 12am and 3am when the rest of my family is asleep.
    - delhanty 9y ago
      Thank you. I was just reading your comments and found this one: >Erlang: the general disinterest of Ericsson and the hapless stewardship of Erlang Solutions. Is that related to the reason that BEAM is no longer part of your day job? The reason I ask is that I am thinking of starting a new project with BEAM, maybe some Rust or C++ and wondering whether Elixir has taken over from Erlang due to the disinterest of Ericsson.
      - im_down_w_otp 9y ago
        Nope, not the reason. My "go-to" language when prototyping most things is still Erlang. Erlang is by far my favorite language and environment to use, and for a whole slew of things I'd still grab it for production projects/products. I moved into the world of autonomous vehicle runtime software, and tools closer to the metal with deterministic timing characteristics are a requirement.
throwaway-1209 9y ago
Let's see what Linus thinks about this.
- deleted 9y ago
  [deleted]
- astrobe_ 9y ago
  Probably the same as the author of curl. Something along the lines of "Yes, sure, our project is open source so fork it and go ahead".
  - throwaway-1209 9y ago
    "And don't call it Linux because I own the trademark".
AWildDHHAppears 9y ago
Do it in .net That would be useful
kbenson 9y ago
Without making any assertions as to the benefits or problems of integrating Rust into the Linux kernel to replace components, I just want to point out it's really cool that you can and that someone has gone through the trouble of documenting how. That's just awesome. Discussion about whether this is a good idea or not, and the problems of doing so, can now commence in earnest, and without the pesky problem of it being mostly theoretical.
- Jach 9y ago
  Yeah it's always great to see concepts implemented and working. My favorite similar project I would use as an argument to bring Nim into a legacy C codebase is https://github.com/ckkashyap/nimxv6 https://github.com/ckkashyap/nimxv6 which started off by taking the xv6 kernel and replacing uart.c with uart.nim. Every step of the way you can test your translation was correct, and once you have Nim in the build process you can start using it for new things too.
  - meditationapp 9y ago
    Do you get anything with him? I was under the impression dereference safety wasn't a priority.
    - kbenson 9y ago
      Debatedly, you get a better stdlib and some usability features.
    - Jach 9y ago
      Nim or Rust might be appropriate depending on the project. To me the idea of replacing C with either of them comes down to a value-sell of how much you value Rust's safety guarantees and whether you're willing to make the investment of learning to use it or if you're just going to wrap everything in unsafe{}. Considering you're talking to C programmers, I don't think they value that safety very much. If they did, at least compared to other values, they'd have moved to a GC language like Java long ago, or at least a C++-subset-with-rules. So Nim has a lot of nice features that they might like and expect from modern higher level languages, a lot you can use even if you alloc() everywhere and avoid the GC, which you can do because it has an optional and implementation-swappable GC. And it's not like Nim is just as unsafe as C if you don't use the GC, the compiler stops you from shooting yourself in the foot for a lot of things plus there are some good (tunable) defaults on runtime behavior. Finally the ramp-up time to get productive in Nim, and ongoing development effort, is probably less than Rust, which will help the sell too.
polygot 9y ago
This is an interesting idea, but probably won't work out because Linus (and other developers) may not want to transition away from the C language (see Linus's comments about not using C++.) I think it would be excellent to see Rust being used, but the implementation of replacing C with Rust could be very complicated, and Rust's benefits may not be directly visible when having to port/rewrite a lot of the components.
- ktta 9y ago
  I mean, the advantages of C++ are complexity management and the downside is its abstractness which is what Linus' argument was about (It is a behemoth compared to C therefore easy to make mistakes). Rust might prove to be a possible candidate because it can help with safety. This is a different rationale than what the argument for C++ was about, so we cannot say. The bigger problem I see is how premature the Rust eco-system and understanding is. It needs to go quite a long way people people start believing in it and before the language is well understood by more than a niche group of people who learn it just out of interest.
- shmerl 9y ago
  Rust doesn't have downsides of C++ by design.
  - jfoutz 9y ago
    Yet. I like rust. It has a deep, thoughtful approach to many problems. But, C++ is pretty long in the tooth. Of course it's weird and inconsistent. Give rust 30 years to really entrench itself as a systems language. It'll be wierd also.
- paulddraper 9y ago
  And GNU Herd weren't on board with creating a monolithic kernel. So what? It got built.
  - wangii 9y ago
    you mean GNU HURD?
lacampbell 9y ago
What is the rust communities obsession with suggesting (threatening?) rewrites of battle tested C programs that have been around for decades? Now a kernel for a new OS, that'd be something.
- dbaupp 9y ago
  The article covers both of your points: > Rust is supposed to be an excellent systems programming language, having the ability to go extremely close to the bare metal, while offering a thick layer of security and expressiveness which C lacks of. And such an assumption has to be trialled! > Which Philipp Oppermann has already done by beginning to write a real OS in Rust and writing about it. But this is not a realistic trial: an OS starting from scratch has almost zero chance to end up being finished, not to mention being actually used on real machines. That is, a more accurate title might be "Proof of concept of incrementally rewriting the Linux kernel in Rust".
- nickpsecurity 9y ago
  I provoked some solid answers from team members on that in this thread: https://lobste.rs/s/ldnlos/have_you_considered_rewriting_it_rust https://lobste.rs/s/ldnlos/have_you_considered_rewriting_it_... Skade even dropped a HOWTO in one comment on replicating much of their community results in other projects. There's plenty of data from team members to look at there where I'll let the rest of you make decisions about it on your own.
deleted 9y ago
[deleted]
Animats 9y ago
I'd rather see a rewrite of QNX in Rust, as open source. The QNX kernel isn't very large, but it offers most of POSIX, so you can run programs on it. (L4 is nice, but it does so little that people just use it as a hypervisor to run Linux. This doesn't simplify the problem.) If you rewrite the Linux kernel in Rust, one module at a time, you'll just end up with C written in Rust syntax, with raw pointers all over the place.
- rbjorklin 9y ago
  I was thinking the same thing but for http://www.minix3.org/ http://www.minix3.org/
  - agumonkey 9y ago
    fun anecdote, it seems that minix3 is the ancestor of the OS running in Intel Management Engine http://blog.ptsecurity.com/2017/04/intel-me-way-of-static-analysis.html http://blog.ptsecurity.com/2017/04/intel-me-way-of-static-an...
- i336_ 9y ago
  QNX is also realtime. In order to provide realtime guarantees that cover small latencies, you need infrastructure that generates as few instructions as possible. (If you have lots of instructions you can hit targets of a hundreds of microseconds since you can just wait. Start inching toward nanoseconds, though, and the scheduler's own execution will get in the way unless it's crazy compact.) The reason I mention this is that QNX runs on a variety of embedded devices (http://qnx.symmetry.com.au/ http://qnx.symmetry.com.au/ has an interesting list, universal remotes particularly jumped out at me) which are traditionally quite slow. What's Rust like in terms of generating code that's consistently compact?
  - mafribe 9y ago
    What's Rust like in ... Isn't that less a question of Rust (which due to its affine types, should be usable for generating code with predictable performance) but of compilers? It should be possible to write a Rust compiler that optimises for predictable performance at the cost of speed.
amluto 9y ago
> (*pointer).handle(); Eek! That is, indeed, unsafe. But this shouldn't be messing with the entry asm at all. Just add your new syscall to the syscall table, just like any other syscall.
martamoreno 9y ago
It's a fun idea and many people have had it first thing when they heard of Rust... So why did no one do it? Quite simply: No one is going to rewrite the Linux Kernel in Rust. It is far too big and also you are not solving any real issues either. Rust only protects you from a small fraction of errors and while for an application like a browser, this can be a big gain, I would argue that it is negligible for a kernel in general. Reasons being that all the device IO, component interaction, privilege escalations, logical errors, hardware errors, firmware errors/bugs all can NOT be addressed by rust. Even for a browser, Rust is only a band-aid. The amount of logical errors and security holes in something as complex as a modern web-browser is more than enough of an attack surface. No need for a rouge pointer to weird memory. What is MUCH more viable though is a project to compartmentalize the Linux Kernel into HVMs. I forgot the name but there are efforts to put nearly everything into its own HVM. Which means if the printer driver goes nuts, it can't really do anything to your system except not print anymore. If your graphics driver goes nuts, well then you won't see anything... And so on. This means, almost no code rewrites and still MUCH higher protection than RUST. Rust does not compartmentalize. If any of your system components is fucked, your whole system is still fucked. That is why it's pointless to rewrite a kernel because of a language. You need to compartmentalize it... Look at QubesOS for an early user-space effort. Would be nice to have a Qubes-Kernel too.
- i336_ 9y ago
  You're referring to microkernel/nanokernel architectures. Linus famously shunned Andrew Tanenbaum's MINIX kernel design and argued in favor of a monolithic kernel, where buggy printer drivers live in the same memory space and have the same elevated privileges as the code that manages the kernel's secure crypto key ring. Linus is also noted in this thread as not being interested in security issues. I do agree with you about Rust not solving the hardware problem.
  - martamoreno 9y ago
    Yes it also makes sense. Because no matter what you do, it is unlikely that your are able to compartmentalize something so critical and raw as a device driver. If that one is fucked, the reason is likely that your system is already compromised. It was just an example of what WOULD be more viable and effective than rewriting it in Rust. I still think that QubesOS is taking the right approach. Initially assume hardware & kernel as trusted and make sure that this trust then can not be violated from the outside (TPM, SecureBoot, VMs for each app, etc.). I just wish more people would focus on that promising approach.
based2 9y ago
-> https://mirage.io/ https://mirage.io/
youdontknowtho 9y ago
I guess one of the things that always comes to mind when someone brings up "Rust all the things" is that it assumes that anything that can be expressed in C can be expressed in Rust with the safety features enabled. Rust wouldn't have a mechanism to do unsafe code otherwise, right? I think it might be more complicated than we might think initially. I personally think that someone should probably spend some more time on GC that's performant enough for systems code. My convictions haven't driven me to do anything about it, however.
- Retra 9y ago
  Safe rust clearly cannot express everything that can be expressed in C. It cannot even express everything that is safe in general. But "the safety features of Rust" includes drawing a barrier between the safe parts of your code and the unsafe parts. There is significant value in that compartmentalization. Moreover, you are assuming that things written unsafely in C should be written identically in rust, when there very well could be more idiomatic, modern ways to do the same thing without any unsafety at all.
  - youdontknowtho 9y ago
    There are modern ways to express something safely that is written unsafely in C. What Rust evangelists seem to forget is that there have been ways to do that for a long time. The article actually has very little safe Rust in it. It makes me wonder what we are gaining? If the idea is that introducing Rust means that later you can go back and add type and memory safety...why not use C++ in a type and safe by construction way? Why not use Safe D? I'm personally just looking forward to the hype dying down. I'm tired of hearing about it, and most of the time I just click "hide" on Rust articles because I'm not interested and people are starting to sound pretty shrill.
    - Retra 9y ago
      Have you ever written anything in Rust?
FrozenVoid 9y ago
>Rewrite Linux Kernel in Rust? Rust has no backward compatibility: C code compiles fine after decades. It would be a waste of time to rewrite Linux in Rust when the resulting code has a lifetime of few months until it won't compile and start breaking everywhere.
- vog 9y ago
  > C code compiles fine after decades Early C code doesn't compile on modern systems at all. Speaking of early C code, every vendor had their own version. C standardization had to go a long way. Even today, writing portable C code is hard. Need a portable 128-bit integer? Good luck on Windows. Need a portable 32-bit integer? Better take a C implementation that provides int32_t, because just using "int" bites you when switching from 32-bit to 64-bit platforms. Oh, and int32_t was introduced in C99, which is not exactly "decades" ago, but admittedly that was 18 years ago. However, I wouldn't bet on portability of any code older than that, unless the authors of that C code were extremely careful and anticipatory. But then, with enough effort (and perhaps code generation), you can create portable code in any language. Rust skips all that mess, by having a clear experimental phase in the 0.x versions. It became stable with a clear commitment to backwards compatibility since 1.0, which was released in 2015.
  - tom_mellior 9y ago
    > Need a portable 32-bit integer? Better take a C implementation that provides int32_t, because just using "int" bites you when switching from 32-bit to 64-bit platforms. Citation needed. Which compilers for which machines are you talking about? I don't think any change the size of int. What does break is the assumption that int is the same size as pointers, but that's because the sizes of pointers change.
    - vog 9y ago
      Whoops. I meant 16-bit versus 32-bit integers, when switching from 16-bit to 32-bit systems. Sorry for the confusion. Fortunately, they didn't repeat that mess for 32/64 bits, at least not for integers, but "decades old code" is still affected.

200 points by z3phyr 9y ago

It would cease to be Linux, but by all means -- make it so! BTW Redox OS (written in rust) originally supported Linux syscalls which I thought was a super cool feature. Jorge Aparicio started steed, a libc implemented in rust for rust. It seems like a pretty interesting approach.

fjallidergodur 9y ago
Author said: Thank you. Actually, I have a series of articles about a libc written in Rust for Rust which I started writing before steed was published, and… isn’t finished yet. :-/ But maybe, I will finish and publish it eventually…

jlrubin 9y ago

This was a fun write up. On the off chance the author is reading the comments here, there are a couple security features they need to add for it to be more complete (I'm probably missing some things). 1) They should add a call to access_ok(VERIFY_WRITE, pointer, mem::size_of<Syscall>()) in rust_syscall_handle to ensures that the user space pointer points to valid userspace memory of the right shape for the syscall type. 2) They should sanitize (hopefully, using some zero-cost method) the Syscall type to guarantee that it is well-formed before calling handle. If the userspace constructs some normally impossible to construct Syscall, it's unclear how a rust match pattern handles it (i.e., if an enum has only 3 types and you pass in a falsely constructed variant with tag 100 is match guaranteed not to just be using a jump table and accidentally jump 100 instructions?)

masklinn 9y ago
Don't know about HN but a friend of the author posted this on reddit and was commenting there: https://www.reddit.com/r/programming/comments/6f235k/rewrite_the_linux_kernel_in_rust/dif9prj/ https://www.reddit.com/r/programming/comments/6f235k/rewrite... edit: they also submitted it on HN, but it looks like they didn't get the "winning" submission: https://news.ycombinator.com/submitted?id=fjallidergodur https://news.ycombinator.com/submitted?id=fjallidergodur
- fjallidergodur 9y ago
  I am said friend, we're reading the discussion.

jclulow 9y ago

I wonder what makes AT&T assembly syntax "objectively crap".

colejohnson66 9y ago
You need to explicitly specify what the parameter sizes and types are. Plus, the parameters are backwards compared to Intel syntax: Intel: mov eax, 5 AT&T: movl $5, %eax In basically every C-like programming language, you assign 5 to eax with `eax=5` not `5=eax`. I can also tell that I'm working with the `long` variant of `mov` just by looking at the types involved. Intel's syntax for memory access seems more natural. If I don't want to add `ebx` to the address, I can leave it out; I can't in AT&T; I have to have this seemingly random comma. Plus, what's with the format? Intel: mov eax, [ds:eax*4+16] AT&T: movl ds:16(,%eax,4)
- ajross 9y ago
  Interestingly, in the language you actually wrote that complaint in: > you assign 5 to eax AT&T speaks English, basically. We move A to B. Destination goes last. Both seem sane enough. And in fact both get really balled up when you have three and four-argument instructions.
  - colejohnson66 9y ago
    I'll grant that, but it's a programming language, so I kind of expect it to follow the order assignment does when I write in C++, C#, etc.
    - ajross 9y ago
      AT&T assembly style significantly predates C++ (and C# by like two decades), and co-evolved with C. And strictly this isn't an assignment, anyway. Assignment is an abstract operation in a programming language. This is a machine instruction[1] for a physical machine, which does exactly one thing. [1] Pause while the peanut gallery points out that in fact there are like ninety six different instructions in x86 called some variant of "MOV". Yeah, yeah, we know.

im_down_w_otp 9y ago

Pretty cool. I decided to take a similar path in trying to improve/ensafen parts of the BEAM VM by finding small chunks I could rewrite in Rust from C. Most of the headache was build toolchain integration stuff. I did manage to get a few simple things slotted in that appear to work transparently, which made me hopeful for future more complicated things to play with like new process mailbox implementations, etc. Anyway, great write up and a cool project!

delhanty 9y ago
That sounds like another nice idea. What happened to your project?
- im_down_w_otp 9y ago
  Ongoing, but BEAM is no longer part of my day job (though Rust is), so it's slower going and only moves occasionally forward between the hours of 12am and 3am when the rest of my family is asleep.
  - delhanty 9y ago
    Thank you. I was just reading your comments and found this one: >Erlang: the general disinterest of Ericsson and the hapless stewardship of Erlang Solutions. Is that related to the reason that BEAM is no longer part of your day job? The reason I ask is that I am thinking of starting a new project with BEAM, maybe some Rust or C++ and wondering whether Elixir has taken over from Erlang due to the disinterest of Ericsson.
    - im_down_w_otp 9y ago
      Nope, not the reason. My "go-to" language when prototyping most things is still Erlang. Erlang is by far my favorite language and environment to use, and for a whole slew of things I'd still grab it for production projects/products. I moved into the world of autonomous vehicle runtime software, and tools closer to the metal with deterministic timing characteristics are a requirement.

throwaway-1209 9y ago

Let's see what Linus thinks about this.

deleted 9y ago
[deleted]
astrobe_ 9y ago
Probably the same as the author of curl. Something along the lines of "Yes, sure, our project is open source so fork it and go ahead".
- throwaway-1209 9y ago
  "And don't call it Linux because I own the trademark".

AWildDHHAppears 9y ago

Do it in .net That would be useful

kbenson 9y ago

Without making any assertions as to the benefits or problems of integrating Rust into the Linux kernel to replace components, I just want to point out it's really cool that you can and that someone has gone through the trouble of documenting how. That's just awesome. Discussion about whether this is a good idea or not, and the problems of doing so, can now commence in earnest, and without the pesky problem of it being mostly theoretical.

Jach 9y ago
Yeah it's always great to see concepts implemented and working. My favorite similar project I would use as an argument to bring Nim into a legacy C codebase is https://github.com/ckkashyap/nimxv6 https://github.com/ckkashyap/nimxv6 which started off by taking the xv6 kernel and replacing uart.c with uart.nim. Every step of the way you can test your translation was correct, and once you have Nim in the build process you can start using it for new things too.
- meditationapp 9y ago
  Do you get anything with him? I was under the impression dereference safety wasn't a priority.
  - kbenson 9y ago
    Debatedly, you get a better stdlib and some usability features.
  - Jach 9y ago
    Nim or Rust might be appropriate depending on the project. To me the idea of replacing C with either of them comes down to a value-sell of how much you value Rust's safety guarantees and whether you're willing to make the investment of learning to use it or if you're just going to wrap everything in unsafe{}. Considering you're talking to C programmers, I don't think they value that safety very much. If they did, at least compared to other values, they'd have moved to a GC language like Java long ago, or at least a C++-subset-with-rules. So Nim has a lot of nice features that they might like and expect from modern higher level languages, a lot you can use even if you alloc() everywhere and avoid the GC, which you can do because it has an optional and implementation-swappable GC. And it's not like Nim is just as unsafe as C if you don't use the GC, the compiler stops you from shooting yourself in the foot for a lot of things plus there are some good (tunable) defaults on runtime behavior. Finally the ramp-up time to get productive in Nim, and ongoing development effort, is probably less than Rust, which will help the sell too.

polygot 9y ago

This is an interesting idea, but probably won't work out because Linus (and other developers) may not want to transition away from the C language (see Linus's comments about not using C++.) I think it would be excellent to see Rust being used, but the implementation of replacing C with Rust could be very complicated, and Rust's benefits may not be directly visible when having to port/rewrite a lot of the components.

ktta 9y ago
I mean, the advantages of C++ are complexity management and the downside is its abstractness which is what Linus' argument was about (It is a behemoth compared to C therefore easy to make mistakes). Rust might prove to be a possible candidate because it can help with safety. This is a different rationale than what the argument for C++ was about, so we cannot say. The bigger problem I see is how premature the Rust eco-system and understanding is. It needs to go quite a long way people people start believing in it and before the language is well understood by more than a niche group of people who learn it just out of interest.
shmerl 9y ago
Rust doesn't have downsides of C++ by design.
- jfoutz 9y ago
  Yet. I like rust. It has a deep, thoughtful approach to many problems. But, C++ is pretty long in the tooth. Of course it's weird and inconsistent. Give rust 30 years to really entrench itself as a systems language. It'll be wierd also.
paulddraper 9y ago
And GNU Herd weren't on board with creating a monolithic kernel. So what? It got built.
- wangii 9y ago
  you mean GNU HURD?

lacampbell 9y ago

What is the rust communities obsession with suggesting (threatening?) rewrites of battle tested C programs that have been around for decades? Now a kernel for a new OS, that'd be something.

dbaupp 9y ago
The article covers both of your points: > Rust is supposed to be an excellent systems programming language, having the ability to go extremely close to the bare metal, while offering a thick layer of security and expressiveness which C lacks of. And such an assumption has to be trialled! > Which Philipp Oppermann has already done by beginning to write a real OS in Rust and writing about it. But this is not a realistic trial: an OS starting from scratch has almost zero chance to end up being finished, not to mention being actually used on real machines. That is, a more accurate title might be "Proof of concept of incrementally rewriting the Linux kernel in Rust".
nickpsecurity 9y ago
I provoked some solid answers from team members on that in this thread: https://lobste.rs/s/ldnlos/have_you_considered_rewriting_it_rust https://lobste.rs/s/ldnlos/have_you_considered_rewriting_it_... Skade even dropped a HOWTO in one comment on replicating much of their community results in other projects. There's plenty of data from team members to look at there where I'll let the rest of you make decisions about it on your own.

deleted 9y ago

[deleted]

Animats 9y ago

I'd rather see a rewrite of QNX in Rust, as open source. The QNX kernel isn't very large, but it offers most of POSIX, so you can run programs on it. (L4 is nice, but it does so little that people just use it as a hypervisor to run Linux. This doesn't simplify the problem.) If you rewrite the Linux kernel in Rust, one module at a time, you'll just end up with C written in Rust syntax, with raw pointers all over the place.

rbjorklin 9y ago
I was thinking the same thing but for http://www.minix3.org/ http://www.minix3.org/
- agumonkey 9y ago
  fun anecdote, it seems that minix3 is the ancestor of the OS running in Intel Management Engine http://blog.ptsecurity.com/2017/04/intel-me-way-of-static-analysis.html http://blog.ptsecurity.com/2017/04/intel-me-way-of-static-an...
i336_ 9y ago
QNX is also realtime. In order to provide realtime guarantees that cover small latencies, you need infrastructure that generates as few instructions as possible. (If you have lots of instructions you can hit targets of a hundreds of microseconds since you can just wait. Start inching toward nanoseconds, though, and the scheduler's own execution will get in the way unless it's crazy compact.) The reason I mention this is that QNX runs on a variety of embedded devices (http://qnx.symmetry.com.au/ http://qnx.symmetry.com.au/ has an interesting list, universal remotes particularly jumped out at me) which are traditionally quite slow. What's Rust like in terms of generating code that's consistently compact?
- mafribe 9y ago
  What's Rust like in ... Isn't that less a question of Rust (which due to its affine types, should be usable for generating code with predictable performance) but of compilers? It should be possible to write a Rust compiler that optimises for predictable performance at the cost of speed.

amluto 9y ago

> (*pointer).handle(); Eek! That is, indeed, unsafe. But this shouldn't be messing with the entry asm at all. Just add your new syscall to the syscall table, just like any other syscall.

martamoreno 9y ago

It's a fun idea and many people have had it first thing when they heard of Rust... So why did no one do it? Quite simply: No one is going to rewrite the Linux Kernel in Rust. It is far too big and also you are not solving any real issues either. Rust only protects you from a small fraction of errors and while for an application like a browser, this can be a big gain, I would argue that it is negligible for a kernel in general. Reasons being that all the device IO, component interaction, privilege escalations, logical errors, hardware errors, firmware errors/bugs all can NOT be addressed by rust. Even for a browser, Rust is only a band-aid. The amount of logical errors and security holes in something as complex as a modern web-browser is more than enough of an attack surface. No need for a rouge pointer to weird memory. What is MUCH more viable though is a project to compartmentalize the Linux Kernel into HVMs. I forgot the name but there are efforts to put nearly everything into its own HVM. Which means if the printer driver goes nuts, it can't really do anything to your system except not print anymore. If your graphics driver goes nuts, well then you won't see anything... And so on. This means, almost no code rewrites and still MUCH higher protection than RUST. Rust does not compartmentalize. If any of your system components is fucked, your whole system is still fucked. That is why it's pointless to rewrite a kernel because of a language. You need to compartmentalize it... Look at QubesOS for an early user-space effort. Would be nice to have a Qubes-Kernel too.

i336_ 9y ago
You're referring to microkernel/nanokernel architectures. Linus famously shunned Andrew Tanenbaum's MINIX kernel design and argued in favor of a monolithic kernel, where buggy printer drivers live in the same memory space and have the same elevated privileges as the code that manages the kernel's secure crypto key ring. Linus is also noted in this thread as not being interested in security issues. I do agree with you about Rust not solving the hardware problem.
- martamoreno 9y ago
  Yes it also makes sense. Because no matter what you do, it is unlikely that your are able to compartmentalize something so critical and raw as a device driver. If that one is fucked, the reason is likely that your system is already compromised. It was just an example of what WOULD be more viable and effective than rewriting it in Rust. I still think that QubesOS is taking the right approach. Initially assume hardware & kernel as trusted and make sure that this trust then can not be violated from the outside (TPM, SecureBoot, VMs for each app, etc.). I just wish more people would focus on that promising approach.

based2 9y ago

-> https://mirage.io/ https://mirage.io/

youdontknowtho 9y ago

I guess one of the things that always comes to mind when someone brings up "Rust all the things" is that it assumes that anything that can be expressed in C can be expressed in Rust with the safety features enabled. Rust wouldn't have a mechanism to do unsafe code otherwise, right? I think it might be more complicated than we might think initially. I personally think that someone should probably spend some more time on GC that's performant enough for systems code. My convictions haven't driven me to do anything about it, however.

Retra 9y ago
Safe rust clearly cannot express everything that can be expressed in C. It cannot even express everything that is safe in general. But "the safety features of Rust" includes drawing a barrier between the safe parts of your code and the unsafe parts. There is significant value in that compartmentalization. Moreover, you are assuming that things written unsafely in C should be written identically in rust, when there very well could be more idiomatic, modern ways to do the same thing without any unsafety at all.
- youdontknowtho 9y ago
  There are modern ways to express something safely that is written unsafely in C. What Rust evangelists seem to forget is that there have been ways to do that for a long time. The article actually has very little safe Rust in it. It makes me wonder what we are gaining? If the idea is that introducing Rust means that later you can go back and add type and memory safety...why not use C++ in a type and safe by construction way? Why not use Safe D? I'm personally just looking forward to the hype dying down. I'm tired of hearing about it, and most of the time I just click "hide" on Rust articles because I'm not interested and people are starting to sound pretty shrill.
  - Retra 9y ago
    Have you ever written anything in Rust?

FrozenVoid 9y ago

>Rewrite Linux Kernel in Rust? Rust has no backward compatibility: C code compiles fine after decades. It would be a waste of time to rewrite Linux in Rust when the resulting code has a lifetime of few months until it won't compile and start breaking everywhere.

vog 9y ago
> C code compiles fine after decades Early C code doesn't compile on modern systems at all. Speaking of early C code, every vendor had their own version. C standardization had to go a long way. Even today, writing portable C code is hard. Need a portable 128-bit integer? Good luck on Windows. Need a portable 32-bit integer? Better take a C implementation that provides int32_t, because just using "int" bites you when switching from 32-bit to 64-bit platforms. Oh, and int32_t was introduced in C99, which is not exactly "decades" ago, but admittedly that was 18 years ago. However, I wouldn't bet on portability of any code older than that, unless the authors of that C code were extremely careful and anticipatory. But then, with enough effort (and perhaps code generation), you can create portable code in any language. Rust skips all that mess, by having a clear experimental phase in the 0.x versions. It became stable with a clear commitment to backwards compatibility since 1.0, which was released in 2015.
- tom_mellior 9y ago
  > Need a portable 32-bit integer? Better take a C implementation that provides int32_t, because just using "int" bites you when switching from 32-bit to 64-bit platforms. Citation needed. Which compilers for which machines are you talking about? I don't think any change the size of int. What does break is the assumption that int is the same size as pointers, but that's because the sizes of pointers change.
  - vog 9y ago
    Whoops. I meant 16-bit versus 32-bit integers, when switching from 16-bit to 32-bit systems. Sorry for the confusion. Fortunately, they didn't repeat that mess for 32/64 bits, at least not for integers, but "decades old code" is still affected.