netdev - Re: [PATCH] Don't allow sharing of tx skbs on xen-netfront

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20111117204553.GD26847@hmsreliant.think-freely.org>
Date:	Thu, 17 Nov 2011 15:45:53 -0500
From:	Neil Horman <nhorman@...driver.com>
To:	Ian Campbell <Ian.Campbell@...rix.com>
Cc:	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"David S. Miller" <davem@...emloft.net>,
	Jeremy Fitzhardinge <Jeremy.Fitzhardinge@...rix.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>,
	"xen-devel@...ts.xensource.com" <xen-devel@...ts.xensource.com>
Subject: Re: [PATCH] Don't allow sharing of tx skbs on xen-netfront

On Thu, Nov 17, 2011 at 08:17:01PM +0000, Ian Campbell wrote:
> On Thu, 2011-11-17 at 19:25 +0000, Neil Horman wrote:
> > On Thu, Nov 17, 2011 at 03:20:38PM +0000, Ian Campbell wrote:
> > > On Mon, 2011-11-14 at 14:22 -0500, Neil Horman wrote:
> > > > It was pointed out to me recently that the xen-netfront driver can't safely
> > > > support shared skbs on transmit, since, while it doesn't maintain skb state
> > > > directly, it does pass a pointer to the skb to the hypervisor via a list, and
> > > > the hypervisor may expect the contents of the skb to remain stable.  Clearing
> > > > the IFF_TX_SKB_SHARING flag after the call to alloc_etherdev to make it safe.
> > > 
> > > What are the actual constraints here? The skb is used as a handle to the
> > > skb->data and shinfo (frags) and to complete at the end. It's actually
> > > those which are passed to the hypervisor (effectively the same as
> > > passing those addresses to the h/w for DMA).
> > > 
> > > Which parts of the skb are expected/allowed to not remain stable?
> > > 
> > > (Appologies if the above seems naive, I seem to have missed the
> > > introduction of shared tx skbs and IFF_TX_SKB_SHARING)
> > > 
> > Its ok, this is the most accurate description from the previous threads on the
> > subject:
> > http://lists.openwall.net/netdev/2011/08/22/63
> > 
> > The basic problem boils down the notion that some drivers, when they receive an
> > skb in their xmit paths, presume to have sole ownership of the skb, and as a
> > result may do things like add the skb to a list, or otherwise store stateful
> > data in the skb.  If the skb is shared, thats unsafe to do, as the stack still
> > holds a reference to the skb, and make make changes without serializing them
> > against the driver.  So we have to flag those drivers which preform these kinds
> > of actions.  xen-netfront doesn't strictly speaking modify any state directly ni
> > an skb, but it does place a pointer to the skb in a data structure here:
> > 
> > np->tx_skbs[id].skb = skb;
> > 
> > Which then gets handed off to the hypervisior.  Since the hypervisor now has
> > access to that skb pointer, and we can't be sure (from the guest perspective),
> > what it does with that information, it would be better to be safe by disallowing
> > shared skbs in this path.
> 
> The skb pointer itself doesn't get given to the backend/hypervisor. The
> page which skb->data refers to is granted to the backend domain, as are
> the pages in the frags.
> 
> I think we only need to be sure that the frontend doesn't rely on
> anything in the skb itself, right? Does skb->data or shinfo count from
> that perspective?
shinfo is definately a problem, as other devices may make modifications to it.
skb->data is probably safer, but is also potentially suspect (for instance if
another device appends an additional header to the data for instance)
Neil
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html