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 answering my questions though.
> 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 the code in Rust, and then I used 'cargo fuzz' to try and find vulnerabilities. After running a billion(!) fuzz iterations, I found 5 bugs (see the 'vobsub' section of the trophy case for a list https://github.com/rust-fuzz/trophy-case).
Happily, not one of those bugs could actually be escalated into an actual exploit. In each case, Rust's various runtime checks successfully caught the problem and turned it into a controlled panic. (In practice, this would restart the web server cleanly.)
So my takeaway from this was that whenever I want a language (1) with no GC, but (2) which I can trust in a security-critical context, Rust is an excellent choice. The fact that I can statically link Linux binaries (like with Go) is a nice plus.
> Happily, not one of those bugs could actually be escalated into an actual exploit. In each case, Rust's various runtime checks successfully caught the problem and turned it into a controlled panic.
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.
KVM maintainer here. I agree that this makes a lot of sense to write in Rust. Some time ago there was even a demo of a qcow2 format driver for QEMU written in Rust.
I also find your Rust style extremely readable. Great job!
Would you consider releasing parts of this as standalone crates on crates.io? I ask because there are many different things developers would like to do with KVM that might not be the same as the goals of ChromiumOS.
Also, the Wayland stuff looks cool but I'm not sure how you are managing the buffers with just the wl protocol.
There is a Wayland crate for Rust that also has support for generating protocol from the xml descriptions, not sure if you used that there.
This seems like a good follow on to the work done in Go and python a while back at Google, though it would be cool to support the virtio p9fs as a root filesystem.
And, I know you can't say anything about this, but I'm happy to see the arm support in there, maybe it's possible that Google supports a fully virtualized Android device with the ability to run first class Linux, ChromeOS, etc. even on locked bootloader devices.
It would even be possible to keep a tiny resident e911-compliant dialer persistant as part of a lock screen.
Anyway, awesome work, I might have to revive kvmd at some point.
>Would you consider releasing parts of this as standalone crates on crates.io? I ask because there are many different things developers would like to do with KVM that might not be the same as the goals of ChromiumOS.
Sadly, not many of the components within crosvm would make good crates in crates.io. The crates in crosvm tend to be laser focused on solving a specific use case within crosvm. There are more general versions of lots of the functionality we have in crosvm that exist in crates.io (e.g. eventfd or memory maps) that we skipped to avoid excessive external dependencies.
>Also, the Wayland stuff looks cool but I'm not sure how you are managing the buffers with just the wl protocol.
The virtio wayland I designed is intended to be somewhat agnostic of the underlying wayland protocol for simplicity. It just passes along the protocol bytes to the host's wayland compositor. In order to share FDs with the host (to support e.g. buffers and keymaps), crosvm has a mapping of virtual file descriptor IDs known to the guest kernel to host FDs that get passed along to the wayland compositor.
>though it would be cool to support the virtio p9fs as a root filesystem.
We considered it, but for our application, 9pfs was not going to be optimal. That being said, we'd welcome patches that added support for it. :)
>And, I know you can't say anything about this, but I'm happy to see the arm support in there
The ARM support is rather preliminary. crosvm will compile for ARM but it has yet to succesfully boot a VM.
I was actually referring to your kvm and kvm-sys crates, through it seems that some of the memory management stuff is closely tied to that. I ask because I tried to build a kvmd daemon using the kvm-rs crate that's out there, but ran into some issues. At the time bindgen was not quite up to the task of handling the kernel headers itself as well.
> The virtio wayland I designed is intended to be somewhat agnostic of the underlying wayland protocol for simplicity. It just passes along the protocol bytes to the host's wayland compositor. In order to share FDs with the host (to support e.g. buffers and keymaps), crosvm has a mapping of virtual file descriptor IDs known to the guest kernel to host FDs that get passed along to the wayland compositor.
Okay, I guess I'm more asking how software running on the VMs are accessing buffers on the GPU which are managed by the Wayland server, as I don't see anything in the virtio folders referring to this. I guess this is just using some kind of shared memory region then? I'll have to look at it more later.
Also, this low-level Wayland really seems like it could be a standard way to access GPUs through a hypervisor, maybe something that could be implemented by (k)qemu or others.
> We considered it, but for our application, 9pfs was not going to be optimal. That being said, we'd welcome patches that added support for it. :)
Yes, and I might try to get to that sometime. I really like the approach starting with vmlinux and not a BIOS implementation, anything to make the OS boot faster in the VM is good.
> The ARM support is rather preliminary. crosvm will compile for ARM but it has yet to succesfully boot a VM.
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 :)
Thanks! I've really appreciated your Rust guides over the years. It's been so handy that we pre-ordered 5 copies of your Rust Programming Language book a few months back. I can't wait to get my hard copy. :)
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 answering my questions though.