5 ms·

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 convinc

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.

ekidd 9y ago
> 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 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.
- Manishearth 9y ago
  > 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.
steveklabnik 9y ago
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 :)
- zaxcellent 9y ago
  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. :)
  - steveklabnik 9y ago
    Wonderful; we had some delays but it's back to full-steam ahead. I can't wait to get a hard copy too :)
tmzt 9y ago
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. The library is here: https://github.com/Smithay/wayland-rs https://github.com/Smithay/wayland-rs and the part you would want is the `wayland-scanner` crate in that repo. 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.
- zaxcellent 9y ago
  >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.
bonzini 9y ago
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!

ekidd 9y ago

> 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 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.

Manishearth 9y ago
> 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.

steveklabnik 9y ago

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 :)

zaxcellent 9y ago
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. :)
- steveklabnik 9y ago
  Wonderful; we had some delays but it's back to full-steam ahead. I can't wait to get a hard copy too :)

tmzt 9y ago

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. The library is here: https://github.com/Smithay/wayland-rs https://github.com/Smithay/wayland-rs and the part you would want is the `wayland-scanner` crate in that repo. 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.

zaxcellent 9y ago
>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.

bonzini 9y ago

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!