netdev - Re: tap/bridge: Dropping NETIF_F_GSO/NETIF_F

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: <20110517051845.GA26414@redhat.com>
Date:	Tue, 17 May 2011 08:18:45 +0300
From:	"Michael S. Tsirkin" <mst@...hat.com>
To:	Herbert Xu <herbert@...dor.hengli.com.au>
Cc:	David Miller <davem@...emloft.net>, mirqus@...il.com,
	shanwei@...fujitsu.com, mirq-linux@...e.qmqm.pl,
	netdev@...r.kernel.org, bhutchings@...arflare.com
Subject: Re: tap/bridge: Dropping NETIF_F_GSO/NETIF_F_SG

On Tue, May 17, 2011 at 09:45:38AM +1000, Herbert Xu wrote:
> On Mon, May 16, 2011 at 07:06:15PM -0400, David Miller wrote:
> >
> > Well the check has to exist somewhere.
> > 
> > Currently userspace can configure tun/tap into whatever set
> > of offloads it likes.
> > 
> > We're warning when the user asks for something that needs to be
> > corrected.  So the only thing you can suggest is to duplicate these
> > changes in the tun/tap driver.
> > 
> > But if we do that, and error on bad combinations instead of fixing
> > them up, we know from this discussion that existing virtualization
> > setups and tools are going to stop working.
> 
> Yeah the tun driver is simply busted.  We should never have allowed
> user-space to tweak the feature bits like this.  Instead they should
> have gone through the ethtool interface like everyone else, or at
> least use the same underlying calls as ethtool.
> 
> Actually, I think we can still do that, and apply the same rules
> as ethtool with respect to automatically turning things on/off.
> 
> AFAICS the current set_offload in tun.c does not call anything
> that verifies/fixes up the settings.  If you change the feature
> bits after registering the tun device it may never get fixed up
> at all.

Hmm, we get the warnings about bits dropped on each set_offload
call:
	netdev_update_features is called,
	that calls netdev_fix_features

No?

> Allowing an unprivileged user to tweak feature bits directly with
> no verification is just wrong.
> 
> Cheers,

But we do verify bits, and only allow the user
to tweak these ones:

#define TUN_USER_FEATURES (NETIF_F_HW_CSUM|NETIF_F_TSO_ECN|NETIF_F_TSO|
\
                          NETIF_F_TSO6|NETIF_F_UFO)

No?

> -- 
> Email: Herbert Xu <herbert@...dor.apana.org.au>
> Home Page: http://gondor.apana.org.au/~herbert/
> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
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