netdev - Re: [ovs-dev] [PATCH v2.56] datapath: Add basic MPLS support to kernel

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 Apr 2014 16:00:12 +0900
From:	Simon Horman <horms@...ge.net.au>
To:	Jesse Gross <jesse@...ira.com>
Cc:	YAMAMOTO Takashi <yamamoto@...inux.co.jp>,
	"dev@...nvswitch.org" <dev@...nvswitch.org>,
	netdev <netdev@...r.kernel.org>,
	Pravin Shelar <pshelar@...ira.com>,
	ravi kerur <rkerur@...il.com>
Subject: Re: [ovs-dev] [PATCH v2.56] datapath: Add basic MPLS support to
 kernel

On Fri, Apr 25, 2014 at 12:57:20PM -0700, Jesse Gross wrote:
> On Fri, Apr 25, 2014 at 1:06 AM, YAMAMOTO Takashi
> <yamamoto@...inux.co.jp> wrote:
> >> On Thu, Apr 24, 2014 at 05:57:29PM +0900, YAMAMOTO Takashi wrote:
> >>> hi,
> >>>
> >>> > + * Due to the sample action there may be multiple possible eth types.
> >>> > + * In order to correctly validate actions all possible types are tracked
> >>> > + * and verified. This is done using struct eth_types.
> >>>
> >>> is there any real-world use cases of these actions inside a sample?
> >>> otherwise, how about just rejecting such combinations?
> >>> it doesn't seem to worth the code complexity to me.
> >>> (sorry if it has been already discussed.  it's the first time for me
> >>> to seriously read this long-lived patch.)
> >>
> >> Good point, the code is rather complex.
> >>
> >> My understanding is that it comes into effect in the case
> >> of sflow or ipfix being configured on the bridge. I tend
> >> to think these are real-world use-cases, though that thinking
> >> is by no means fixed.
> >>
> >> My reading of the code is that in the case of sflow and ipfix a single
> >> sample rule appears at the beginning of the flow. And that it may be
> >> possible to replace the code that you are referring to with something
> >> simpler to handle these cases.
> >
> > it seems that they put only a userland action inside a sample.
> > it's what i expected from its name "sample".
> 
> Yes, that's the only current use case. In theory, this could be used
> more generally although nothing has come up yet.
> 
> In retrospect, I regret the design of the sample action - not the part
> that allows it to handle different actions but the fact that the
> results can affect things outside of the sample action list. I think
> that if we had made it more like a subroutine then that would have
> retained all of the functionality but none of the complexity here.
> Perhaps if we can find a clean way to restructure it without breaking
> compatibility then that would simplify the validation here.

I have not thought deeply about this but it seems to me that it should be
easy enough to provide compatibility for a new user-space to work with both
new and old datapaths.  But it is not clear to me how to achieve the
reverse: allowing a new datapath to work with both new and old user-spaces.
I assume that we care about such compatibility.

> >> My understanding is that the code you are referring to also comes into
> >> effect when a sample action (a Nicira extension) is used directly in a
> >> rule.  I am less sure that this is a real-world case but the complex logic
> >> you are referring to should to handle this use-case.
> >
> > probably nicira folks can clarify?
> 
> It's the same set of use cases, just extending it to OpenFlow to
> enable building sampling into different situations.
--
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