On Thu, Aug 06, 2020 at 01:01:30PM +0100, Daniel P. Berrangé wrote: > On Thu, Aug 06, 2020 at 01:51:48PM +0200, Sergio Lopez wrote: > > On Thu, Aug 06, 2020 at 11:24:13AM +0100, Stefan Hajnoczi wrote: > > <snip> > > > Conclusion > > > --------------- > > > Most security bugs in QEMU today are C programming bugs. Switching to > > > a safer programming language will significantly reduce security bugs > > > in QEMU. Rust is now mature and proven enough to use as the language > > > for device emulation code. Thanks to vhost-user and vfio-user using > > > Rust for device emulation does not require a big conversion of QEMU > > > code, it can simply be done in a separate program. This way attack > > > surfaces can be written in Rust to make them less susceptible to > > > security bugs going forward. > > > > > > > Having worked on Rust implementations for vhost-user-fs and > > vhost-user-blk, I'm 100% sold on this idea. > > > > That said, there are a couple things that I think may help getting > > more people into implementing vhost-user devices in Rust. > > > > 1. Having a reference implementation for a simple device somewhere > > close or inside the QEMU source tree. I'd say vhost-user-blk is a > > clear candidate, given that a naive implementation for raw files > > without any I/O optimization is quite easy to read and understand. > > > > 2. Integrating the ability to start-up vhost-user daemons from QEMU, > > in an easy and portable way. I know we can always rely on daemons > > like libvirt to do this for us, but I think it'd be nicer to be able > > to define a vhost-user device from the command line and have QEMU > > execute it with the proper parameters (BTW, Cloud-Hypervisor already > > does that). This would probably require some kind of configuration > > file, to be able to define which binary provides each vhost-user > > device personality, but could also be a way for "sanctioning" > > daemons (through the configuration defaults), and to have them adhere > > to a standardized command line format. > > This second point is such a good idea that we already have defined > how todo this in QEMU - see the docs/interop/vhost-user.json file. > This specifies metadata files that should be installed into a > defined location such that QEMU/libvirt/other mgmt app can locate > vhost-user impls for each type of device, and priortize between > different impls.
Nice, but AFAIK QEMU still lacks the ability to process those files and run the vhost-user device providers by itself. Or perhaps I just can't find it (?). Sergio.
signature.asc
Description: PGP signature
