71–80 of 109 posts
Is this a new component for Chrome OS? Would this be a replacement for a project like Crouton or is something like this already being leveraged by that project?
Crouton is just a chroot to some linux distro. It doesn't use any sort of virtualization.
Earlier quoted context omitted.
That's low-level code implementing a wrapper around the underlying libc socket API; there's no alternative to unsafe blocks there as it wraps a legacy API written in C. The "this is safe" comment is just a (very verbose) explanation as to why the wrapper code is doing the correct thing. Notably, there's another similar comment just above it. In fact, looking through the file if anything I'm quite impressed at how car…
Author here: one of the policies we tried to stick to when writing unsafe code was to document each case. It can be tedious but it encourages having less unsafe code and makes the author really think about if this unsafe code is really meeting the same guarantees as safe Rust according to https://doc.rust-lang.org/nomicon/meet-safe-and-unsafe.html
(When I've pondered this question before, "document every instance of `unsafe`" has been one of my policies (as obvious as it may seem), so I think you're on the right track!)
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 unsa…
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.
Is Rust an officially sanctioned language at Google?
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 unsa…
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'…
Earlier quoted context omitted.
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'…
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.
Earlier quoted context omitted.
Author here: Rust is not officially sanctioned at Google, but there are pockets of folks using it here. The trick with using Rust in this component was convincing my coworkers that no other language was right for job, which I believe to be the case in this instance. That being said, there was a ton of work getting Rust to play nice within the Chrome OS build environment. The Rust folks have been super helpful in answ…
I am super excited to see this! Glad we've already been helpful, but I'd like to reaffirm that if you need anything, we'd like to continue being helpful in the future :)
Earlier quoted context omitted.
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.
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.
Earlier quoted context omitted.
Author here: Rust is not officially sanctioned at Google, but there are pockets of folks using it here. The trick with using Rust in this component was convincing my coworkers that no other language was right for job, which I believe to be the case in this instance. That being said, there was a ton of work getting Rust to play nice within the Chrome OS build environment. The Rust folks have been super helpful in answ…
> The trick with using Rust in this component was convincing my coworkers that no other language was right for job, which I believe to be the case in this instance. I ran into a similar use case in one of my own projects—a vobsub subtitle decoder, which parses complicated binary data, and which I someday want to run as web service. So obviously, I want to ensure that there are no vulnerabilities in my code. I wrote t…
This has been more or less our experience with fuzzing rust code in firefox too, fwiw. Fuzzing found a lot of panics (and debug assertions / "safe" overflow assertions). In one case it actually found a bug that had been under the radar in the analogous Gecko code for around a decade.
Earlier quoted context omitted.
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.
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!
I think one of the clearest examples would be drivers -- they might be properly sandboxed by a good microkernel, but they are notoriously buggy/crashy/incorrect. If I remember correctly one of the Fuchsia team members told me that they were going to support drivers written in Rust, but I could be completely wrong.
Filesystems, the network stack, whatever horrifying systemd equivalent Fuchsia grows, etc. are all examples of things I would advocate for writing in Rust before focusing on the kernel. All of these things are still security/reliability sensitive, all still terrible by Rustacean safety standards in most OSes, and conveniently don't have to be built directly as part of the kernel when you're doing a microkernel.
Just spitballing, of course.