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: <20111128130409.GB16828@gondor.apana.org.au>
Date:	Mon, 28 Nov 2011 21:04:10 +0800
From:	Herbert Xu <herbert@...dor.apana.org.au>
To:	jhs@...atatu.com
Cc:	David Miller <davem@...emloft.net>, jesse@...ira.com,
	netdev@...r.kernel.org, dev@...nvswitch.org
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.

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