7 ms·

The Fuchsia OS microkernel should be rewritten in Rust, too, especially if it's going to take another 5 years before we even see it in a commercial product. If

by mtgx 9y ago

The Fuchsia OS microkernel should be rewritten in Rust, too, especially if it's going to take another 5 years before we even see it in a commercial product. If Google wants to make a modern new OS that will help it avoid many of the existing security problems it needs to keep fixing with Android/Chrome OS right now, then it should do it right and avoid collecting a lot of "security debt" down the road because of unsafe code/poor initial security architecture decisions.

cyber1 9y ago
You absolutely right! You can imagine what Google can do with his resources when even one programmer writes his own OS, file system, etc on Rust - https://github.com/redox-os/ https://github.com/redox-os/!
- 0xFFC 9y ago
  What is the connection between Google and Redox? I didn’t understand you to be honest.
  - cyber1 9y ago
    I try to say when you use a good programming language with a really cool compiler which can prevent a lot of errors you can be very efficient and don't lose most of time in debugger!
  - mtgx 9y ago
    I think he meant that if one guy developed Redox in his spare time, surely it wouldn't be too hard for a Google team to "simply" rewrite Fuchsia in Rust.
Ygg2 9y ago
They should rewrite Go in Rust! That way we can avoid all this Go vs Rust discussions ;) Problem with your idea, is that low level kernel will use a lot of unsafe Rust, which will lose lot of benefits.
- cyber1 9y ago
  According to memory management, yes but you have a lot of benefit from the strong type-safe system, ecosystem, testing and etc.
- ekidd 9y ago
  > Problem with your idea, is that low level kernel will use a lot of unsafe Rust, which will lose lot of benefits. I've actually worked on a toy kernel in Rust (using the excellent tutorial at https://os.phil-opp.com/ https://os.phil-opp.com/), and it turns out that, yes, you obviously need to use unsafe code to talk to the actual hardware. But in most cases, you can encapsulate the low-level hardware inside a safe API: https://github.com/emk/toyos-rs/blob/fdc5fb8cc8152a63d1b6c85cd357737e6b1aebb5/crates/cpuio/src/lib.rs#L43-L75 https://github.com/emk/toyos-rs/blob/fdc5fb8cc8152a63d1b6c85... In this example, only I/O port creation is an unsafe API, because you need to specify a memory address to read and write. But once the port is created (pointed at an appropriate address!), it's perfectly safe to use. So, yes, kernel-space Rust will use "unsafe" far more often than regular Rust code. But you can still make at least 80% of your code safe, and maybe much more. And the remaining "unsafe" APIs act as a useful warning to pay attention to what you're doing. Plus, Rust is a really nice language to write kernel code in, anyway.
  - angrygoat 9y ago
    Nice to have the dangerous bits annotated – in a C/C++/... kernel, everything is "unsafe". "Given enough eyeballs, all bugs are shallow" - but it helps when the eyeballs are focussed! :-)
    - staticassertion 9y ago
      It's hard to emphasize the auditability enough. With auditing a C/C++ codebase, in my experience, you rely a lot on intuition. "Well, there's parsing done here, so I'll focus my efforts" or "Historically we've had a lot of CVEs from this part of code so I'll start there". I'm not a professional RE so my experience is limited, but when I went looking for vulns that's how I went about it, and I think that's generally the case. With rust there's significantly less guesswork. That parser doesn't use unsafe? OK, let's start elsewhere. That seemingly innocent code uses unsafe? Great, check that out. You can grep for vulnerabilities, basically.
pjmlp 9y ago
The TCP/IP stack and file system driver are written in Go.
- kristianp 9y ago
  See https://github.com/fuchsia-mirror?language=go https://github.com/fuchsia-mirror?language=go
dikaiosune 9y ago
I'm normally quite happy to advocate for Rust everywhere, but one of the benefits of the microkernel architecture is that you have a very small trusted computing base for your system. Yes, Rust could help, but there are lots of techniques for building highly reliable C/C++ codebases, and one of the main reasons they don't get used more in large codebases is that they don't scale super well. But, in a microkernel it's much easier to apply those methods. See for example the sel4 microkernel, which is small enough to have a well-verified model for a bunch of different hardware. Uh, this is rambling a bit. My point is that building zircon as a microkernel makes it much easier to write correct code, Rust or not. And that maybe the overhead of a rewrite wouldn't be as beneficial for the microkernel as it would be for other parts of the operating system.
- colemickens 9y ago
  This is virtually the same reply that every single "rust would help with safety" comment gets every time without fail. And despite those tools, mistakes occur in the most critical of codebases. In fact just early today a patch to LKML was being mocked because some pointer manipulation in C was clearly buggy and uncaught due to the lack of safety and sophistication of the type system.
  - dikaiosune 9y ago
    I don't think this is quite the template reply (and if you check my HN comment history, I think you might see that I'm quite familiar with receiving the template replies!), what I meant to say is that it'd be much higher leverage to rewrite other parts of Fuchsia in Rust than to rewrite Zircon.
    - colemickens 9y ago
      Sorry, I didn't mean to put words in your mouth or anything. I am quite curious which parts you think would better benefit from a rewrite in a safer language if you might elaborate. Thanks!
      - 9y ago

