[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


  • To: Claudio Jeker <cjeker@xxxxxxxxxxxxxxxxx>
  • From: Roger Pau Monné <roger.pau@xxxxxxxxxx>
  • Date: Tue, 29 Mar 2022 12:51:37 +0200
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=fgWNT3f9WMZmxjpQ+LpATbVnyx8TPNst9aseBSWaTr4=; b=JTbir9NTg8ipF/UW61MUGUzsEfe3E/+bt9vC+Q22QDF9merrTQPYumYZivexTdYNcRLPuuNjm4NBykm4Ydfrzaj23PMBRmfV86bFSlkqoswrByvePubh9cMu/gn/26EYwT9nJQ5gV9mBe8+iQrLisvWOchm+d64DUuvzkLsv9/6b5mJCdJmD3UadU2145hgx2+/EcPHpatD6TRnFAPR3Egsf0ZuuWc9TTdIzwhz/QAC8Rc6XYcrUbUsRsnKQu0uB9HkcYmRRXya34M62jameis/9J8NbNUItuY0wZMLAkH9isBfLahU4OMExQ+RNjFL4hsEhX2AxN8Qu7gVwaA16uQ==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=CNagokudkJ1hHuX7hUaOXnbHeGxBjIn2GGh4EJhlkOZPdoQA+VuJrWCx1wlO6DgLFLcdWgREE+59ePdM1C696gINymbA8zMFhuHQ4HsiPdyME7WSbWwH5p6SARV2msiEdUmSwSmszDaSAXmVbxZFToyM5ScrSJCm+d5Bd3cXaMdBOA/ADbSN/0r5MqX3cQsGL84M5/897uUKEo5eFLQQgCcehEiIHpmdKVBlb5Cf/4Xr+J3T1QyFEOuPI1/yMQmzwLAo1Lo1cqG3te3SsQn0GksHREJSaOS7oqgZvkO0Jc7UYWAQfJU1MeYTpXadNSyqoR6VFQJ/CNGbcftD1NKgpg==
  • Authentication-results: esa2.hc3370-68.iphmx.com; dkim=pass (signature verified) header.i=@citrix.onmicrosoft.com
  • Cc: Demi Marie Obenour <demi@xxxxxxxxxxxxxxxxxxxxxx>, Mark Kettenis <mark.kettenis@xxxxxxxxx>, <djm@xxxxxxxxxxx>, <marmarek@xxxxxxxxxxxxxxxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxxx>, <tech@xxxxxxxxxxx>
  • Delivery-date: Tue, 29 Mar 2022 10:52:05 +0000
  • Ironport-data: A9a23:Ghheu6gL46UEsfl0piFL67Y3X1614xAKZh0ujC45NGQN5FlHY01je htvXjqFP/eNN2v9fI1/bYi1oEhTvpHUx4c3SAZtqyk0Fn4b9cadCdqndUqhZCn6wu8v7a5EA 2fyTvGacajYm1eF/k/F3oDJ9CU6jefSLlbFILas1hpZHGeIcw98z0M78wIFqtQw24LhWFnc4 YmaT/D3YzdJ5RYlagr41IrbwP9flKyaVOQw5wFWiVhj5TcyplFNZH4tDfjZw0jQG+G4KtWSV efbpIxVy0uCl/sb5nFJpZ6gGqECaua60QFjERO6UYD66vRJjnRaPqrWqJPwwKqY4tmEt4kZ9 TlDiXC/YV8kEIbNm+FBbwJjFBNAOKgYyu6AI2fq5KR/z2WeG5ft6/BnDUVwNowE4OdnR2pJ8 JT0KhhUMErF3bjvhuvmFK883azPL+GyVG8bkmtnwjzDS+4vXLjIQrnQ5M8e1zA17ixLNaiBO 5BJMmE3BPjGSzwfAFgnDakdp72DilulfRlxpwifvJNitgA/yyQuieOwYbI5YOeiQMxPm0+Cq 2Hu/mLnAwobPtiS1TqE9H23gubF2yj8Xeo6BLC+s/JnnlCX7mgSEwENE0u2p+GjjUyzUM4ZL FYbkgIyoKMy3EuzQ9/3RBH+p2SL1jYQWd94Fuw85BuK1uzT+QnxLmMGQz1McvQqtcI2TCYmk FnMhZbmQzdotdW9RX+Y95+Vqy2zIikfKWIeZS4CQhAB6tOlq4Y25jrKR8xgVq24ksH4HzDr6 yCR8CE6g/MViaY2O76TpA6dxWj2/96QE1Bztl6/sn+ZAh1RPIOLTI2r7ATn9s1HHricSwez7 T8GhJ3LhAwRNq2lmCuISeQLObim4feZLTHR6WJS84kdGyeFoCD6I90JiN1qDAIwa5tfJ2e1C KPGkVkJjKK/KkdGekOej2iZL80xhZbtGt3+Phw/RoofO8MhHONrEcwHWKJx44wPuBV3+U3cE c3CGSpJMZr8If49pNZRb71BuYLHPghkmQvuqWnTlnxLK4a2an+PUqsiO1CTdO0/567siFyLr 4YDb5TQkUsEDr2WjszrHWg7dwpiwZ8TX82eliCqXrTbfloO9J8JVZc9Po/Ni6Q6xv8Ix48kD 1m2W1NCyUqXuJE0AV7iV5yXU5u2BcwXhStiZUQEZA/0s1B+MdfHxPpOLPMfIOh4nNGPONYpF pHpje3bWa8RItkGkhxABaTAQHtKKU3z3FnUbnP/CNX9FrY5LzH0FhbfVlKH3AEFDzattNt4p Lul1wjBRoEESRgkB8HTAM9DBXvr1ZTBsIqeh3f1H+Q=
  • Ironport-hdrordr: A9a23:dtU5sKG3migwYTBBpLqFCpHXdLJyesId70hD6qkvc3Nom52j+/ xGws536faVslcssHFJo6HmBEClewKnyXcT2/htAV7CZnichILMFu9fBOTZsl/d8kHFh4tgPO JbAtRD4b7LfClHZKTBkXCF+r8bqbHtmsDY5ts2jU0dNT2CA5sQkTuRYTzrdHGeKjM2YabQQ/ Gnl7V6TnebCDwqR/X+IkNAc/nIptXNmp6jSRkaByQ/4A3LqT+z8rb1HzWRwx9bClp0sP0f2F mAtza8yrSosvm9xBOZ/2jP765OkN+k7tdYHsSDhuUcNz2poAe1Y4ZKXaGEoVkO0aqSwWdvtO OJjwYrPsx15X+UVmapoSH10w2l6zoq42+K8y7uvVLT5ejCAB4qActIgoxUNjHD7VA7gd162K VXm0qEqpt+F3r77WvAzumNcysvulu/oHIkn+JWpWdYS5EiZLhYqpFa1F9JEa0HADnx5OkcYa VT5fnnlbdrmG6hHjDkVjEF+q3uYp1zJGbKfqE6gL3a79AM90oJjXfxx6Qk7wM9HdwGOtx5Dt //Q9dVfYF1P78rhJ1GdZU8qOuMexrwqEH3QSuvyWqOLtBzB5uKke+y3IkI
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On Tue, Mar 29, 2022 at 10:16:15AM +0200, Claudio Jeker wrote:
> On Mon, Mar 28, 2022 at 04:38:33PM -0400, Demi Marie Obenour 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.
> 
> So how does xen manage to limit access to less than a page size?
> The hardware on x86 does not give you byte precise mappings for granting
> memory.
> An mbuf is 256 bytes and of those 256 bytes less then that is used for
> data. Still for dma the full 4k page needs to be granted to the host.
> The only way this can be done is by memcpy all data into individual pages.
> The same is true for the most common mbuf cluster size of 2k.
> So yes, this will be a bcopy ethernet driver and by that will be on the
> same level of crappyness as bce(4) and old old old realtek.

I've got no idea about the Xen network protocol, but the Xen block
protocol already has a feature called persistent grants that will
force the frontend to copy all data into a set of pre-granted pages
(ie: akin to a bounce buffer).

That's mostly done as a performance optimization so that the backend
doesn't have to map and unmap each page on the request, as
establishing and tearing down such mappings tends to be more expensive
than doing a memcpy on the frontend.

A security sensitive block frontend could refuse to connect unless
persistent grants are available, or as you say force all pages to be
bounced.

So forcing a copy in the frontend might not be that bad from a
performance PoV if that avoids the transient grant mapping operations
on the backend side, but that needs to be negotiated.

Roger.



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.