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: <20124540-D566-41B0-B86F-0BCA19B948AA@nicira.com>
Date:	Mon, 28 Nov 2011 10:44:48 -0800
From:	Justin Pettit <jpettit@...ira.com>
To:	Jamal Hadi Salim <jhs@...atatu.com>
Cc:	"Fischer, Anna" <anna.fischer@...com>,
	"dev@...nvswitch.org" <dev@...nvswitch.org>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	Herbert Xu <herbert@...dor.apana.org.au>,
	David Miller <davem@...emloft.net>
Subject: Re: [ovs-dev] Issues with openflow protocol WAS(RE: [GIT PULL v2] Open vSwitch

On Nov 28, 2011, at 6:07 AM, Jamal Hadi Salim wrote:

> On Mon, 2011-11-28 at 13:54 +0000, Fischer, Anna wrote:
> 
>> 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.
> 
> Good - more folks scrutinizing openflow ;->

I realize you chair an IETF standard with overlapping goals with
OpenFlow (ForCES), so you may have strong opinions about its design.
However, that's not relevant to this discussion, since OpenFlow's design
has nothing to do with the discussion being held here in regards to Open
vSwitch.  OpenFlow is just a bullet point--although an important one--in
a large set of features that Open vSwitch provides.  Its design is such
that it should be fairly easy to include new control protocols; OpenFlow
is just a library in Open vSwitch.  If you have issues with OpenFlow,
those would be better directed to the ONF or one of the OpenFlow mailing
lists.

--Justin

> That would resolve the kernel->user if in addition you then add
> prioritization of those queues. 
> But even then also the same problem exists with open flow in the 
> northbound direction towards the external controller where
> there is a single (TCP) socket.
> 
> cheers,
> jamal
> 
> _______________________________________________
> dev mailing list
> dev@...nvswitch.org
> http://openvswitch.org/mailman/listinfo/dev

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