by mtgx 9y ago

cyber1 9y ago

You absolutely right! You can imagine what Google can do with his resources when even one programmer writes his own OS, file system, etc on Rust - https://github.com/redox-os/ https://github.com/redox-os/!

0xFFC 9y ago
What is the connection between Google and Redox? I didn’t understand you to be honest.
- cyber1 9y ago
  I try to say when you use a good programming language with a really cool compiler which can prevent a lot of errors you can be very efficient and don't lose most of time in debugger!
- mtgx 9y ago
  I think he meant that if one guy developed Redox in his spare time, surely it wouldn't be too hard for a Google team to "simply" rewrite Fuchsia in Rust.

Ygg2 9y ago

They should rewrite Go in Rust! That way we can avoid all this Go vs Rust discussions ;) Problem with your idea, is that low level kernel will use a lot of unsafe Rust, which will lose lot of benefits.

cyber1 9y ago
According to memory management, yes but you have a lot of benefit from the strong type-safe system, ecosystem, testing and etc.
ekidd 9y ago
> Problem with your idea, is that low level kernel will use a lot of unsafe Rust, which will lose lot of benefits. I've actually worked on a toy kernel in Rust (using the excellent tutorial at https://os.phil-opp.com/ https://os.phil-opp.com/), and it turns out that, yes, you obviously need to use unsafe code to talk to the actual hardware. But in most cases, you can encapsulate the low-level hardware inside a safe API: https://github.com/emk/toyos-rs/blob/fdc5fb8cc8152a63d1b6c85cd357737e6b1aebb5/crates/cpuio/src/lib.rs#L43-L75 https://github.com/emk/toyos-rs/blob/fdc5fb8cc8152a63d1b6c85... In this example, only I/O port creation is an unsafe API, because you need to specify a memory address to read and write. But once the port is created (pointed at an appropriate address!), it's perfectly safe to use. So, yes, kernel-space Rust will use "unsafe" far more often than regular Rust code. But you can still make at least 80% of your code safe, and maybe much more. And the remaining "unsafe" APIs act as a useful warning to pay attention to what you're doing. Plus, Rust is a really nice language to write kernel code in, anyway.
- angrygoat 9y ago
  Nice to have the dangerous bits annotated – in a C/C++/... kernel, everything is "unsafe". "Given enough eyeballs, all bugs are shallow" - but it helps when the eyeballs are focussed! :-)
  - staticassertion 9y ago
    It's hard to emphasize the auditability enough. With auditing a C/C++ codebase, in my experience, you rely a lot on intuition. "Well, there's parsing done here, so I'll focus my efforts" or "Historically we've had a lot of CVEs from this part of code so I'll start there". I'm not a professional RE so my experience is limited, but when I went looking for vulns that's how I went about it, and I think that's generally the case. With rust there's significantly less guesswork. That parser doesn't use unsafe? OK, let's start elsewhere. That seemingly innocent code uses unsafe? Great, check that out. You can grep for vulnerabilities, basically.

pjmlp 9y ago

The TCP/IP stack and file system driver are written in Go.

kristianp 9y ago
See https://github.com/fuchsia-mirror?language=go https://github.com/fuchsia-mirror?language=go

dikaiosune 9y ago

I'm normally quite happy to advocate for Rust everywhere, but one of the benefits of the microkernel architecture is that you have a very small trusted computing base for your system. Yes, Rust could help, but there are lots of techniques for building highly reliable C/C++ codebases, and one of the main reasons they don't get used more in large codebases is that they don't scale super well. But, in a microkernel it's much easier to apply those methods. See for example the sel4 microkernel, which is small enough to have a well-verified model for a bunch of different hardware. Uh, this is rambling a bit. My point is that building zircon as a microkernel makes it much easier to write correct code, Rust or not. And that maybe the overhead of a rewrite wouldn't be as beneficial for the microkernel as it would be for other parts of the operating system.

colemickens 9y ago
This is virtually the same reply that every single "rust would help with safety" comment gets every time without fail. And despite those tools, mistakes occur in the most critical of codebases. In fact just early today a patch to LKML was being mocked because some pointer manipulation in C was clearly buggy and uncaught due to the lack of safety and sophistication of the type system.
- dikaiosune 9y ago
  I don't think this is quite the template reply (and if you check my HN comment history, I think you might see that I'm quite familiar with receiving the template replies!), what I meant to say is that it'd be much higher leverage to rewrite other parts of Fuchsia in Rust than to rewrite Zircon.
  - colemickens 9y ago
    Sorry, I didn't mean to put words in your mouth or anything. I am quite curious which parts you think would better benefit from a rewrite in a safer language if you might elaborate. Thanks!
    - 9y ago