netdev - RE: [GIT PULL v2] Open vSwitch

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: <0199E0D51A61344794750DC57738F58E7586A74137@GVW1118EXC.americas.hpqcorp.net>
Date:	Mon, 28 Nov 2011 13:54:16 +0000
From:	"Fischer, Anna" <anna.fischer@...com>
To:	Herbert Xu <herbert@...dor.apana.org.au>,
	"jhs@...atatu.com" <jhs@...atatu.com>
CC:	David Miller <davem@...emloft.net>,
	"jesse@...ira.com" <jesse@...ira.com>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"dev@...nvswitch.org" <dev@...nvswitch.org>
Subject: RE: [GIT PULL v2] Open vSwitch

> Subject: Re: [GIT PULL v2] Open vSwitch
> 
> On Wed, Nov 23, 2011 at 07:22:56AM -0500, jamal wrote:
> >
> > For a classifier, u32 or em matches would do the job  - but they may
> > need a wrapper around it in user space; so from a usability pov, it
> > would make sense to have a new classifier that is specific to them.
> > All the VLAN actions could go into one tc action; the checksum action
> > is already present. The IP/TCP/UDP header re-writes may require
> > their own actions - I think one would be sufficient for all.
> > So in my estimate one classifier and two actions.
> > Then you get rid of half the code (they use generic netlink to
> set/get
> > policies)
> 
> You're right, a new classifier for the hash table would be the
> best option.
> 
> > I cant find one - you may. After staring at the code, I am also now
> > questioning if the existing bridge code couldnt have been re-used
> with
> > some small tweaks.
> 
> I wasn't able to find any functionality that could not be easily
> done with the existing classifier/action code.
> 
> Whether we want to go down this route though is open to debate
> as someone would have to actually implement this :)
> 
> However, what's more worrying for me right now is the gaping
> DoS opportunities that exist in the patch as is.
> 
> In particular, the whole design principle of punting all new
> flows to user-space is an excellent way of attacking the system.
> 
> A would-be attacker would only need to continuously inject new
> flows to prevent flow creation on all ports, since every single
> port on a data path shares the same receive queue in user-space.
> 
> Considering that this is meant to be used in virtualisation
> environments, where hostile entities may indeed exist on the
> network, I think this needs to be addressed.

Yes, I mentioned this months ago, and I am surprised this critical issue has never been picked up on and addressed. With a flaw like this there is no chance this component can be used in any serious virtualization deployment where different customers share the same physical server.

The path up to user-space needs to be designed in a multi-queue fashion, so that each vPort has its own queue up to user-space. Ideally those queues also need to be rate controlled in some form, so that no DoS is possible.
--
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