> Date: Mon, 28 Mar 2022 09:51:22 -0400 > From: Demi Marie Obenour <d...@invisiblethingslab.com> > > On 3/27/22 21:45, Damien Miller wrote: > > On Fri, 25 Mar 2022, Demi Marie Obenour wrote: > > > >> Linux’s netfront and blkfront drivers recently had a security > >> vulnerability (XSA-396) that allowed a malicious backend to potentially > >> compromise them. In follow-up audits, I found that OpenBSD’s xnf(4) > >> currently trusts the backend domain. I reported this privately to Theo > >> de Raadt, who indicated that OpenBSD does not consider this to be a > >> security concern. > >> > >> This is obviously a valid position for the OpenBSD project to take, but > >> it is surprising to some (such as myself) from the broader Xen > >> ecosystem. Standard practice in the Xen world is that bugs in frontends > >> that allow a malicious backend to cause mischief *are* considered > >> security bugs unless there is explicit documentation to the contrary. > >> As such, I believe this deserves to be noted in xnf(4) and xbf(4)’s man > >> pages. If the OpenBSD project agrees, I am willing to write a patch, > >> but I have no experience with mandoc so it might take a few tries. > > > > Hang on, what is a "malicious backend" in this context? Is it something > > other than the Xen Hypervisor? If not, then it seems not to be a useful > > attack model, as the hypervisor typically has near-complete access to > > guests' memory and CPU state. > > The backend can run in any Xen VM. It often runs in dom0, but it > is not required to, and in Qubes OS the network backend never runs > in dom0. Unless it runs in dom0, it has no access to frontend memory, > except for memory the frontend has explicitly given it access to via > grant tables.
So this is somewhat similar to the situation on sun4v (Sun's virtualization of the SPARC architecture). When writing the vnet(4) and vdsk(4) drivers for OpenBSD, I did consider the implications of those drivers talking to a "malicious" domain. the SPARC hypervisor implements a concept similar to grant tables. It is fairly obvious that any memory you grant access to should be considered insecure. This means that you either have to make a copy of the data or revoke access to the shared memory through some sort of Hypervisor call that implements a synchronization point of some sorts. Otherwise you and up TOCTOU issues all over the place. But this obviously has significant performance consequences. For vnet(4) I decided that an extra copy was worth doing and the only reasonable way of doing things given how OpenBSD's mbuf layer works. But for vdsk(4) I decided to trust the other domain as there is no way to prevent it from feeding you compromised data. Full disk encryption doesn't really solve the problem unless you have a way to securely verify the bootloader. Personally I think it might be beneficial for us to turn xnf(4) into what we colloquially call a "bcopy" network driver. But folks who actually use xen may find the performance impact of doing this unacceptable and decide to trust the backend instead.
