netdev - Re: [rfc] Merging the Open vSwitch datapath

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: <201008311943.52955.arnd@arndb.de>
Date:	Tue, 31 Aug 2010 19:43:52 +0200
From:	Arnd Bergmann <arnd@...db.de>
To:	"Rose, Gregory V" <gregory.v.rose@...el.com>
Cc:	Ben Pfaff <blp@...ira.com>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	Jesse Gross <jesse@...ira.com>,
	Stephen Hemminger <shemminger@...ux-foundation.org>,
	Chris Wright <chrisw@...s-sol.org>,
	Herbert Xu <herbert@...dor.apana.org.au>,
	David Miller <davem@...emloft.net>
Subject: Re: [rfc] Merging the Open vSwitch datapath

On Tuesday 31 August 2010, Rose, Gregory V wrote:
> >
> >Exactly! The problem is that I don't think any edge virtual bridge
> >can ever implement the full set of features we have in software,
> >and for this reason I wouldn't spend too much time in adding a small
> >subset of the features.
> 
> Not sure I agree there.  I've gotten specific requests for a small
> number of features that would make an embedded NIC switch useful
> to some customers.

That should be fine. Adding a small number of features probably
works well enough using extensions to the existing VF_INFO netlink
attributes, like a way to configure ports into VEPA mode.

I'm totally fine with making small additions here, which is something
completely different from extending the interface to the point where
it mimics all the features we have in the linux bridge code.

> No need to implement all of them but there are a small subset of
> useful rules and associated actions that would be very useful on
> the embedded switch of an SR-IOV capable NIC.  And these rules 
> and actions would actually promote security from my point of view.
> I agree that the embedded NIC switch will never (and should never)
> attempt to implement all the features a full fledged external
> switch.  But as things stand now embedded NIC switches are so 
> dumb as to be almost useless for most security conscious
> virtualized applications.  With the implementation of a small 
> set of rules and associated actions we could make them more
> useful for a number of our customers.

Right. Can you share your specific requirements with the rest of us?
Maybe start a new email thread with the same people on it, since
this is now really an Open vSwitch topic.

> Alright, I'm sort of new to Linux.  Most of my past experience 
> is in the embedded space and is more device oriented so I
> definitely appreciate getting your perspective on this.
> Like many folks I just have product features that I need to make 
> available to customers.  Finding a way to do this that is 
> acceptable to the Linux community and promotes the common welfare
> (so to speak) is all I'm trying to do here.

Ok, cool. Now I think that getting an interface that fits the needs
of the NIC and Open vSwitch would be great for both Open vSwitch and
every NIC vendor implementing it, because it means that you can simply
add a smart NIC and Open vSwitch will run faster without any changes to
the software setup.
Even better for you if you are the first one on the market to implement
it in hardware ;-)

You should probably take a look at the current ioctl based implementation
in Open vSwitch and figure out if you could make that interface would work
on your NIC, and if not, tell us all what is missing to make that work
with the new interface.

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