* This Week in Spectrum,
@ 2020-07-13 0:01 Alyssa Ross
0 siblings, 0 replies; only message in thread
From: Alyssa Ross @ 2020-07-13 0:01 UTC (permalink / raw)
To: discuss, devel; +Cc: Cole Helbling
[-- Attachment #1: Type: text/plain, Size: 4983 bytes --]
After I got an isolated Wayland compositor working last week, I wasn't
really sure what to do next -- this was a big piece of work that I'd
been very focused on for a while. The funding milestone I'm closest to
is to do with implementing hardware isolation, which the Wayland work
was a part of, so I decided to keep going with that, and explore other
types of isolation. More on that in a bit.
Wayland
-------
Posted my patch for virtio_wl display socket support in
libwayland-server[1]. This is what allows it to run in a VM, and
receive connections from clients in other VMs. The patch description is
very extensive, so I recommend reading it for more detail if you're
interested.
It introduces a libvirtio_wl, which should also be useful for porting
other programs that we might want to communicate with across a VM
boundary, if they are written with normal Unix sockets in mind
(including transferring file descriptors). This is the evolution of
code I previously had put in wlroots, moved to Wayland for convenience.
If it ever acquires another user (or maybe even if it doesn't) it might
make sense to make it its own package, since virtio_wl is useful even if
Wayland isn't involved.
[1]: https://spectrum-os.org/lists/archives/spectrum-devel/SJ0PR03MB5581479F3388047230F36EB3B3670@SJ0PR03MB5581.namprd03.prod.outlook.com/T/#t
crosvm
------
I pushed all my crosvm changes to get the isolated compositor working to
the work-in-progress "interguest" branch[2]. Remember, I only got it
working last week right before I needed to start writing the TWiS email,
so I hadn't even done that yet! I also posted some patches[3] to the list
to fix a bug in my previous crosvm deadlock fix, and to improve some
related documentation. As usual, these were kindly reviewed by Cole.
Next, I turned my attention to other forms of hardware isolation.
Wayland was a bit special, because despite crosvm including a virtual
"Wayland device", it's not really hardware, and so it required an
approach to isolation that will be quite different to other crosvm
virtual devices. My hope is that other virtual devices should all be
substantially similar to each other.
The basic idea for actual hardware isolation is that rather than having
drivers in the host kernel for USB, network devices, etc. those will be
exposed to dedicated VMs as virtual PCI devices. This should
substantially reduce host kernel attack surface. crosvm virtual devices
will be run in these device VMs, and communicate over virtio with
application VMs as normal. This will require implementing in crosvm a
virtio proxy device, than allows for the crosvm running an application
VM to forward virtio communication to the virtual device running in
userspace in the driver VM.
(The reason devices aren't attached to application VMs directly but run
in seperate device VMs is that hardware is probably not going to be very
happy if multiple kernels are trying to talk to it at the same time.
Additionally, this indirection means that application VMs only have to
use the one virtio driver for that device category, rather than any of
the hundreds of drivers for different hardware in that category. If one
of those drivers had a vulnerability, this should help to contain it to
the device VM.)
So I started writing this virtio proxy. The basic idea is to copy
virtio buffers from application VM guest memory into memory that can be
shared with the userspace virtual device in the device VM. I can't find
any prior art on this (which is not unusual -- not many systems isolate
drivers in this way), so this has required a lot of looking back at the
virtio paper[4] and spec[5] to make sure I understand what to do here.
As I write this, the next problem to solve is integrating some sort of
memory allocator that can manage buffer allocations in the shared memory
that the virtual device looks at. This is a new area for me that I'd
appreciate advice on if anybody can give it -- think of it like, I have a
memfd, mmaped into my process, and I would like to dynamically allocate
and release memory buffers of dynamic sizes in that region. I'm sure
there's a library I'll be able to plug in for this.
[2]: https://spectrum-os.org/git/crosvm/?h=interguest
[3]: https://spectrum-os.org/lists/archives/spectrum-devel/SJ0PR03MB55819DE7E13B7AFC97321C3BB3670@SJ0PR03MB5581.namprd03.prod.outlook.com/T/#t
[4]: https://www.ozlabs.org/~rusty/virtio-spec/virtio-paper.pdf
[5]: https://docs.oasis-open.org/virtio/virtio/v1.1/csprd01/virtio-v1.1-csprd01.html
As usual, big thank you to Cole for reviewing patches, and for finding
room for improvement even in languages/areas he isn't familiar with.
It feels nice to have done some thinking about the project at a slightly
higher level than I have been recently, and to know where I am on the
way to the next milestone. Having taken a lot of time away from the
milestone list this year to work on fundamentals, it's good to feel like
I'm getting back on track.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
^ permalink raw reply [flat|nested] only message in thread
only message in thread, other threads:[~2020-07-13 0:01 UTC | newest]
Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-07-13 0:01 This Week in Spectrum, Alyssa Ross
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).