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]

Date:	Mon, 28 Nov 2011 09:02:34 -0500
From:	Jamal Hadi Salim <jhs@...atatu.com>
To:	Herbert Xu <herbert@...dor.apana.org.au>
Cc:	David Miller <davem@...emloft.net>, jesse@...ira.com,
	netdev@...r.kernel.org, dev@...nvswitch.org
Subject: Re: [GIT PULL v2] Open vSwitch

On Mon, 2011-11-28 at 21:04 +0800, Herbert Xu wrote:

> 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.

Thanks for validating Herbert. 

> Whether we want to go down this route though is open to debate
> as someone would have to actually implement this :)

I empathize that effort has been invested in coding the way it was. 
But this is where an RFC to netdev would have been useful instead of
reinventing things. I dont see it as a huge effort really; the
refactoring should be mostly in user space.

Along the same lines:
Even for the integration with existing silicon I am worried that using
openvswitch as a proxy is not the right thing to do (the Intel approach
or the DSA approach where Linux is the proxy is the right thing to
do(TM).

> 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.

Indeed this is an issue with openflow in general.
The general solution is to rate limit how much goes to the controller
but even that is insufficient.

cheers,
jamal

--
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