Re: Security support status of xnf(4) and xbf(4)

[Mark Kettenis <mark.kettenis@xxxxxxxxx>]

> Date: Mon, 28 Mar 2022 09:51:22 -0400
> From: Demi Marie Obenour <demi@xxxxxxxxxxxxxxxxxxxxxx>
> 
> 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.