> 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. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
