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

["Theo de Raadt" <deraadt@xxxxxxxxxxx>]

And I simply why we don't simply delete all that code.


Demi Marie Obenour <demi@xxxxxxxxxxxxxxxxxxxxxx> wrote:

> On 3/28/22 10:39, Mark Kettenis wrote:
> >> 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.
> 
> In Qubes OS, xbf(4) devices are configurable.  While all of them are
> provided by dom0 (which is trusted) by default, it is possible to
> attach devices that are *not* provided by dom0, and these devices
> should not be trusted.
> 
> > 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.
> 
> You actually don’t have to do that.  The Xen network protocol
> requires the backend to drop access to the buffer before giving it
> to the frontend, so the frontend only needs to ensure that it cannot
> regain access.  This will fail if the backend still has access, but
> that is a bug in the backend, in which case you should shut down the
> interface.  So there should not be any significant performance impact.
> 
> If you are curious about how Linux does this, you can look at
> drivers/xen/grant-table.c, drivers/net/xen-netfront.c, and
> drivers/block/xen-blkfront.c from the Linux source.  They are
> dual licensed GPL/MIT so there should not be licensing issues there.
> Be sure to use a version at or after “xen/netfront: react properly to
> failing gnttab_end_foreign_access_ref()” and the other XSA-396 patches.
> -- 
> Sincerely,
> Demi Marie Obenour (she/her/hers)
> Invisible Things Lab