Re: [ovs-dev] [PATCH net] gso: do GSO for local skb with size bigger than MTU
于 2015年01月08日 04:52, Jesse Gross 写道: My understanding is: >controller sets the forwarding rules into kernel datapath, any flow not >matching >with the rules are threw to controller by upcall. Once the rule decision is >made >by controller, then, this flow packet is pushed down to datapath to be >forwarded >again according to the new rule. > >So I'm not sure whether pushing the over-MTU-sized packet or pushing the >forged ICMP >without encapsulation to controller is required by current ovs >implementation. By doing >so, such over-MTU-sized packet is treated as a event for the controller to >be take >care of. If flows are implementing routing (again, they are doing things like decrementing the TTL) then it is necessary for them to also handle this situation using some potentially new primitives (like a size check). Otherwise you end up with issues like the ones that I mentioned above like needing to forge addresses because you don't know what the correct ones are. Thanks for explaining, Jesse! btw, I don't get it about "to forge addresses", building ICMP message with Guest packet doesn't require to forge address when not encapsulating ICMP message with outer headers. If the flows aren't doing things to implement routing, then you really have a flat L2 network and you shouldn't be doing this type of behavior at all as I described in the original plan. For flows implementing routing scenario: First of all, over-MTU-sized packet could only be detected once the flow as been consulted(each port could implement a 'check' hook to do this), and just before send to the actual port. Then pushing the over-MTU-sized packet back to controller, it's the controller who will will decide whether to build ICMP message, or whatever routing behaviour it may take. And sent it back with the port information. This ICMP message will travel back to Guest. Why does the flow has to use primitive like a "check size"? "check size" will only take effect after do_output. I'm not very clear with this approach. And not all scenario involving flow with routing behaviour, just set up a vxlan tunnel, and attach KVM guest or Docker onto it for playing or developing. This wouldn't necessarily require user to set additional specific flows to make over-MTU-sized packet pass through the tunnel correctly. In such scenario, I think the original patch in this thread to fragment tunnel packet is still needed OR workout a generic component to build ICMP for all type tunnel in L2 level. Both of those will act as a backup plan as there is no such specific flow as default. If I missed something obviously, please let me know. -- No zuo no die but I have to try. ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH 6/6] openvswitch: Support VXLAN Group Policy extension
On 01/07/15 at 05:18pm, Jesse Gross wrote: > On Wed, Jan 7, 2015 at 3:01 PM, Thomas Graf wrote: > > The encoding will be based on struct ovs_vxlan_opts which is extended > > as needed by appending new members to the end of the struct. Parsers > > will look at the provided length to see which fields are provided. > > But this means that if there are two extensions that are conflicting > or if one is retired you still need to carry the earlier members of > the struct. Why not make them real netlink attributes? I figured that due to the limited space available in the VXLAN header the structure would never grow big. I have no problem converting this to use Netlink attributes internally though. Will address this in v2. ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
[ovs-dev] Vmworld conference
Hi, I searched your company from *Vmworld conference* which was hosted by *VMware* and thought you would be interested in knowing best returns for your investment. We do provide *B2B* contacts from below mentioned products: *VMware NetApp Oracle’s VirtuaBox REVH Amazon Citrix Cloud Computing Networking and many more as per your requirement* *We also provide:* IT Decision Makers, Sales and Marketing Decision Makers, C-level Titles and other titles as per your requirement. Please review and let me know your requirement and I will get back to you with more information regarding the same. Thanks *Benita Linda* Data Specialist If you are not the right person, feel free to forward this email to the right person in your organization. To opt out response Remove ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
[ovs-dev] Vmworld conference
Hi, I searched your company from *Vmworld conference* which was hosted by *VMware* and thought you would be interested in knowing best returns for your investment. We do provide *B2B* contacts from below mentioned products: *VMware NetApp Oracle’s VirtuaBox REVH Amazon Citrix Cloud Computing Networking and many more as per your requirement* *We also provide:* IT Decision Makers, Sales and Marketing Decision Makers, C-level Titles and other titles as per your requirement. Please review and let me know your requirement and I will get back to you with more information regarding the same. Thanks *Benita Linda* Data Specialist If you are not the right person, feel free to forward this email to the right person in your organization. To opt out response Remove ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
[ovs-dev] Vmworld conference
Hi, I searched your company from *Vmworld conference* which was hosted by *VMware* and thought you would be interested in knowing best returns for your investment. We do provide *B2B* contacts from below mentioned products: *VMware NetApp Oracle’s VirtuaBox REVH Amazon Citrix Cloud Computing Networking and many more as per your requirement* *We also provide:* IT Decision Makers, Sales and Marketing Decision Makers, C-level Titles and other titles as per your requirement. Please review and let me know your requirement and I will get back to you with more information regarding the same. Thanks *Benita Linda* Data Specialist If you are not the right person, feel free to forward this email to the right person in your organization. To opt out response Remove ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH] Update SECURITY.md
On Thursday, January 08, 2015 11:14:40 AM Andrew Kampjes wrote: > Include more specific GPG recomendation usage. > Add generalised rules for vulnerabilties. > > Signed-off-by: Andrew Kampjes > --- > SECURITY.md | 41 + > 1 file changed, 29 insertions(+), 12 deletions(-) > > diff --git a/SECURITY.md b/SECURITY.md > index d558d44..c85e594 100644 > --- a/SECURITY.md > +++ b/SECURITY.md > @@ -23,25 +23,33 @@ What is a vulnerability? > > > All vulnerabilities are bugs, but not every bug is a vulnerability. > +Vulnerabilites compromise one or more of: > + > +* Confidentiality (Personal and company data/secrets). > +* Integrity (trustworthyness and correctness). > +* Availability (Uptime and service). > + > Here are some examples of vulnerabilities to which one would expect to > apply this process: > > -* A crafted packet that causes a kernel or userspace crash. > +* A crafted packet that causes a kernel or userspace crash > + (Availability). > > * A flow translation bug that misforwards traffic in a way likely > - to hop over security boundaries. > + to hop over security boundaries (Integrity). > > * An OpenFlow protocol bug that allows a controller to read > - arbitrary files from the file system. > + arbitrary files from the file system (Confidentiality). > > * Misuse of the OpenSSL library that allows bypassing certificate > - checks. > + checks (Integrity). > > * A bug (memory corruption, overflow, ...) that allows one to >modify the behaviour of OVS through external configuration > - interfaces such as OVSDB. > + interfaces such as OVSDB (Integrity). > > -* Privileged information is exposed to unprivileged users. > +* Privileged information is exposed to unprivileged users > + (Confidentiality). > > If in doubt, please do use the vulnerability management process. At > worst, the response will be to report the bug through the usual > @@ -53,8 +61,17 @@ Step 1: Reception > > To report an Open vSwitch vulnerability, send an email to the > ovs-security mailing list (see "Contact" at the end of this document). > -A security team member should reply to the reporter acknowledging that > -the report has been received. > +A security team member should reply to the reporter within 24 hours > +acknowledging that the report has been received. There is no on-call team as far as know. Perhaps Ben can confirm that. So issues reported during holidays or weekends may take more than 24 hours to get a reply. My concern here is that it will create a non practical expectation. Perhaps something like this: A security team member should reply to the reporter within 24 hours on business days acknowledging that the report has been received. > +Reporters may ask for a GPG key while initiating contact with the > +security team to deliver more sensitive reports. > +If the reporter has used GPG while disclosing, further vulnerability > +details should also be discussed using GPG. > + > +Please don't report security vulnerabilities to the ovs-dev list, > +ovs-bug list or github issues to allow the team ovs security team > +to responsibly fix the vulnerability. It looks more clear/effective to me if we swap the two paragraphs. I mean, first tell to not report on ovs-dev and then talk about GPG details... fbl > Please consider reporting the information mentioned in > REPORTING-BUGS.md, where relevant. > @@ -132,11 +149,11 @@ vSwitch user who is interested and can be considered > trustworthy > enough could be included. To become a downstream stakeholder, email > the ovs-security mailing list. > > -If the vulnerability is public, skip this step. > +If the vulnerability is already public, skip this step. > > > -Step 5: Full Disclosure > > +Step 5: Public Disclosure > +- > > When the embargo expires, push the (reviewed) patches to appropriate > branches, post the patches to the ovs-dev mailing list (noting that > @@ -151,7 +168,7 @@ The security advisory should be GPG-signed by a security > team member > with a key that is in a public web of trust. > > > -Contact > +Contact > === > > Report security vulnerabilities to the ovs-security mailing list: > ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH net] gso: do GSO for local skb with size bigger than MTU
On Thu, Jan 8, 2015 at 1:39 AM, Fan Du wrote: > 于 2015年01月08日 04:52, Jesse Gross 写道: >>> >>> My understanding is: >>> >controller sets the forwarding rules into kernel datapath, any flow not >>> >matching >>> >with the rules are threw to controller by upcall. Once the rule decision >>> > is >>> >made >>> >by controller, then, this flow packet is pushed down to datapath to be >>> >forwarded >>> >again according to the new rule. >>> > >>> >So I'm not sure whether pushing the over-MTU-sized packet or pushing the >>> >forged ICMP >>> >without encapsulation to controller is required by current ovs >>> >implementation. By doing >>> >so, such over-MTU-sized packet is treated as a event for the controller >>> > to >>> >be take >>> >care of. >> >> If flows are implementing routing (again, they are doing things like >> decrementing the TTL) then it is necessary for them to also handle >> this situation using some potentially new primitives (like a size >> check). Otherwise you end up with issues like the ones that I >> mentioned above like needing to forge addresses because you don't know >> what the correct ones are. > > > Thanks for explaining, Jesse! > > btw, I don't get it about "to forge addresses", building ICMP message > with Guest packet doesn't require to forge address when not encapsulating > ICMP message with outer headers. Your patch has things like this (for the inner IP header): + new_ip->saddr = orig_ip->daddr; + new_ip->daddr = orig_ip->saddr; These addresses are owned by the endpoints, not the host generating generating the ICMP message, so I would consider that to be forging addresses. > If the flows aren't doing things to >> >> implement routing, then you really have a flat L2 network and you >> shouldn't be doing this type of behavior at all as I described in the >> original plan. > > > For flows implementing routing scenario: > First of all, over-MTU-sized packet could only be detected once the flow > as been consulted(each port could implement a 'check' hook to do this), > and just before send to the actual port. > > Then pushing the over-MTU-sized packet back to controller, it's the > controller > who will will decide whether to build ICMP message, or whatever routing > behaviour > it may take. And sent it back with the port information. This ICMP message > will > travel back to Guest. > > Why does the flow has to use primitive like a "check size"? "check size" > will only take effect after do_output. I'm not very clear with this > approach. Checking the size obviously needs to be an action that would take place before outputting in order for it to have any effect. Attaching a check to a port does not fit in very well with the other primitives of OVS, so I think an action is the obvious place to put it. > And not all scenario involving flow with routing behaviour, just set up a > vxlan tunnel, and attach KVM guest or Docker onto it for playing or > developing. > This wouldn't necessarily require user to set additional specific flows to > make > over-MTU-sized packet pass through the tunnel correctly. In such scenario, I > think the original patch in this thread to fragment tunnel packet is still > needed > OR workout a generic component to build ICMP for all type tunnel in L2 > level. > Both of those will act as a backup plan as there is no such specific flow as > default. In these cases, we should find a way to adjust the MTU, preferably automatically using virtio. ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH] automake: fix file paths for out-of-tree builds
You are right. I will drop the patch. On Wed, Jan 7, 2015 at 7:27 PM, Ben Pfaff wrote: > On Wed, Jan 07, 2015 at 07:55:11PM -0800, Andy Zhou wrote: >> Out of tree builds failed when trying to find the er-diagram *.pic >> files. Fixing by adding proper source path. >> >> Signed-off-by: Andy Zhou > > I don't understand this patch. vswitch.pic is generated in the build > directory: > >> vswitchd/vswitch.pic: vswitchd/vswitch.gv ovsdb/dot2pic >> $(AM_V_GEN)(dot -T plain < vswitchd/vswitch.gv | $(PERL) >> $(srcdir)/ovsdb/dot2pic -f 3) > $@.tmp && \ >> mv $@.tmp $@ > > so I don't understand why one would look for it in the source directory: > >> -VSWITCH_PIC = vswitchd/vswitch.pic >> +VSWITCH_PIC = $(srcdir)/vswitchd/vswitch.pic > > Thanks, > > Ben. ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH] Update SECURITY.md
Both good points, thanks Flavio. Ben, can you confirm what the expectation for response should be? Will swap those paragraphs too. On 9 January 2015 at 05:11, Flavio Leitner wrote: > On Thursday, January 08, 2015 11:14:40 AM Andrew Kampjes wrote: > > Include more specific GPG recomendation usage. > > Add generalised rules for vulnerabilties. > > > > Signed-off-by: Andrew Kampjes > > --- > > SECURITY.md | 41 + > > 1 file changed, 29 insertions(+), 12 deletions(-) > > > > diff --git a/SECURITY.md b/SECURITY.md > > index d558d44..c85e594 100644 > > --- a/SECURITY.md > > +++ b/SECURITY.md > > @@ -23,25 +23,33 @@ What is a vulnerability? > > > > > > All vulnerabilities are bugs, but not every bug is a vulnerability. > > +Vulnerabilites compromise one or more of: > > + > > +* Confidentiality (Personal and company data/secrets). > > +* Integrity (trustworthyness and correctness). > > +* Availability (Uptime and service). > > + > > Here are some examples of vulnerabilities to which one would expect to > > apply this process: > > > > -* A crafted packet that causes a kernel or userspace crash. > > +* A crafted packet that causes a kernel or userspace crash > > + (Availability). > > > > * A flow translation bug that misforwards traffic in a way likely > > - to hop over security boundaries. > > + to hop over security boundaries (Integrity). > > > > * An OpenFlow protocol bug that allows a controller to read > > - arbitrary files from the file system. > > + arbitrary files from the file system (Confidentiality). > > > > * Misuse of the OpenSSL library that allows bypassing certificate > > - checks. > > + checks (Integrity). > > > > * A bug (memory corruption, overflow, ...) that allows one to > >modify the behaviour of OVS through external configuration > > - interfaces such as OVSDB. > > + interfaces such as OVSDB (Integrity). > > > > -* Privileged information is exposed to unprivileged users. > > +* Privileged information is exposed to unprivileged users > > + (Confidentiality). > > > > If in doubt, please do use the vulnerability management process. At > > worst, the response will be to report the bug through the usual > > @@ -53,8 +61,17 @@ Step 1: Reception > > > > To report an Open vSwitch vulnerability, send an email to the > > ovs-security mailing list (see "Contact" at the end of this document). > > -A security team member should reply to the reporter acknowledging that > > -the report has been received. > > +A security team member should reply to the reporter within 24 hours > > +acknowledging that the report has been received. > > There is no on-call team as far as know. Perhaps Ben can confirm that. > So issues reported during holidays or weekends may take more than > 24 hours to get a reply. My concern here is that it will create a non > practical expectation. > > Perhaps something like this: > A security team member should reply to the reporter within 24 hours > on business days acknowledging that the report has been received. > > > +Reporters may ask for a GPG key while initiating contact with the > > +security team to deliver more sensitive reports. > > +If the reporter has used GPG while disclosing, further vulnerability > > +details should also be discussed using GPG. > > + > > +Please don't report security vulnerabilities to the ovs-dev list, > > +ovs-bug list or github issues to allow the team ovs security team > > +to responsibly fix the vulnerability. > > It looks more clear/effective to me if we swap the two > paragraphs. I mean, first tell to not report on ovs-dev and > then talk about GPG details... > > fbl > > > Please consider reporting the information mentioned in > > REPORTING-BUGS.md, where relevant. > > @@ -132,11 +149,11 @@ vSwitch user who is interested and can be > considered trustworthy > > enough could be included. To become a downstream stakeholder, email > > the ovs-security mailing list. > > > > -If the vulnerability is public, skip this step. > > +If the vulnerability is already public, skip this step. > > > > > > -Step 5: Full Disclosure > > > > +Step 5: Public Disclosure > > +- > > > > When the embargo expires, push the (reviewed) patches to appropriate > > branches, post the patches to the ovs-dev mailing list (noting that > > @@ -151,7 +168,7 @@ The security advisory should be GPG-signed by a > security team member > > with a key that is in a public web of trust. > > > > > > -Contact > > +Contact > > === > > > > Report security vulnerabilities to the ovs-security mailing list: > > > > ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH] Update SECURITY.md
I don't know what to say for response time. In general I expect it to be pretty fast for anything that is clearly urgent. On Fri, Jan 09, 2015 at 09:48:11AM +1300, Andrew Kampjes wrote: > Both good points, thanks Flavio. > Ben, can you confirm what the expectation for response should be? > > Will swap those paragraphs too. > > On 9 January 2015 at 05:11, Flavio Leitner wrote: > > > On Thursday, January 08, 2015 11:14:40 AM Andrew Kampjes wrote: > > > Include more specific GPG recomendation usage. > > > Add generalised rules for vulnerabilties. > > > > > > Signed-off-by: Andrew Kampjes > > > --- > > > SECURITY.md | 41 + > > > 1 file changed, 29 insertions(+), 12 deletions(-) > > > > > > diff --git a/SECURITY.md b/SECURITY.md > > > index d558d44..c85e594 100644 > > > --- a/SECURITY.md > > > +++ b/SECURITY.md > > > @@ -23,25 +23,33 @@ What is a vulnerability? > > > > > > > > > All vulnerabilities are bugs, but not every bug is a vulnerability. > > > +Vulnerabilites compromise one or more of: > > > + > > > +* Confidentiality (Personal and company data/secrets). > > > +* Integrity (trustworthyness and correctness). > > > +* Availability (Uptime and service). > > > + > > > Here are some examples of vulnerabilities to which one would expect to > > > apply this process: > > > > > > -* A crafted packet that causes a kernel or userspace crash. > > > +* A crafted packet that causes a kernel or userspace crash > > > + (Availability). > > > > > > * A flow translation bug that misforwards traffic in a way likely > > > - to hop over security boundaries. > > > + to hop over security boundaries (Integrity). > > > > > > * An OpenFlow protocol bug that allows a controller to read > > > - arbitrary files from the file system. > > > + arbitrary files from the file system (Confidentiality). > > > > > > * Misuse of the OpenSSL library that allows bypassing certificate > > > - checks. > > > + checks (Integrity). > > > > > > * A bug (memory corruption, overflow, ...) that allows one to > > >modify the behaviour of OVS through external configuration > > > - interfaces such as OVSDB. > > > + interfaces such as OVSDB (Integrity). > > > > > > -* Privileged information is exposed to unprivileged users. > > > +* Privileged information is exposed to unprivileged users > > > + (Confidentiality). > > > > > > If in doubt, please do use the vulnerability management process. At > > > worst, the response will be to report the bug through the usual > > > @@ -53,8 +61,17 @@ Step 1: Reception > > > > > > To report an Open vSwitch vulnerability, send an email to the > > > ovs-security mailing list (see "Contact" at the end of this document). > > > -A security team member should reply to the reporter acknowledging that > > > -the report has been received. > > > +A security team member should reply to the reporter within 24 hours > > > +acknowledging that the report has been received. > > > > There is no on-call team as far as know. Perhaps Ben can confirm that. > > So issues reported during holidays or weekends may take more than > > 24 hours to get a reply. My concern here is that it will create a non > > practical expectation. > > > > Perhaps something like this: > > A security team member should reply to the reporter within 24 hours > > on business days acknowledging that the report has been received. > > > > > +Reporters may ask for a GPG key while initiating contact with the > > > +security team to deliver more sensitive reports. > > > +If the reporter has used GPG while disclosing, further vulnerability > > > +details should also be discussed using GPG. > > > + > > > +Please don't report security vulnerabilities to the ovs-dev list, > > > +ovs-bug list or github issues to allow the team ovs security team > > > +to responsibly fix the vulnerability. > > > > It looks more clear/effective to me if we swap the two > > paragraphs. I mean, first tell to not report on ovs-dev and > > then talk about GPG details... > > > > fbl > > > > > Please consider reporting the information mentioned in > > > REPORTING-BUGS.md, where relevant. > > > @@ -132,11 +149,11 @@ vSwitch user who is interested and can be > > considered trustworthy > > > enough could be included. To become a downstream stakeholder, email > > > the ovs-security mailing list. > > > > > > -If the vulnerability is public, skip this step. > > > +If the vulnerability is already public, skip this step. > > > > > > > > > -Step 5: Full Disclosure > > > > > > +Step 5: Public Disclosure > > > +- > > > > > > When the embargo expires, push the (reviewed) patches to appropriate > > > branches, post the patches to the ovs-dev mailing list (noting that > > > @@ -151,7 +168,7 @@ The security advisory should be GPG-signed by a > > security team member > > > with
Re: [ovs-dev] [PATCH] Update SECURITY.md
I change back to a more general statement, given that we can't really guarantee a response time. On Fri Jan 09 2015 at 09:54:03 Ben Pfaff wrote: > I don't know what to say for response time. In general I expect it to > be pretty fast for anything that is clearly urgent. > > On Fri, Jan 09, 2015 at 09:48:11AM +1300, Andrew Kampjes wrote: > > Both good points, thanks Flavio. > > Ben, can you confirm what the expectation for response should be? > > > > Will swap those paragraphs too. > > > > On 9 January 2015 at 05:11, Flavio Leitner wrote: > > > > > On Thursday, January 08, 2015 11:14:40 AM Andrew Kampjes wrote: > > > > Include more specific GPG recomendation usage. > > > > Add generalised rules for vulnerabilties. > > > > > > > > Signed-off-by: Andrew Kampjes > > > > --- > > > > SECURITY.md | 41 + > > > > 1 file changed, 29 insertions(+), 12 deletions(-) > > > > > > > > diff --git a/SECURITY.md b/SECURITY.md > > > > index d558d44..c85e594 100644 > > > > --- a/SECURITY.md > > > > +++ b/SECURITY.md > > > > @@ -23,25 +23,33 @@ What is a vulnerability? > > > > > > > > > > > > All vulnerabilities are bugs, but not every bug is a vulnerability. > > > > +Vulnerabilites compromise one or more of: > > > > + > > > > +* Confidentiality (Personal and company data/secrets). > > > > +* Integrity (trustworthyness and correctness). > > > > +* Availability (Uptime and service). > > > > + > > > > Here are some examples of vulnerabilities to which one would expect > to > > > > apply this process: > > > > > > > > -* A crafted packet that causes a kernel or userspace crash. > > > > +* A crafted packet that causes a kernel or userspace crash > > > > + (Availability). > > > > > > > > * A flow translation bug that misforwards traffic in a way > likely > > > > - to hop over security boundaries. > > > > + to hop over security boundaries (Integrity). > > > > > > > > * An OpenFlow protocol bug that allows a controller to read > > > > - arbitrary files from the file system. > > > > + arbitrary files from the file system (Confidentiality). > > > > > > > > * Misuse of the OpenSSL library that allows bypassing > certificate > > > > - checks. > > > > + checks (Integrity). > > > > > > > > * A bug (memory corruption, overflow, ...) that allows one to > > > >modify the behaviour of OVS through external configuration > > > > - interfaces such as OVSDB. > > > > + interfaces such as OVSDB (Integrity). > > > > > > > > -* Privileged information is exposed to unprivileged users. > > > > +* Privileged information is exposed to unprivileged users > > > > + (Confidentiality). > > > > > > > > If in doubt, please do use the vulnerability management process. At > > > > worst, the response will be to report the bug through the usual > > > > @@ -53,8 +61,17 @@ Step 1: Reception > > > > > > > > To report an Open vSwitch vulnerability, send an email to the > > > > ovs-security mailing list (see "Contact" at the end of this > document). > > > > -A security team member should reply to the reporter acknowledging > that > > > > -the report has been received. > > > > +A security team member should reply to the reporter within 24 hours > > > > +acknowledging that the report has been received. > > > > > > There is no on-call team as far as know. Perhaps Ben can confirm that. > > > So issues reported during holidays or weekends may take more than > > > 24 hours to get a reply. My concern here is that it will create a non > > > practical expectation. > > > > > > Perhaps something like this: > > > A security team member should reply to the reporter within 24 hours > > > on business days acknowledging that the report has been received. > > > > > > > +Reporters may ask for a GPG key while initiating contact with the > > > > +security team to deliver more sensitive reports. > > > > +If the reporter has used GPG while disclosing, further vulnerability > > > > +details should also be discussed using GPG. > > > > + > > > > +Please don't report security vulnerabilities to the ovs-dev list, > > > > +ovs-bug list or github issues to allow the team ovs security team > > > > +to responsibly fix the vulnerability. > > > > > > It looks more clear/effective to me if we swap the two > > > paragraphs. I mean, first tell to not report on ovs-dev and > > > then talk about GPG details... > > > > > > fbl > > > > > > > Please consider reporting the information mentioned in > > > > REPORTING-BUGS.md, where relevant. > > > > @@ -132,11 +149,11 @@ vSwitch user who is interested and can be > > > considered trustworthy > > > > enough could be included. To become a downstream stakeholder, email > > > > the ovs-security mailing list. > > > > > > > > -If the vulnerability is public, skip this step. > > > > +If the vulnerability is already public, skip this step. > > > > > > > > > > > > -Step 5: Full Disc
Re: [ovs-dev] [PATCH] Update SECURITY.md
Thanks. Some background: I don't want to say "there will be a response within 24 hours" because I do like to take off weekends, and because I might easily judge something as not important even though it was sent to the security list. But I also don't want to say "there will be a response within 72 hours" because that makes it sound like we're a bunch of lazy so-and-sos, which we're not. That's why I left it so vague originally. There's also likely to be an extra delay if anyone sends me encrypted email, because my private key is only on one computer that I usually leave at home. On Thu, Jan 08, 2015 at 09:17:30PM +, Andrew Kampjes wrote: > I change back to a more general statement, given that we can't really > guarantee a response time. > > On Fri Jan 09 2015 at 09:54:03 Ben Pfaff wrote: > > > I don't know what to say for response time. In general I expect it to > > be pretty fast for anything that is clearly urgent. > > > > On Fri, Jan 09, 2015 at 09:48:11AM +1300, Andrew Kampjes wrote: > > > Both good points, thanks Flavio. > > > Ben, can you confirm what the expectation for response should be? > > > > > > Will swap those paragraphs too. > > > > > > On 9 January 2015 at 05:11, Flavio Leitner wrote: > > > > > > > On Thursday, January 08, 2015 11:14:40 AM Andrew Kampjes wrote: > > > > > Include more specific GPG recomendation usage. > > > > > Add generalised rules for vulnerabilties. > > > > > > > > > > Signed-off-by: Andrew Kampjes > > > > > --- > > > > > SECURITY.md | 41 + > > > > > 1 file changed, 29 insertions(+), 12 deletions(-) > > > > > > > > > > diff --git a/SECURITY.md b/SECURITY.md > > > > > index d558d44..c85e594 100644 > > > > > --- a/SECURITY.md > > > > > +++ b/SECURITY.md > > > > > @@ -23,25 +23,33 @@ What is a vulnerability? > > > > > > > > > > > > > > > All vulnerabilities are bugs, but not every bug is a vulnerability. > > > > > +Vulnerabilites compromise one or more of: > > > > > + > > > > > +* Confidentiality (Personal and company data/secrets). > > > > > +* Integrity (trustworthyness and correctness). > > > > > +* Availability (Uptime and service). > > > > > + > > > > > Here are some examples of vulnerabilities to which one would expect > > to > > > > > apply this process: > > > > > > > > > > -* A crafted packet that causes a kernel or userspace crash. > > > > > +* A crafted packet that causes a kernel or userspace crash > > > > > + (Availability). > > > > > > > > > > * A flow translation bug that misforwards traffic in a way > > likely > > > > > - to hop over security boundaries. > > > > > + to hop over security boundaries (Integrity). > > > > > > > > > > * An OpenFlow protocol bug that allows a controller to read > > > > > - arbitrary files from the file system. > > > > > + arbitrary files from the file system (Confidentiality). > > > > > > > > > > * Misuse of the OpenSSL library that allows bypassing > > certificate > > > > > - checks. > > > > > + checks (Integrity). > > > > > > > > > > * A bug (memory corruption, overflow, ...) that allows one to > > > > >modify the behaviour of OVS through external configuration > > > > > - interfaces such as OVSDB. > > > > > + interfaces such as OVSDB (Integrity). > > > > > > > > > > -* Privileged information is exposed to unprivileged users. > > > > > +* Privileged information is exposed to unprivileged users > > > > > + (Confidentiality). > > > > > > > > > > If in doubt, please do use the vulnerability management process. At > > > > > worst, the response will be to report the bug through the usual > > > > > @@ -53,8 +61,17 @@ Step 1: Reception > > > > > > > > > > To report an Open vSwitch vulnerability, send an email to the > > > > > ovs-security mailing list (see "Contact" at the end of this > > document). > > > > > -A security team member should reply to the reporter acknowledging > > that > > > > > -the report has been received. > > > > > +A security team member should reply to the reporter within 24 hours > > > > > +acknowledging that the report has been received. > > > > > > > > There is no on-call team as far as know. Perhaps Ben can confirm that. > > > > So issues reported during holidays or weekends may take more than > > > > 24 hours to get a reply. My concern here is that it will create a non > > > > practical expectation. > > > > > > > > Perhaps something like this: > > > > A security team member should reply to the reporter within 24 hours > > > > on business days acknowledging that the report has been received. > > > > > > > > > +Reporters may ask for a GPG key while initiating contact with the > > > > > +security team to deliver more sensitive reports. > > > > > +If the reporter has used GPG while disclosing, further vulnerability > > > > > +details should also be discussed using GPG. > > > > > + > > > > > +Please don't report security
Re: [ovs-dev] [PATCH] Update SECURITY.md
Of course, we all like to have a life :) On Fri Jan 09 2015 at 10:18:52 Ben Pfaff wrote: > Thanks. > > Some background: > > I don't want to say "there will be a response within 24 hours" because > I do like to take off weekends, and because I might easily judge > something as not important even though it was sent to the security > list. But I also don't want to say "there will be a response within > 72 hours" because that makes it sound like we're a bunch of lazy > so-and-sos, which we're not. That's why I left it so vague > originally. > > There's also likely to be an extra delay if anyone sends me encrypted > email, because my private key is only on one computer that I usually > leave at home. > > On Thu, Jan 08, 2015 at 09:17:30PM +, Andrew Kampjes wrote: > > I change back to a more general statement, given that we can't really > > guarantee a response time. > > > > On Fri Jan 09 2015 at 09:54:03 Ben Pfaff wrote: > > > > > I don't know what to say for response time. In general I expect it to > > > be pretty fast for anything that is clearly urgent. > > > > > > On Fri, Jan 09, 2015 at 09:48:11AM +1300, Andrew Kampjes wrote: > > > > Both good points, thanks Flavio. > > > > Ben, can you confirm what the expectation for response should be? > > > > > > > > Will swap those paragraphs too. > > > > > > > > On 9 January 2015 at 05:11, Flavio Leitner wrote: > > > > > > > > > On Thursday, January 08, 2015 11:14:40 AM Andrew Kampjes wrote: > > > > > > Include more specific GPG recomendation usage. > > > > > > Add generalised rules for vulnerabilties. > > > > > > > > > > > > Signed-off-by: Andrew Kampjes > > > > > > --- > > > > > > SECURITY.md | 41 + > > > > > > 1 file changed, 29 insertions(+), 12 deletions(-) > > > > > > > > > > > > diff --git a/SECURITY.md b/SECURITY.md > > > > > > index d558d44..c85e594 100644 > > > > > > --- a/SECURITY.md > > > > > > +++ b/SECURITY.md > > > > > > @@ -23,25 +23,33 @@ What is a vulnerability? > > > > > > > > > > > > > > > > > > All vulnerabilities are bugs, but not every bug is a > vulnerability. > > > > > > +Vulnerabilites compromise one or more of: > > > > > > + > > > > > > +* Confidentiality (Personal and company data/secrets). > > > > > > +* Integrity (trustworthyness and correctness). > > > > > > +* Availability (Uptime and service). > > > > > > + > > > > > > Here are some examples of vulnerabilities to which one would > expect > > > to > > > > > > apply this process: > > > > > > > > > > > > -* A crafted packet that causes a kernel or userspace crash. > > > > > > +* A crafted packet that causes a kernel or userspace crash > > > > > > + (Availability). > > > > > > > > > > > > * A flow translation bug that misforwards traffic in a way > > > likely > > > > > > - to hop over security boundaries. > > > > > > + to hop over security boundaries (Integrity). > > > > > > > > > > > > * An OpenFlow protocol bug that allows a controller to read > > > > > > - arbitrary files from the file system. > > > > > > + arbitrary files from the file system (Confidentiality). > > > > > > > > > > > > * Misuse of the OpenSSL library that allows bypassing > > > certificate > > > > > > - checks. > > > > > > + checks (Integrity). > > > > > > > > > > > > * A bug (memory corruption, overflow, ...) that allows one > to > > > > > >modify the behaviour of OVS through external configuration > > > > > > - interfaces such as OVSDB. > > > > > > + interfaces such as OVSDB (Integrity). > > > > > > > > > > > > -* Privileged information is exposed to unprivileged users. > > > > > > +* Privileged information is exposed to unprivileged users > > > > > > + (Confidentiality). > > > > > > > > > > > > If in doubt, please do use the vulnerability management > process. At > > > > > > worst, the response will be to report the bug through the usual > > > > > > @@ -53,8 +61,17 @@ Step 1: Reception > > > > > > > > > > > > To report an Open vSwitch vulnerability, send an email to the > > > > > > ovs-security mailing list (see "Contact" at the end of this > > > document). > > > > > > -A security team member should reply to the reporter > acknowledging > > > that > > > > > > -the report has been received. > > > > > > +A security team member should reply to the reporter within 24 > hours > > > > > > +acknowledging that the report has been received. > > > > > > > > > > There is no on-call team as far as know. Perhaps Ben can confirm > that. > > > > > So issues reported during holidays or weekends may take more than > > > > > 24 hours to get a reply. My concern here is that it will create a > non > > > > > practical expectation. > > > > > > > > > > Perhaps something like this: > > > > > A security team member should reply to the reporter within 24 hours > > > > > on business days acknowledging that the report has been received. > > > > > > >
[ovs-dev] [PATCH 0/5 V6] Add 802.1ad (qinq) support
This patch adds support for 802.1ad. The second part of the series includes user space changes and a test. Version 6 splits the changes into separate patches to make it easier on the eyes of reviewers but otherwise is functionally the same as version 5. Version 6 includes only the user space patch. The Linux kernel datapath patch will be rebased to net-next and and submitted to netdev separately. Version 6 also fixes some white space problems and renames the included test. Version 5 updated the patch to properly use nested attributes, fixed some whitespace problems and allows TPID 0x88a8 tag be pushed with either single or outer tag because Open Flow does not specifically prohibit it. This effort is supported by Entry Point LLC. as part of the Virtual Broadband Gateway project. This patch been tested in VMs as well as real-world environment at ATC Communications Inc. This patch has been tested along with the Linux Kernel datapath patch in a VM based test network as well as real-world provider test environment. Thanks to Robert Peterson for inspiring and leading the effort of separating customer from provider traffic which led to this work and thanks to the people at ATC for helping with configuring the test lab including the Cisco and Brocade equipment. Thanks to Ben Pfaff and others that have commented on previous versions of this patch and thanks to Dave Benson who contributed the test included in this patch. We would be interested in any feedback and results from any other testers. Thomas F Herbert (5): Add support for 802.1AD (qinq) Flow changes for 802.1ad Vlan parsing: 802.1AD and encapsulated Vlan Actions changes 802.1ad Customer TCI Add test for 802.1AD including 0x88a8 TPID NEWS | 2 + lib/flow.c | 22 +++-- lib/flow.h | 15 ++- lib/match.c | 2 +- lib/nx-match.c | 2 +- lib/odp-execute.c| 2 +- lib/odp-util.c | 217 +-- lib/odp-util.h | 2 +- lib/ofp-actions.c| 32 --- lib/ofp-actions.h| 9 +- lib/ofp-util.c | 2 +- lib/packets.c| 2 +- lib/packets.h| 7 ++ ofproto/ofproto-dpif-xlate.c | 13 ++- tests/ofproto-dpif.at| 40 utilities/ovs-ofctl.8.in | 3 +- 16 files changed, 309 insertions(+), 63 deletions(-) -- 1.8.3.2 ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
[ovs-dev] [PATCH 1/5 V6] Add support for 802.1AD (qinq)
Signed-off-by: Thomas F Herbert --- NEWS | 2 ++ utilities/ovs-ofctl.8.in | 3 +-- 2 files changed, 3 insertions(+), 2 deletions(-) diff --git a/NEWS b/NEWS index 8fcc14b..58ef3d8 100644 --- a/NEWS +++ b/NEWS @@ -1,5 +1,7 @@ Post-v2.3.0 - + - Add support for 8021.AD as specified in OpenFlow 1.1+. Adds push and pop + of 802.1AD Ethertype and handling of QinQ or double stacked Vlans. - Add bash command-line completion support for ovs-appctl/ovs-dpctl/ ovs-ofctl/ovsdb-tool commands. Please check utilities/ovs-command-compgen.INSTALL.md for how to use. diff --git a/utilities/ovs-ofctl.8.in b/utilities/ovs-ofctl.8.in index 7ffbeaa..ea8ae2e 100644 --- a/utilities/ovs-ofctl.8.in +++ b/utilities/ovs-ofctl.8.in @@ -1276,8 +1276,7 @@ Strips the VLAN tag from a packet if it is present. . .IP \fBpush_vlan\fR:\fIethertype\fR Push a new VLAN tag onto the packet. Ethertype is used as the the Ethertype -for the tag. Only ethertype 0x8100 should be used. (0x88a8 which the spec -allows isn't supported at the moment.) +for the tag. Either Ethertypes 0x8100, or 0x88a8 may be used. A priority of zero and the tag of zero are used for the new tag. . .IP \fBpush_mpls\fR:\fIethertype\fR -- 1.8.3.2 ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
[ovs-dev] [PATCH 2/5 V6] Flow changes for 802.1ad
This patch adds support for 802.1ad by adding customer tci and tpid to the
flow structure.
Signed-off-by: Thomas F Herbert
---
lib/flow.c | 22 +-
lib/flow.h | 15 ++-
lib/match.c| 2 +-
lib/nx-match.c | 2 +-
lib/odp-util.h | 2 +-
lib/ofp-util.c | 2 +-
6 files changed, 27 insertions(+), 18 deletions(-)
diff --git a/lib/flow.c b/lib/flow.c
index d8a7981..af0cfc8 100644
--- a/lib/flow.c
+++ b/lib/flow.c
@@ -119,7 +119,7 @@ struct mf_ctx {
* away. Some GCC versions gave warnings on ALWAYS_INLINE, so these are
* defined as macros. */
-#if (FLOW_WC_SEQ != 29)
+#if (FLOW_WC_SEQ != 30)
#define MINIFLOW_ASSERT(X) ovs_assert(X)
BUILD_MESSAGE("FLOW_WC_SEQ changed: miniflow_extract() will have runtime "
"assertions enabled. Consider updating FLOW_WC_SEQ after "
@@ -287,7 +287,7 @@ parse_vlan(void **datap, size_t *sizep)
data_pull(datap, sizep, ETH_ADDR_LEN * 2);
-if (eth->eth_type == htons(ETH_TYPE_VLAN)) {
+if (eth_type_vlan(eth->eth_type)) {
if (OVS_LIKELY(*sizep
>= sizeof(struct qtag_prefix) + sizeof(ovs_be16))) {
const struct qtag_prefix *qp = data_pull(datap, sizep, sizeof *qp);
@@ -762,7 +762,7 @@ flow_unwildcard_tp_ports(const struct flow *flow, struct
flow_wildcards *wc)
void
flow_get_metadata(const struct flow *flow, struct flow_metadata *fmd)
{
-BUILD_ASSERT_DECL(FLOW_WC_SEQ == 29);
+BUILD_ASSERT_DECL(FLOW_WC_SEQ == 30);
fmd->dp_hash = flow->dp_hash;
fmd->recirc_id = flow->recirc_id;
@@ -909,7 +909,7 @@ void flow_wildcards_init_for_packet(struct flow_wildcards
*wc,
memset(&wc->masks, 0x0, sizeof wc->masks);
/* Update this function whenever struct flow changes. */
-BUILD_ASSERT_DECL(FLOW_WC_SEQ == 29);
+BUILD_ASSERT_DECL(FLOW_WC_SEQ == 30);
if (flow->tunnel.ip_dst) {
if (flow->tunnel.flags & FLOW_TNL_F_KEY) {
@@ -1006,7 +1006,7 @@ uint64_t
flow_wc_map(const struct flow *flow)
{
/* Update this function whenever struct flow changes. */
-BUILD_ASSERT_DECL(FLOW_WC_SEQ == 29);
+BUILD_ASSERT_DECL(FLOW_WC_SEQ == 30);
uint64_t map = (flow->tunnel.ip_dst) ? MINIFLOW_MAP(tunnel) : 0;
@@ -1058,7 +1058,7 @@ void
flow_wildcards_clear_non_packet_fields(struct flow_wildcards *wc)
{
/* Update this function whenever struct flow changes. */
-BUILD_ASSERT_DECL(FLOW_WC_SEQ == 29);
+BUILD_ASSERT_DECL(FLOW_WC_SEQ == 30);
memset(&wc->masks.metadata, 0, sizeof wc->masks.metadata);
memset(&wc->masks.regs, 0, sizeof wc->masks.regs);
@@ -1616,7 +1616,7 @@ flow_push_mpls(struct flow *flow, int n, ovs_be16
mpls_eth_type,
flow->mpls_lse[0] = set_mpls_lse_values(ttl, tc, 1, htonl(label));
/* Clear all L3 and L4 fields and dp_hash. */
-BUILD_ASSERT(FLOW_WC_SEQ == 29);
+BUILD_ASSERT(FLOW_WC_SEQ == 30);
memset((char *) flow + FLOW_SEGMENT_2_ENDS_AT, 0,
sizeof(struct flow) - FLOW_SEGMENT_2_ENDS_AT);
flow->dp_hash = 0;
@@ -1803,8 +1803,12 @@ flow_compose(struct ofpbuf *b, const struct flow *flow)
return;
}
-if (flow->vlan_tci & htons(VLAN_CFI)) {
-eth_push_vlan(b, htons(ETH_TYPE_VLAN), flow->vlan_tci);
+if (flow->vlan_tci & htons(VLAN_CFI) &&
+(flow->vlan_ctci & htons(VLAN_CFI))) {
+eth_push_vlan(b, htons(ETH_TYPE_VLAN_8021Q), flow->vlan_ctci);
+eth_push_vlan(b, htons(ETH_TYPE_VLAN_8021AD), flow->vlan_tci);
+} else if (flow->vlan_tci & htons(VLAN_CFI)) {
+eth_push_vlan(b, htons(ETH_TYPE_VLAN_8021Q), flow->vlan_tci);
}
if (flow->dl_type == htons(ETH_TYPE_IP)) {
diff --git a/lib/flow.h b/lib/flow.h
index 17b9b86..0335044 100644
--- a/lib/flow.h
+++ b/lib/flow.h
@@ -38,7 +38,7 @@ struct pkt_metadata;
/* This sequence number should be incremented whenever anything involving flows
* or the wildcarding of flows changes. This will cause build assertion
* failures in places which likely need to be updated. */
-#define FLOW_WC_SEQ 29
+#define FLOW_WC_SEQ 30
/* Number of Open vSwitch extension 32-bit registers. */
#define FLOW_N_REGS 8
@@ -112,7 +112,12 @@ struct flow {
uint8_t dl_dst[ETH_ADDR_LEN]; /* Ethernet destination address. */
uint8_t dl_src[ETH_ADDR_LEN]; /* Ethernet source address. */
ovs_be16 dl_type; /* Ethernet frame type. */
-ovs_be16 vlan_tci; /* If 802.1Q, TCI | VLAN_CFI; otherwise 0. */
+ovs_be16 vlan_tci; /* If 802.1Q, TCI | VLAN_CFI; If 802.1ad,
+ outer tag | VLAN_CFI */
+ovs_be16 vlan_ctci; /* If 802.1ad, This is Customer TCI | VLAN_CFI,
+ inner tag */
+ovs_be16 vlan_tpid; /* Vlan protocol type, either 802.1ad or
802.1q. */
+ovs_be32 pad2; /* Pad to 64 bits. */
ovs_be32 mpls_lse[ROUND_UP(FLOW_MAX_MPLS_LABELS, 2)]; /* MPLS label stack
[ovs-dev] [PATCH 3/5 V6] Vlan parsing: 802.1AD and encapsulated Vlan
This patch adds support for 802.1AD by adding parsing of 802.1AD double
stacked vlans.
Signed-off-by: Thomas F Herbert
---
lib/odp-execute.c | 2 +-
lib/odp-util.c| 217 +++---
2 files changed, 192 insertions(+), 27 deletions(-)
diff --git a/lib/odp-execute.c b/lib/odp-execute.c
index 9ff418d..79d39b1 100644
--- a/lib/odp-execute.c
+++ b/lib/odp-execute.c
@@ -478,7 +478,7 @@ odp_execute_actions(void *dp, struct dpif_packet **packets,
int cnt, bool steal,
for (i = 0; i < cnt; i++) {
struct ofpbuf *buf = &packets[i]->ofpbuf;
-eth_push_vlan(buf, htons(ETH_TYPE_VLAN), vlan->vlan_tci);
+eth_push_vlan(buf, vlan->vlan_tpid, vlan->vlan_tci);
}
break;
}
diff --git a/lib/odp-util.c b/lib/odp-util.c
index d52c172..06ddfaf 100644
--- a/lib/odp-util.c
+++ b/lib/odp-util.c
@@ -2861,7 +2861,7 @@ odp_flow_key_from_flow__(struct ofpbuf *buf, const struct
flow *flow,
size_t max_mpls_depth, bool recirc, bool export_mask)
{
struct ovs_key_ethernet *eth_key;
-size_t encap;
+size_t encap = 0;
const struct flow *data = export_mask ? mask : flow;
nl_msg_put_u32(buf, OVS_KEY_ATTR_PRIORITY, data->skb_priority);
@@ -2887,11 +2887,19 @@ odp_flow_key_from_flow__(struct ofpbuf *buf, const
struct flow *flow,
sizeof *eth_key);
get_ethernet_key(data, eth_key);
-if (flow->vlan_tci != htons(0) || flow->dl_type == htons(ETH_TYPE_VLAN)) {
-if (export_mask) {
-nl_msg_put_be16(buf, OVS_KEY_ATTR_ETHERTYPE, OVS_BE16_MAX);
+if (flow->vlan_tci != htons(0) || eth_type_vlan(flow->dl_type)) {
+if (flow->vlan_ctci != htons(0)) {
+if (export_mask) {
+nl_msg_put_be16(buf, OVS_KEY_ATTR_ETHERTYPE, OVS_BE16_MAX);
+} else {
+nl_msg_put_be16(buf, OVS_KEY_ATTR_ETHERTYPE,
htons(ETH_TYPE_VLAN_8021AD));
+}
} else {
-nl_msg_put_be16(buf, OVS_KEY_ATTR_ETHERTYPE, htons(ETH_TYPE_VLAN));
+if (export_mask) {
+nl_msg_put_be16(buf, OVS_KEY_ATTR_ETHERTYPE, OVS_BE16_MAX);
+} else {
+nl_msg_put_be16(buf, OVS_KEY_ATTR_ETHERTYPE,
htons(ETH_TYPE_VLAN_8021Q));
+}
}
nl_msg_put_be16(buf, OVS_KEY_ATTR_VLAN, data->vlan_tci);
encap = nl_msg_start_nested(buf, OVS_KEY_ATTR_ENCAP);
@@ -3624,6 +3632,81 @@ parse_8021q_onward(const struct nlattr
*attrs[OVS_KEY_ATTR_MAX + 1],
return MAX(fitness, encap_fitness);
}
+/* Parse 802.1ADQ header then parse encapsulated Customer Vlan. */
+static enum odp_key_fitness
+parse_8021ad_onward(const struct nlattr *attrs[OVS_KEY_ATTR_MAX + 1],
+uint64_t present_attrs, int out_of_range_attr,
+uint64_t expected_attrs, struct flow *flow,
+const struct nlattr *key, size_t key_len,
+const struct flow *src_flow)
+{
+static struct vlog_rate_limit rl = VLOG_RATE_LIMIT_INIT(1, 5);
+bool is_mask = src_flow != flow;
+
+const struct nlattr *encap
+= (present_attrs & (UINT64_C(1) << OVS_KEY_ATTR_ENCAP)
+ ? attrs[OVS_KEY_ATTR_ENCAP] : NULL);
+enum odp_key_fitness encap_fitness;
+enum odp_key_fitness fitness;
+
+/* Calculate fitness of outer attributes. */
+if (!is_mask) {
+expected_attrs |= ((UINT64_C(1) << OVS_KEY_ATTR_VLAN) |
+ (UINT64_C(1) << OVS_KEY_ATTR_ENCAP));
+} else {
+if (present_attrs & (UINT64_C(1) << OVS_KEY_ATTR_VLAN)) {
+expected_attrs |= (UINT64_C(1) << OVS_KEY_ATTR_VLAN);
+}
+if (present_attrs & (UINT64_C(1) << OVS_KEY_ATTR_ENCAP)) {
+expected_attrs |= (UINT64_C(1) << OVS_KEY_ATTR_ENCAP);
+}
+}
+fitness = check_expectations(present_attrs, out_of_range_attr,
+ expected_attrs, key, key_len);
+
+/* Set outertag, vlan_tci.
+ * Remove the TPID from dl_type since it's not the real Ethertype. */
+flow->dl_type = htons(0);
+flow->vlan_tci = (present_attrs & (UINT64_C(1) << OVS_KEY_ATTR_VLAN)
+ ? nl_attr_get_be16(attrs[OVS_KEY_ATTR_VLAN])
+ : htons(0));
+if (!is_mask) {
+if (!(present_attrs & (UINT64_C(1) << OVS_KEY_ATTR_VLAN))) {
+return ODP_FIT_TOO_LITTLE;
+} else if (flow->vlan_tci == htons(0)) {
+/* Corner case for a truncated 802.1Q header. */
+if (fitness == ODP_FIT_PERFECT && nl_attr_get_size(encap)) {
+return ODP_FIT_TOO_MUCH;
+}
+return fitness;
+} else if (!(flow->vlan_tci & htons(VLAN_CFI))) {
+VLOG_ERR_RL(&rl, "Outer OVS_KEY_ATTR_VLAN 0x%04"PRIx16" is nonzero
"
+"but CFI bit is not set", ntohs(flow->vlan_tci));
+
[ovs-dev] [PATCH 5/5 V6] Add test for 802.1AD including 0x88a8 TPID
This adds a test of OF support of pushing and popping VLANS with 0x88a8 Ethertype. This is based on Dave Benson's contribution of the 802.1AD Ethertype test. Signed-off-by: Thomas F Herbert --- tests/ofproto-dpif.at | 40 1 file changed, 40 insertions(+) diff --git a/tests/ofproto-dpif.at b/tests/ofproto-dpif.at index 22050f3..fd2f4ae 100644 --- a/tests/ofproto-dpif.at +++ b/tests/ofproto-dpif.at @@ -1475,6 +1475,46 @@ NXST_FLOW reply: OVS_VSWITCHD_STOP AT_CLEANUP +AT_SETUP([ofproto-dpif - Push and pop VLANS with 802.1AD TPID]) +OVS_VSWITCHD_START +ADD_OF_PORTS([br0], [1], [2], [3], [4]) + +AT_DATA([flows1.txt], [dnl +table=0 in_port=1 dl_type=0x8100 actions=pop_vlan,output:2 +table=0 in_port=1 dl_type=0x88a8 actions=pop_vlan,output:3 +]) +AT_CHECK([ovs-ofctl add-flows br0 flows1.txt]) +AT_DATA([flows2.txt], [dnl +table=0 in_port=2 dl_type=0x0800 actions=push_vlan:0x8100,mod_vlan_vid:9,output:1 +table=0 in_port=3 dl_type=0x0800 actions=push_vlan:0x88a8,set_field:0x1006->vlan_tci,output:1 +table=0 in_port=4 dl_type=0x0800 actions=push_vlan:0x88a8,mod_vlan_vid:11,output:1 +]) +AT_CHECK([ovs-ofctl -O OpenFlow11 add-flows br0 flows2.txt]) + +AT_CHECK([ovs-appctl ofproto/trace br0 'in_port=1,dl_dst=ff:ff:ff:ff:ff:ff,dl_type=0x8100,dl_vlan=9'], [0], [stdout]) +AT_CHECK([tail -1 stdout], [0], + [Datapath actions: pop_vlan,2 +]) +AT_CHECK([ovs-appctl ofproto/trace br0 'in_port=1,dl_dst=ff:ff:ff:ff:ff:ff,dl_type=0x88a8,dl_vlan=9'], [0], [stdout]) +AT_CHECK([tail -1 stdout], [0], + [Datapath actions: pop_vlan,3 +]) +AT_CHECK([ovs-appctl ofproto/trace br0 'in_port=2,dl_dst=ff:ff:ff:ff:ff:ff,dl_type=0x0800'], [0], [stdout]) +AT_CHECK([tail -1 stdout], [0], + [Datapath actions: push_vlan(vid=9,pcp=0),1 +]) +AT_CHECK([ovs-appctl ofproto/trace br0 'in_port=3,dl_dst=ff:ff:ff:ff:ff:ff,dl_type=0x0800'], [0], [stdout]) +AT_CHECK([tail -1 stdout], [0], + [Datapath actions: push_vlan(tpid=0x88a8,vid=6,pcp=0),1 +]) +AT_CHECK([ovs-appctl ofproto/trace br0 'in_port=4,dl_dst=ff:ff:ff:ff:ff:ff,dl_type=0x0800'], [0], [stdout]) +AT_CHECK([tail -1 stdout], [0], + [Datapath actions: push_vlan(tpid=0x88a8,vid=11,pcp=0),1 +]) + +OVS_VSWITCHD_STOP +AT_CLEANUP + AT_SETUP([ofproto-dpif - MPLS handling]) OVS_VSWITCHD_START([dnl add-port br0 p1 -- set Interface p1 type=dummy -- 1.8.3.2 ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
[ovs-dev] [PATCH 4/5 V6] Actions changes 802.1ad Customer TCI
This patch changes the actions processing to support popping and pushing of
double stacked vlans (qinq.)
Signed-off-by: Thomas F Herbert
---
lib/ofp-actions.c| 32 +++-
lib/ofp-actions.h| 9 -
lib/packets.c| 2 +-
lib/packets.h| 7 +++
ofproto/ofproto-dpif-xlate.c | 13 -
5 files changed, 47 insertions(+), 16 deletions(-)
diff --git a/lib/ofp-actions.c b/lib/ofp-actions.c
index 4680d81..7414a78 100644
--- a/lib/ofp-actions.c
+++ b/lib/ofp-actions.c
@@ -1266,16 +1266,20 @@ format_STRIP_VLAN(const struct ofpact_null *a, struct
ds *s)
static enum ofperr
decode_OFPAT_RAW11_PUSH_VLAN(ovs_be16 eth_type, struct ofpbuf *out)
{
-if (eth_type != htons(ETH_TYPE_VLAN_8021Q)) {
-/* XXX 802.1AD(QinQ) isn't supported at the moment */
+struct ofpact_push_vlan *oam;
+
+if (!eth_type_vlan(eth_type)) {
+/* XXX Only 802.1q and 802.1AD(QinQ) is supported. */
return OFPERR_OFPBAC_BAD_ARGUMENT;
}
-ofpact_put_PUSH_VLAN(out);
+oam = ofpact_put_PUSH_VLAN(out);
+oam->ethertype = eth_type;
+
return 0;
}
static void
-encode_PUSH_VLAN(const struct ofpact_null *null OVS_UNUSED,
+encode_PUSH_VLAN(const struct ofpact_push_vlan *push_vlan,
enum ofp_version ofp_version, struct ofpbuf *out)
{
if (ofp_version == OFP10_VERSION) {
@@ -1283,7 +1287,7 @@ encode_PUSH_VLAN(const struct ofpact_null *null
OVS_UNUSED,
* follow this action. */
} else {
/* XXX ETH_TYPE_VLAN_8021AD case */
-put_OFPAT11_PUSH_VLAN(out, htons(ETH_TYPE_VLAN_8021Q));
+put_OFPAT11_PUSH_VLAN(out, push_vlan->ethertype);
}
}
@@ -1295,25 +1299,25 @@ parse_PUSH_VLAN(char *arg, struct ofpbuf *ofpacts,
char *error;
*usable_protocols &= OFPUTIL_P_OF11_UP;
-error = str_to_u16(arg, "ethertype", ðertype);
+error = str_to_u16(arg, "push_vlan", ðertype);
if (error) {
return error;
}
-if (ethertype != ETH_TYPE_VLAN_8021Q) {
-/* XXX ETH_TYPE_VLAN_8021AD case isn't supported */
+if (!eth_type_vlan(htons(ethertype))) {
+/* Check for valid VLAN ethertypes */
return xasprintf("%s: not a valid VLAN ethertype", arg);
}
-ofpact_put_PUSH_VLAN(ofpacts);
+ofpact_put_PUSH_VLAN(ofpacts)->ethertype = htons(ethertype);
return NULL;
}
static void
-format_PUSH_VLAN(const struct ofpact_null *a OVS_UNUSED, struct ds *s)
+format_PUSH_VLAN(const struct ofpact_push_vlan *a OVS_UNUSED, struct ds *s)
{
/* XXX 802.1AD case*/
-ds_put_format(s, "push_vlan:%#"PRIx16, ETH_TYPE_VLAN_8021Q);
+ds_put_format(s, "push_vlan:%#"PRIx16, ntohs(a->ethertype));
}
/* Action structure for OFPAT10_SET_DL_SRC/DST and OFPAT11_SET_DL_SRC/DST. */
@@ -5357,8 +5361,9 @@ ofpact_check__(enum ofputil_protocol *usable_protocols,
struct ofpact *a,
return 0;
case OFPACT_PUSH_VLAN:
-if (flow->vlan_tci & htons(VLAN_CFI)) {
-/* Multiple VLAN headers not supported. */
+if (flow->vlan_tci & htons(VLAN_CFI) &&
+flow->vlan_ctci & htons(VLAN_CFI)) {
+/* More then 2 levels of VLAN headers not supported. */
return OFPERR_OFPBAC_BAD_TAG;
}
/* Temporary mark that we have a vlan tag. */
@@ -5971,6 +5976,7 @@ ofpacts_get_meter(const struct ofpact ofpacts[], size_t
ofpacts_len)
/* Formatting ofpacts. */
+
static void
ofpact_format(const struct ofpact *a, struct ds *s)
{
diff --git a/lib/ofp-actions.h b/lib/ofp-actions.h
index 8362aa8..6c55356 100644
--- a/lib/ofp-actions.h
+++ b/lib/ofp-actions.h
@@ -66,7 +66,7 @@
OFPACT(SET_VLAN_VID,ofpact_vlan_vid,ofpact, "set_vlan_vid") \
OFPACT(SET_VLAN_PCP,ofpact_vlan_pcp,ofpact, "set_vlan_pcp") \
OFPACT(STRIP_VLAN, ofpact_null,ofpact, "strip_vlan") \
-OFPACT(PUSH_VLAN, ofpact_null,ofpact, "push_vlan")\
+OFPACT(PUSH_VLAN, ofpact_push_vlan, ofpact, "push_vlan")\
OFPACT(SET_ETH_SRC, ofpact_mac, ofpact, "mod_dl_src") \
OFPACT(SET_ETH_DST, ofpact_mac, ofpact, "mod_dl_dst") \
OFPACT(SET_IPV4_SRC,ofpact_ipv4,ofpact, "mod_nw_src") \
@@ -401,6 +401,13 @@ struct ofpact_push_mpls {
ovs_be16 ethertype;
};
+/* OFPACT_PUSH_VLAN
+ *
+ * Used for OFPAT11_PUSH_VLAN. */
+struct ofpact_push_vlan {
+struct ofpact ofpact;
+ovs_be16 ethertype;
+};
/* OFPACT_POP_MPLS
*
* Used for NXAST_POP_MPLS, OFPAT11_POP_MPLS.. */
diff --git a/lib/packets.c b/lib/packets.c
index af99e3b..f5b4526 100644
--- a/lib/packets.c
+++ b/lib/packets.c
@@ -217,7 +217,7 @@ set_ethertype(struct ofpbuf *packet, ovs_be16 eth_type)
return;
}
-if (eh->eth_type == htons(ETH_TYPE_VLAN)) {
+if (eth_type_vlan(eh->eth_type)) {
ovs_be16 *p;
char *l2_5 = ofpbuf_l2_5(packet);
diff --git a/lib/packets.h b/
[ovs-dev] [PATCHv2] Update SECURITY.md
Include more specific GPG recomendation usage. Add generalised rules for vulnerabilties. Signed-off-by: Andrew Kampjes --- SECURITY.md | 37 +++-- 1 file changed, 27 insertions(+), 10 deletions(-) diff --git a/SECURITY.md b/SECURITY.md index d558d44..c74bc04 100644 --- a/SECURITY.md +++ b/SECURITY.md @@ -23,25 +23,33 @@ What is a vulnerability? All vulnerabilities are bugs, but not every bug is a vulnerability. +Vulnerabilites compromise one or more of: + +* Confidentiality (Personal and company data/secrets). +* Integrity (trustworthyness and correctness). +* Availability (Uptime and service). + Here are some examples of vulnerabilities to which one would expect to apply this process: -* A crafted packet that causes a kernel or userspace crash. +* A crafted packet that causes a kernel or userspace crash + (Availability). * A flow translation bug that misforwards traffic in a way likely - to hop over security boundaries. + to hop over security boundaries (Integrity). * An OpenFlow protocol bug that allows a controller to read - arbitrary files from the file system. + arbitrary files from the file system (Confidentiality). * Misuse of the OpenSSL library that allows bypassing certificate - checks. + checks (Integrity). * A bug (memory corruption, overflow, ...) that allows one to modify the behaviour of OVS through external configuration - interfaces such as OVSDB. + interfaces such as OVSDB (Integrity). -* Privileged information is exposed to unprivileged users. +* Privileged information is exposed to unprivileged users + (Confidentiality). If in doubt, please do use the vulnerability management process. At worst, the response will be to report the bug through the usual @@ -56,9 +64,18 @@ ovs-security mailing list (see "Contact" at the end of this document). A security team member should reply to the reporter acknowledging that the report has been received. +Please don't report security vulnerabilities to the ovs-dev list, +ovs-bug list or github issues to allow the OVS security team to +responsibly fix the vulnerability. + Please consider reporting the information mentioned in REPORTING-BUGS.md, where relevant. +Reporters may ask for a GPG key while initiating contact with the +security team to deliver more sensitive reports. +If the reporter has used GPG while disclosing, further vulnerability +details should also be discussed using GPG. + The Linux kernel has its own vulnerability management process: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/SecurityBugs Handling of vulnerabilities that affect both the Open vSwitch tree and @@ -132,11 +149,11 @@ vSwitch user who is interested and can be considered trustworthy enough could be included. To become a downstream stakeholder, email the ovs-security mailing list. -If the vulnerability is public, skip this step. +If the vulnerability is already public, skip this step. -Step 5: Full Disclosure +Step 5: Public Disclosure +- When the embargo expires, push the (reviewed) patches to appropriate branches, post the patches to the ovs-dev mailing list (noting that @@ -151,7 +168,7 @@ The security advisory should be GPG-signed by a security team member with a key that is in a public web of trust. -Contact +Contact === Report security vulnerabilities to the ovs-security mailing list: -- 1.9.1 ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
[ovs-dev] [PATCH] vagrant: switch to use out of tree build
Vagrant shared folder, at least on the default virtual box, does not support the creation of the socket files. If one were to build OVS under /vagrant, 'make check' would not work. Out of tree builds can be used to work around this issue. See Install.md for instructions. Since out of tree builds requires a clean source tree, Vagrantfile can not be a generated file. This commit removes Vagrantfile.in, commit Vagrantfile instead. Signed-off-by: Andy Zhou --- .gitignore | 1 - INSTALL.md | 21 + Makefile.am| 2 +- Vagrantfile| 49 + Vagrantfile.in | 30 -- configure.ac | 1 - 6 files changed, 67 insertions(+), 37 deletions(-) create mode 100644 Vagrantfile delete mode 100644 Vagrantfile.in diff --git a/.gitignore b/.gitignore index a3522d8..e37a690 100644 --- a/.gitignore +++ b/.gitignore @@ -65,5 +65,4 @@ tags _debian odp-netlink.h OvsDpInterface.h -Vagrantfile /.vagrant/ diff --git a/INSTALL.md b/INSTALL.md index 8fae214..94c25f7 100644 --- a/INSTALL.md +++ b/INSTALL.md @@ -579,7 +579,7 @@ report, plus any other information needed to reproduce the problem. Vagrant --- -Requires: Vagrant and a compatible hypervisor +Requires: Vagrant (version 1.7.0 or later) and a compatible hypervisor You must bootstrap and configure the sources (steps are in "Building and Installing Open vSwitch for Linux, FreeBSD or NetBSD" above) before @@ -592,12 +592,25 @@ tree as found locally in a virtual machine using the following commands: vagrant ssh This will bring up w Fedora 20 VM by default, alternatively the -`Vagrantfile.in` can be modified to use a different distribution box as -base. Also, the VM can be reprovisioned at any time to recompile and -reinstall OVS: +`Vagrantfile` can be modified to use a different distribution box as +base. Also, the VM can be reprovisioned at any time: vagrant provision +OVS out-of-tree compilation environment can be set up with: + + ./boot.sh + vagrant provision --provision-with configure_ovs,build_ovs + +This will set up an out-of-tree build environment in /home/vagrant/build. +The source code can be found in /vagrant. Out-of-tree build is preferred +to work around limitations of the sync file systems. + +To recompile and reinstall OVS using RPM: + + ./boot.sh + vagrant provision --provision-with configure_ovs,install_rpm + Continuous Integration with Travis-CI - diff --git a/Makefile.am b/Makefile.am index 6ad6fc2..b3ff4e3 100644 --- a/Makefile.am +++ b/Makefile.am @@ -105,7 +105,7 @@ EXTRA_DIST = \ build-aux/soexpand.pl \ $(MAN_FRAGMENTS) \ $(MAN_ROOTS) \ - Vagrantfile.in + Vagrantfile bin_PROGRAMS = sbin_PROGRAMS = bin_SCRIPTS = diff --git a/Vagrantfile b/Vagrantfile new file mode 100644 index 000..982eb01 --- /dev/null +++ b/Vagrantfile @@ -0,0 +1,49 @@ +# -*- mode: ruby -*- +# vi: set ft=ruby : + +# Vagrantfile API/syntax version. Don't touch unless you know what you're doing! +VAGRANTFILE_API_VERSION = "2" + +$bootstrap_fedora = <
Re: [ovs-dev] [PATCH] vagrant: switch to use out of tree build
On 01/08/15 at 03:00pm, Andy Zhou wrote: > Vagrant shared folder, at least on the default virtual box, does not > support the creation of the socket files. If one were to build OVS > under /vagrant, 'make check' would not work. > > Out of tree builds can be used to work around this issue. > See Install.md for instructions. > > Since out of tree builds requires a clean source tree, Vagrantfile can > not be a generated file. This commit removes Vagrantfile.in, commit > Vagrantfile instead. > > Signed-off-by: Andy Zhou Very nice Acked-by: Thomas Graf ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
[ovs-dev] [PATCH 3/6] vxlan: Only bind to sockets with correct extensions enabled
A VXLAN net_device looking for an appropriate socket may only consider
a socket which has a matching set of extensions enabled. If the
extensions don't match, return a conflict to have the caller create a
distinct socket with distinct port.
The OVS VXLAN port is kept unaware of extensions at this point.
Signed-off-by: Thomas Graf
---
v2:
- Improved commit message, reported by Jesse
drivers/net/vxlan.c | 35 +--
include/net/vxlan.h | 2 +-
net/openvswitch/vport-vxlan.c | 2 +-
3 files changed, 23 insertions(+), 16 deletions(-)
diff --git a/drivers/net/vxlan.c b/drivers/net/vxlan.c
index b148739..61e1112 100644
--- a/drivers/net/vxlan.c
+++ b/drivers/net/vxlan.c
@@ -271,14 +271,15 @@ static inline struct vxlan_rdst *first_remote_rtnl(struct
vxlan_fdb *fdb)
}
/* Find VXLAN socket based on network namespace, address family and UDP port */
-static struct vxlan_sock *vxlan_find_sock(struct net *net,
- sa_family_t family, __be16 port)
+static struct vxlan_sock *vxlan_find_sock(struct net *net, sa_family_t family,
+ __be16 port, u32 exts)
{
struct vxlan_sock *vs;
hlist_for_each_entry_rcu(vs, vs_head(net, port), hlist) {
if (inet_sk(vs->sock->sk)->inet_sport == port &&
- inet_sk(vs->sock->sk)->sk.sk_family == family)
+ inet_sk(vs->sock->sk)->sk.sk_family == family &&
+ vs->exts == exts)
return vs;
}
return NULL;
@@ -298,11 +299,12 @@ static struct vxlan_dev *vxlan_vs_find_vni(struct
vxlan_sock *vs, u32 id)
/* Look up VNI in a per net namespace table */
static struct vxlan_dev *vxlan_find_vni(struct net *net, u32 id,
- sa_family_t family, __be16 port)
+ sa_family_t family, __be16 port,
+ u32 exts)
{
struct vxlan_sock *vs;
- vs = vxlan_find_sock(net, family, port);
+ vs = vxlan_find_sock(net, family, port, exts);
if (!vs)
return NULL;
@@ -1776,7 +1778,8 @@ static void vxlan_xmit_one(struct sk_buff *skb, struct
net_device *dev,
ip_rt_put(rt);
dst_vxlan = vxlan_find_vni(vxlan->net, vni,
- dst->sa.sa_family, dst_port);
+ dst->sa.sa_family, dst_port,
+ vxlan->exts);
if (!dst_vxlan)
goto tx_error;
vxlan_encap_bypass(skb, vxlan, dst_vxlan);
@@ -1835,7 +1838,8 @@ static void vxlan_xmit_one(struct sk_buff *skb, struct
net_device *dev,
dst_release(ndst);
dst_vxlan = vxlan_find_vni(vxlan->net, vni,
- dst->sa.sa_family, dst_port);
+ dst->sa.sa_family, dst_port,
+ vxlan->exts);
if (!dst_vxlan)
goto tx_error;
vxlan_encap_bypass(skb, vxlan, dst_vxlan);
@@ -2005,7 +2009,7 @@ static int vxlan_init(struct net_device *dev)
spin_lock(&vn->sock_lock);
vs = vxlan_find_sock(vxlan->net, ipv6 ? AF_INET6 : AF_INET,
-vxlan->dst_port);
+vxlan->dst_port, vxlan->exts);
if (vs && atomic_add_unless(&vs->refcnt, 1, 0)) {
/* If we have a socket with same port already, reuse it */
vxlan_vs_add_dev(vs, vxlan);
@@ -2359,7 +2363,7 @@ static struct socket *vxlan_create_sock(struct net *net,
bool ipv6,
/* Create new listen socket if needed */
static struct vxlan_sock *vxlan_socket_create(struct net *net, __be16 port,
vxlan_rcv_t *rcv, void *data,
- u32 flags)
+ u32 flags, u32 exts)
{
struct vxlan_net *vn = net_generic(net, vxlan_net_id);
struct vxlan_sock *vs;
@@ -2387,6 +2391,7 @@ static struct vxlan_sock *vxlan_socket_create(struct net
*net, __be16 port,
atomic_set(&vs->refcnt, 1);
vs->rcv = rcv;
vs->data = data;
+ vs->exts = exts;
/* Initialize the vxlan udp offloads structure */
vs->udp_offloads.port = port;
@@ -2411,13 +2416,14 @@ static struct vxlan_sock *vxlan_socket_create(struct
net *net, __be16 port,
struct vxlan_sock *vxlan_sock_add(struct net *net, __be16 port,
vxlan_rcv_t *rcv, void *data,
- bool no_share, u32 flags)
+ bool no_share, u32 flags,
+
[ovs-dev] [PATCH 0/6 net-next v2] VXLAN Group Policy Extension
Implements supports for the Group Policy VXLAN extension [0] to provide a lightweight and simple security label mechanism across network peers based on VXLAN. The security context and associated metadata is mapped to/from skb->mark. This allows further mapping to a SELinux context using SECMARK, to implement ACLs directly with nftables, iptables, OVS, tc, etc. The extension is disabled by default and should be run on a distinct port in mixed Linux VXLAN VTEP environments. Liberal VXLAN VTEPs which ignore unknown reserved bits will be able to receive VXLAN-GBP frames. Simple usage example: 10.1.1.1: # ip link add vxlan0 type vxlan id 10 remote 10.1.1.2 gbp # iptables -I OUTPUT -m owner --uid-owner 101 -j MARK --set-mark 0x200 10.1.1.2: # ip link add vxlan0 type vxlan id 10 remote 10.1.1.1 gbp # iptables -I INPUT -m mark --mark 0x200 -j DROP iproute2 [1] and OVS [2] support will be provided in separate patches. [0] https://tools.ietf.org/html/draft-smith-vxlan-group-policy [1] https://github.com/tgraf/iproute2/tree/vxlan-gbp [2] https://github.com/tgraf/ovs/tree/vxlan-gbp Thomas Graf (6): vxlan: Allow for VXLAN extensions to be implemented vxlan: Group Policy extension vxlan: Only bind to sockets with correct extensions enabled openvswitch: Rename GENEVE_TUN_OPTS() to TUN_METADATA_OPTS() openvswitch: Allow for any level of nesting in flow attributes openvswitch: Support VXLAN Group Policy extension drivers/net/vxlan.c | 225 -- include/net/ip_tunnels.h | 5 +- include/net/vxlan.h | 101 +- include/uapi/linux/if_link.h | 8 ++ include/uapi/linux/openvswitch.h | 11 ++ net/openvswitch/flow.c | 2 +- net/openvswitch/flow.h | 14 +- net/openvswitch/flow_netlink.c | 286 ++- net/openvswitch/vport-geneve.c | 2 +- net/openvswitch/vport-vxlan.c| 90 +++- net/openvswitch/vport-vxlan.h| 11 ++ 11 files changed, 572 insertions(+), 183 deletions(-) create mode 100644 net/openvswitch/vport-vxlan.h -- 1.9.3 ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
[ovs-dev] [PATCH 1/6] vxlan: Allow for VXLAN extensions to be implemented
The VXLAN receive code is currently conservative in what it accepts and
will reject any frame that uses any of the reserved VXLAN protocol fields.
The VXLAN draft specifies that "reserved fields MUST be set to zero on
transmit and ignored on receive.".
Retain the current conservative parsing behaviour by default but allows
these fields to be used by VXLAN extensions which are explicitly enabled
on the VXLAN socket respectively VXLAN net_device.
Signed-off-by: Thomas Graf
---
v2:
- No change
drivers/net/vxlan.c | 29 +++--
include/net/vxlan.h | 32 +---
2 files changed, 48 insertions(+), 13 deletions(-)
diff --git a/drivers/net/vxlan.c b/drivers/net/vxlan.c
index 2ab0922..4d52aa9 100644
--- a/drivers/net/vxlan.c
+++ b/drivers/net/vxlan.c
@@ -65,7 +65,7 @@
#define VXLAN_VID_MASK (VXLAN_N_VID - 1)
#define VXLAN_HLEN (sizeof(struct udphdr) + sizeof(struct vxlanhdr))
-#define VXLAN_FLAGS 0x0800 /* struct vxlanhdr.vx_flags required value. */
+#define VXLAN_FLAGS 0x0800 /* struct vxlanhdr.vx_flags default value. */
/* UDP port for VXLAN traffic.
* The IANA assigned port is 4789, but the Linux default is 8472
@@ -1100,22 +1100,28 @@ static int vxlan_udp_encap_recv(struct sock *sk, struct
sk_buff *skb)
if (!pskb_may_pull(skb, VXLAN_HLEN))
goto error;
+ vs = rcu_dereference_sk_user_data(sk);
+ if (!vs)
+ goto drop;
+
/* Return packets with reserved bits set */
vxh = (struct vxlanhdr *)(udp_hdr(skb) + 1);
- if (vxh->vx_flags != htonl(VXLAN_FLAGS) ||
- (vxh->vx_vni & htonl(0xff))) {
- netdev_dbg(skb->dev, "invalid vxlan flags=%#x vni=%#x\n",
- ntohl(vxh->vx_flags), ntohl(vxh->vx_vni));
- goto error;
+
+ /* For backwards compatibility, only allow reserved fields to be
+* used by VXLAN extensions if explicitly requested.
+*/
+ if (vs->exts) {
+ if (!vxh->vni_present)
+ goto error_invalid_header;
+ } else {
+ if (vxh->vx_flags != htonl(VXLAN_FLAGS) ||
+ (vxh->vx_vni & htonl(0xff)))
+ goto error_invalid_header;
}
if (iptunnel_pull_header(skb, VXLAN_HLEN, htons(ETH_P_TEB)))
goto drop;
- vs = rcu_dereference_sk_user_data(sk);
- if (!vs)
- goto drop;
-
vs->rcv(vs, skb, vxh->vx_vni);
return 0;
@@ -1124,6 +1130,9 @@ drop:
kfree_skb(skb);
return 0;
+error_invalid_header:
+ netdev_dbg(skb->dev, "invalid vxlan flags=%#x vni=%#x\n",
+ ntohl(vxh->vx_flags), ntohl(vxh->vx_vni));
error:
/* Return non vxlan pkt */
return 1;
diff --git a/include/net/vxlan.h b/include/net/vxlan.h
index 903461a..3e98d31 100644
--- a/include/net/vxlan.h
+++ b/include/net/vxlan.h
@@ -11,10 +11,35 @@
#define VNI_HASH_BITS 10
#define VNI_HASH_SIZE (1<"
+#endif
+ __u8vx_reserved1;
+ __be16 vx_reserved2;
+ };
+ __be32 vx_flags;
+ };
+ __be32 vx_vni;
};
struct vxlan_sock;
@@ -25,6 +50,7 @@ struct vxlan_sock {
struct hlist_node hlist;
vxlan_rcv_t *rcv;
void *data;
+ u32 exts;
struct work_struct del_work;
struct socket*sock;
struct rcu_head rcu;
--
1.9.3
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
[ovs-dev] [PATCH 5/6] openvswitch: Allow for any level of nesting in flow attributes
nlattr_set() is currently hardcoded to two levels of nesting. This change
introduces struct ovs_len_tbl to define minimal length requirements plus
next level nesting tables to traverse the key attributes to arbitary depth.
Signed-off-by: Thomas Graf
---
v2:
- New patch to allow nested Netlink attributes inside
OVS_TUNNEL_KEY_ATTR_VXLAN_OPTS
net/openvswitch/flow_netlink.c | 106 ++---
1 file changed, 56 insertions(+), 50 deletions(-)
diff --git a/net/openvswitch/flow_netlink.c b/net/openvswitch/flow_netlink.c
index 8980d32..457ccf3 100644
--- a/net/openvswitch/flow_netlink.c
+++ b/net/openvswitch/flow_netlink.c
@@ -50,6 +50,13 @@
#include "flow_netlink.h"
+struct ovs_len_tbl {
+ int len;
+ const struct ovs_len_tbl *next;
+};
+
+#define OVS_ATTR_NESTED -1
+
static void update_range(struct sw_flow_match *match,
size_t offset, size_t size, bool is_mask)
{
@@ -289,29 +296,44 @@ size_t ovs_key_attr_size(void)
+ nla_total_size(28); /* OVS_KEY_ATTR_ND */
}
+static const struct ovs_len_tbl ovs_tunnel_key_lens[OVS_TUNNEL_KEY_ATTR_MAX +
1] = {
+ [OVS_TUNNEL_KEY_ATTR_ID]= { .len = sizeof(u64) },
+ [OVS_TUNNEL_KEY_ATTR_IPV4_SRC] = { .len = sizeof(u32) },
+ [OVS_TUNNEL_KEY_ATTR_IPV4_DST] = { .len = sizeof(u32) },
+ [OVS_TUNNEL_KEY_ATTR_TOS] = { .len = 1 },
+ [OVS_TUNNEL_KEY_ATTR_TTL] = { .len = 1 },
+ [OVS_TUNNEL_KEY_ATTR_DONT_FRAGMENT] = { .len = 0 },
+ [OVS_TUNNEL_KEY_ATTR_CSUM] = { .len = 0 },
+ [OVS_TUNNEL_KEY_ATTR_TP_SRC]= { .len = sizeof(u16) },
+ [OVS_TUNNEL_KEY_ATTR_TP_DST]= { .len = sizeof(u16) },
+ [OVS_TUNNEL_KEY_ATTR_OAM] = { .len = 0 },
+ [OVS_TUNNEL_KEY_ATTR_GENEVE_OPTS] = { .len = OVS_ATTR_NESTED },
+};
+
/* The size of the argument for each %OVS_KEY_ATTR_* Netlink attribute. */
-static const int ovs_key_lens[OVS_KEY_ATTR_MAX + 1] = {
- [OVS_KEY_ATTR_ENCAP] = -1,
- [OVS_KEY_ATTR_PRIORITY] = sizeof(u32),
- [OVS_KEY_ATTR_IN_PORT] = sizeof(u32),
- [OVS_KEY_ATTR_SKB_MARK] = sizeof(u32),
- [OVS_KEY_ATTR_ETHERNET] = sizeof(struct ovs_key_ethernet),
- [OVS_KEY_ATTR_VLAN] = sizeof(__be16),
- [OVS_KEY_ATTR_ETHERTYPE] = sizeof(__be16),
- [OVS_KEY_ATTR_IPV4] = sizeof(struct ovs_key_ipv4),
- [OVS_KEY_ATTR_IPV6] = sizeof(struct ovs_key_ipv6),
- [OVS_KEY_ATTR_TCP] = sizeof(struct ovs_key_tcp),
- [OVS_KEY_ATTR_TCP_FLAGS] = sizeof(__be16),
- [OVS_KEY_ATTR_UDP] = sizeof(struct ovs_key_udp),
- [OVS_KEY_ATTR_SCTP] = sizeof(struct ovs_key_sctp),
- [OVS_KEY_ATTR_ICMP] = sizeof(struct ovs_key_icmp),
- [OVS_KEY_ATTR_ICMPV6] = sizeof(struct ovs_key_icmpv6),
- [OVS_KEY_ATTR_ARP] = sizeof(struct ovs_key_arp),
- [OVS_KEY_ATTR_ND] = sizeof(struct ovs_key_nd),
- [OVS_KEY_ATTR_RECIRC_ID] = sizeof(u32),
- [OVS_KEY_ATTR_DP_HASH] = sizeof(u32),
- [OVS_KEY_ATTR_TUNNEL] = -1,
- [OVS_KEY_ATTR_MPLS] = sizeof(struct ovs_key_mpls),
+static const struct ovs_len_tbl ovs_key_lens[OVS_KEY_ATTR_MAX + 1] = {
+ [OVS_KEY_ATTR_ENCAP] = { .len = OVS_ATTR_NESTED },
+ [OVS_KEY_ATTR_PRIORITY] = { .len = sizeof(u32) },
+ [OVS_KEY_ATTR_IN_PORT] = { .len = sizeof(u32) },
+ [OVS_KEY_ATTR_SKB_MARK] = { .len = sizeof(u32) },
+ [OVS_KEY_ATTR_ETHERNET] = { .len = sizeof(struct ovs_key_ethernet) },
+ [OVS_KEY_ATTR_VLAN] = { .len = sizeof(__be16) },
+ [OVS_KEY_ATTR_ETHERTYPE] = { .len = sizeof(__be16) },
+ [OVS_KEY_ATTR_IPV4] = { .len = sizeof(struct ovs_key_ipv4) },
+ [OVS_KEY_ATTR_IPV6] = { .len = sizeof(struct ovs_key_ipv6) },
+ [OVS_KEY_ATTR_TCP] = { .len = sizeof(struct ovs_key_tcp) },
+ [OVS_KEY_ATTR_TCP_FLAGS] = { .len = sizeof(__be16) },
+ [OVS_KEY_ATTR_UDP] = { .len = sizeof(struct ovs_key_udp) },
+ [OVS_KEY_ATTR_SCTP] = { .len = sizeof(struct ovs_key_sctp) },
+ [OVS_KEY_ATTR_ICMP] = { .len = sizeof(struct ovs_key_icmp) },
+ [OVS_KEY_ATTR_ICMPV6]= { .len = sizeof(struct ovs_key_icmpv6) },
+ [OVS_KEY_ATTR_ARP] = { .len = sizeof(struct ovs_key_arp) },
+ [OVS_KEY_ATTR_ND]= { .len = sizeof(struct ovs_key_nd) },
+ [OVS_KEY_ATTR_RECIRC_ID] = { .len = sizeof(u32) },
+ [OVS_KEY_ATTR_DP_HASH] = { .len = sizeof(u32) },
+ [OVS_KEY_ATTR_TUNNEL]= { .len = OVS_ATTR_NESTED,
+.next = ovs_tunnel_key_lens, },
+ [OVS_KEY_ATTR_MPLS] = { .len = sizeof(struct ovs_key_mpls) },
};
static bool is_all_zero(const u8 *fp, size_t size)
@@ -352,8 +374,8 @@ static int __parse_flow_nlattrs(const struct nlattr *attr,
return -EINVAL;
}
- expected_len = ovs_key_lens[type];
- if (nla_len(nla) != expected_len && e
[ovs-dev] [PATCH 2/6] vxlan: Group Policy extension
Implements supports for the Group Policy VXLAN extension [0] to provide
a lightweight and simple security label mechanism across network peers
based on VXLAN. The security context and associated metadata is mapped
to/from skb->mark. This allows further mapping to a SELinux context
using SECMARK, to implement ACLs directly with nftables, iptables, OVS,
tc, etc.
The group membership is defined by the lower 16 bits of skb->mark, the
upper 16 bits are used for flags.
SELinux allows to manage label to secure local resources. However,
distributed applications require ACLs to implemented across hosts. This
is typically achieved by matching on L2-L4 fields to identify the
original sending host and process on the receiver. On top of that,
netlabel and specifically CIPSO [1] allow to map security contexts to
universal labels. However, netlabel and CIPSO are relatively complex.
This patch provides a lightweight alternative for overlay network
environments with a trusted underlay. No additional control protocol
is required.
Host 1: Host 2:
Group AGroup BGroup B Group A
+-+ +-++---+ +-+
| lxc | | SELinux CTX || httpd | | VM |
+--+--+ +--+--++---+---+ +--+--+
\---+---/ \+---/
| |
+---+---+ +---+---+
| vxlan | | vxlan |
+---+---+ +---+---+
+--+
Backwards compatibility:
A VXLAN-GBP socket can receive standard VXLAN frames and will assign
the default group 0x to such frames. A Linux VXLAN socket will
drop VXLAN-GBP frames. The extension is therefore disabled by default
and needs to be specifically enabled:
ip link add [...] type vxlan [...] gbp
In a mixed environment with VXLAN and VXLAN-GBP sockets, the GBP socket
must run on a separate port number.
Examples:
iptables:
host1# iptables -I OUTPUT -m owner --uid-owner 101 -j MARK --set-mark 0x200
host2# iptables -I INPUT -m mark --mark 0x200 -j DROP
OVS:
# ovs-ofctl add-flow br0
'in_port=1,actions=load:0x200->NXM_NX_TUN_GBP_ID[],NORMAL'
# ovs-ofctl add-flow br0 'in_port=2,tun_gbp_id=0x200,actions=drop'
[0] https://tools.ietf.org/html/draft-smith-vxlan-group-policy
[1] http://lwn.net/Articles/204905/
Signed-off-by: Thomas Graf
---
v2:
- split GBP header definition into separate struct vxlanhdr_gbp as requested
by Alexei
drivers/net/vxlan.c | 161 ++
include/net/vxlan.h | 73 +--
include/uapi/linux/if_link.h | 8 +++
net/openvswitch/vport-vxlan.c | 9 ++-
4 files changed, 198 insertions(+), 53 deletions(-)
diff --git a/drivers/net/vxlan.c b/drivers/net/vxlan.c
index 4d52aa9..b148739 100644
--- a/drivers/net/vxlan.c
+++ b/drivers/net/vxlan.c
@@ -132,6 +132,7 @@ struct vxlan_dev {
__u8 tos; /* TOS override */
__u8 ttl;
u32 flags;/* VXLAN_F_* in vxlan.h */
+ u32 exts; /* Enabled extensions */
struct work_struct sock_work;
struct work_struct igmp_join;
@@ -568,7 +569,8 @@ static struct sk_buff **vxlan_gro_receive(struct sk_buff
**head, struct sk_buff
continue;
vh2 = (struct vxlanhdr *)(p->data + off_vx);
- if (vh->vx_vni != vh2->vx_vni) {
+ if (vh->vx_flags != vh2->vx_flags ||
+ vh->vx_vni != vh2->vx_vni) {
NAPI_GRO_CB(p)->same_flow = 0;
continue;
}
@@ -1095,6 +1097,7 @@ static int vxlan_udp_encap_recv(struct sock *sk, struct
sk_buff *skb)
{
struct vxlan_sock *vs;
struct vxlanhdr *vxh;
+ struct vxlan_metadata md = {0};
/* Need Vxlan and inner Ethernet header to be present */
if (!pskb_may_pull(skb, VXLAN_HLEN))
@@ -1113,6 +1116,22 @@ static int vxlan_udp_encap_recv(struct sock *sk, struct
sk_buff *skb)
if (vs->exts) {
if (!vxh->vni_present)
goto error_invalid_header;
+
+ if (vxh->gbp_present) {
+ struct vxlanhdr_gbp *gbp;
+
+ if (!(vs->exts & VXLAN_EXT_GBP))
+ goto error_invalid_header;
+
+ gbp = (struct vxlanhdr_gbp *)vxh;
+ md.gbp = ntohs(gbp->policy_id);
+
+ if (gbp->dont_learn)
+ md.gbp |= VXLAN_GBP_DONT_LEARN;
+
+ if (gbp->policy_applied)
+ md.gbp |= VXLAN_GBP_POLICY_APPLIED;
+ }
} else {
if (vxh->vx_flags != htonl(VXLAN_FLAGS) ||
(vxh->vx_vni & htonl(0xff)))
@@ -11
[ovs-dev] [PATCH 4/6] openvswitch: Rename GENEVE_TUN_OPTS() to TUN_METADATA_OPTS()
Also factors out Geneve validation code into a new separate function
validate_and_copy_geneve_opts().
A subsequent patch will introduce VXLAN options. Rename the existing
GENEVE_TUN_OPTS() to reflect its extended purpose of carrying generic
tunnel metadata options.
Signed-off-by: Thomas Graf
---
v2:
- Don't rename genev_tun_opt_from_nlattr() and keep it Geneve specific,
pointed out by Jesse.
- Factor out Geneve specific validation code into separate function as
requested by Jesse.
net/openvswitch/flow.c | 2 +-
net/openvswitch/flow.h | 14
net/openvswitch/flow_netlink.c | 72 +++---
3 files changed, 47 insertions(+), 41 deletions(-)
diff --git a/net/openvswitch/flow.c b/net/openvswitch/flow.c
index da2fae0..41f2dfd 100644
--- a/net/openvswitch/flow.c
+++ b/net/openvswitch/flow.c
@@ -691,7 +691,7 @@ int ovs_flow_key_extract(const struct ovs_tunnel_info
*tun_info,
BUILD_BUG_ON((1 << (sizeof(tun_info->options_len) *
8)) - 1
> sizeof(key->tun_opts));
- memcpy(GENEVE_OPTS(key, tun_info->options_len),
+ memcpy(TUN_METADATA_OPTS(key, tun_info->options_len),
tun_info->options, tun_info->options_len);
key->tun_opts_len = tun_info->options_len;
} else {
diff --git a/net/openvswitch/flow.h b/net/openvswitch/flow.h
index a8b30f3..d3d0a40 100644
--- a/net/openvswitch/flow.h
+++ b/net/openvswitch/flow.h
@@ -53,7 +53,7 @@ struct ovs_key_ipv4_tunnel {
struct ovs_tunnel_info {
struct ovs_key_ipv4_tunnel tunnel;
- const struct geneve_opt *options;
+ const void *options;
u8 options_len;
};
@@ -61,10 +61,10 @@ struct ovs_tunnel_info {
* maximum size. This allows us to get the benefits of variable length
* matching for small options.
*/
-#define GENEVE_OPTS(flow_key, opt_len) \
- ((struct geneve_opt *)((flow_key)->tun_opts + \
- FIELD_SIZEOF(struct sw_flow_key, tun_opts) - \
- opt_len))
+#define TUN_METADATA_OFFSET(opt_len) \
+ (FIELD_SIZEOF(struct sw_flow_key, tun_opts) - opt_len)
+#define TUN_METADATA_OPTS(flow_key, opt_len) \
+ ((void *)((flow_key)->tun_opts + TUN_METADATA_OFFSET(opt_len)))
static inline void __ovs_flow_tun_info_init(struct ovs_tunnel_info *tun_info,
__be32 saddr, __be32 daddr,
@@ -73,7 +73,7 @@ static inline void __ovs_flow_tun_info_init(struct
ovs_tunnel_info *tun_info,
__be16 tp_dst,
__be64 tun_id,
__be16 tun_flags,
- const struct geneve_opt *opts,
+ const void *opts,
u8 opts_len)
{
tun_info->tunnel.tun_id = tun_id;
@@ -105,7 +105,7 @@ static inline void ovs_flow_tun_info_init(struct
ovs_tunnel_info *tun_info,
__be16 tp_dst,
__be64 tun_id,
__be16 tun_flags,
- const struct geneve_opt *opts,
+ const void *opts,
u8 opts_len)
{
__ovs_flow_tun_info_init(tun_info, iph->saddr, iph->daddr,
diff --git a/net/openvswitch/flow_netlink.c b/net/openvswitch/flow_netlink.c
index d1eecf7..8980d32 100644
--- a/net/openvswitch/flow_netlink.c
+++ b/net/openvswitch/flow_netlink.c
@@ -432,8 +432,7 @@ static int genev_tun_opt_from_nlattr(const struct nlattr *a,
SW_FLOW_KEY_PUT(match, tun_opts_len, 0xff, true);
}
- opt_key_offset = (unsigned long)GENEVE_OPTS((struct sw_flow_key *)0,
- nla_len(a));
+ opt_key_offset = TUN_METADATA_OFFSET(nla_len(a));
SW_FLOW_KEY_MEMCPY_OFFSET(match, opt_key_offset, nla_data(a),
nla_len(a), is_mask);
return 0;
@@ -558,8 +557,7 @@ static int ipv4_tun_from_nlattr(const struct nlattr *attr,
static int __ipv4_tun_to_nlattr(struct sk_buff *skb,
const struct ovs_key_ipv4_tunnel *output,
- const struct geneve_opt *tun_opts,
- int swkey_tun_opts_len)
+ const void *tun_opts, int swkey_tun_opts_len)
{
if (output->tun_flags & TUNNEL_KEY &&
nla_put_be64(skb, OVS_TUNNEL_KEY_ATTR_ID, output->tun_id))
@@ -600,8 +598,7 @@ static int __ipv4_tun_to_nlattr(struct sk_buff *skb,
static int ipv4_tun_to_nlattr(struct sk_buff *skb,
[ovs-dev] [PATCH 6/6] openvswitch: Support VXLAN Group Policy extension
Introduces support for the group policy extension to the VXLAN virtual
port. The extension is disabled by default and only enabled if the user
has provided the respective configuration.
ovs-vsctl add-port br0 vxlan0 -- \
set Interface vxlan0 type=vxlan options:exts=gbp
The configuration interface to enable the extension is based on a new
attribute OVS_VXLAN_EXT_GBP nested inside OVS_TUNNEL_ATTR_EXTENSION
which can carry additional extensions as needed in the future.
The group policy metadata is stored as binary blob (struct ovs_vxlan_opts)
internally just like Geneve options but transported as nested Netlink
attributes to user space.
Renames the existing TUNNEL_OPTIONS_PRESENT to TUNNEL_GENEVE_OPT with the
binary value kept intact, a new flag TUNNEL_VXLAN_OPT is introduced.
The attributes OVS_TUNNEL_KEY_ATTR_VXLAN_OPTS and existing
OVS_TUNNEL_KEY_ATTR_GENEVE_OPTS are implemented mutually exclusive.
Signed-off-by: Thomas Graf
---
v2:
- Addressed Jesse's request to transport VXLAN options as Netlink
attributes instead of a binary blob. Allows a partial transport of
VXLAN extensions. Internally, the datapath continues to use a binary
blob (defined in vport-vxlan.h) for performance reasons.
- Added new TUNNEL_GENEVE_OPT and TUNNEL_VXLAN_OPT flags to mark
tunnel option flavour
- Correctly report VXLAN options to user space
include/net/ip_tunnels.h | 5 +-
include/uapi/linux/openvswitch.h | 11
net/openvswitch/flow_netlink.c | 114 ++-
net/openvswitch/vport-geneve.c | 2 +-
net/openvswitch/vport-vxlan.c| 81 +++-
net/openvswitch/vport-vxlan.h| 11
6 files changed, 207 insertions(+), 17 deletions(-)
create mode 100644 net/openvswitch/vport-vxlan.h
diff --git a/include/net/ip_tunnels.h b/include/net/ip_tunnels.h
index 25a59eb..ce4db3c 100644
--- a/include/net/ip_tunnels.h
+++ b/include/net/ip_tunnels.h
@@ -97,7 +97,10 @@ struct ip_tunnel {
#define TUNNEL_DONT_FRAGMENT__cpu_to_be16(0x0100)
#define TUNNEL_OAM __cpu_to_be16(0x0200)
#define TUNNEL_CRIT_OPT__cpu_to_be16(0x0400)
-#define TUNNEL_OPTIONS_PRESENT __cpu_to_be16(0x0800)
+#define TUNNEL_GENEVE_OPT __cpu_to_be16(0x0800)
+#define TUNNEL_VXLAN_OPT __cpu_to_be16(0x1000)
+
+#define TUNNEL_OPTIONS_PRESENT (TUNNEL_GENEVE_OPT | TUNNEL_VXLAN_OPT)
struct tnl_ptk_info {
__be16 flags;
diff --git a/include/uapi/linux/openvswitch.h b/include/uapi/linux/openvswitch.h
index 3a6dcaa..e474c95 100644
--- a/include/uapi/linux/openvswitch.h
+++ b/include/uapi/linux/openvswitch.h
@@ -248,11 +248,21 @@ enum ovs_vport_attr {
#define OVS_VPORT_ATTR_MAX (__OVS_VPORT_ATTR_MAX - 1)
+enum {
+ OVS_VXLAN_EXT_UNSPEC,
+ OVS_VXLAN_EXT_GBP, /* Flag or __u32 */
+ __OVS_VXLAN_EXT_MAX,
+};
+
+#define OVS_VXLAN_EXT_MAX (__OVS_VXLAN_EXT_MAX - 1)
+
+
/* OVS_VPORT_ATTR_OPTIONS attributes for tunnels.
*/
enum {
OVS_TUNNEL_ATTR_UNSPEC,
OVS_TUNNEL_ATTR_DST_PORT, /* 16-bit UDP port, used by L4 tunnels. */
+ OVS_TUNNEL_ATTR_EXTENSION,
__OVS_TUNNEL_ATTR_MAX
};
@@ -324,6 +334,7 @@ enum ovs_tunnel_key_attr {
OVS_TUNNEL_KEY_ATTR_GENEVE_OPTS,/* Array of Geneve options. */
OVS_TUNNEL_KEY_ATTR_TP_SRC, /* be16 src Transport Port. */
OVS_TUNNEL_KEY_ATTR_TP_DST, /* be16 dst Transport Port. */
+ OVS_TUNNEL_KEY_ATTR_VXLAN_OPTS, /* Nested OVS_VXLAN_EXT_* */
__OVS_TUNNEL_KEY_ATTR_MAX
};
diff --git a/net/openvswitch/flow_netlink.c b/net/openvswitch/flow_netlink.c
index 457ccf3..cea492b 100644
--- a/net/openvswitch/flow_netlink.c
+++ b/net/openvswitch/flow_netlink.c
@@ -49,6 +49,7 @@
#include
#include "flow_netlink.h"
+#include "vport-vxlan.h"
struct ovs_len_tbl {
int len;
@@ -268,6 +269,9 @@ size_t ovs_tun_key_attr_size(void)
+ nla_total_size(0)/* OVS_TUNNEL_KEY_ATTR_CSUM */
+ nla_total_size(0)/* OVS_TUNNEL_KEY_ATTR_OAM */
+ nla_total_size(256) /* OVS_TUNNEL_KEY_ATTR_GENEVE_OPTS */
+ /* OVS_TUNNEL_KEY_ATTR_VXLAN_OPTS is mutually exclusive with
+* OVS_TUNNEL_KEY_ATTR_GENEVE_OPTS and covered by it.
+*/
+ nla_total_size(2)/* OVS_TUNNEL_KEY_ATTR_TP_SRC */
+ nla_total_size(2); /* OVS_TUNNEL_KEY_ATTR_TP_DST */
}
@@ -308,6 +312,7 @@ static const struct ovs_len_tbl
ovs_tunnel_key_lens[OVS_TUNNEL_KEY_ATTR_MAX + 1]
[OVS_TUNNEL_KEY_ATTR_TP_DST]= { .len = sizeof(u16) },
[OVS_TUNNEL_KEY_ATTR_OAM] = { .len = 0 },
[OVS_TUNNEL_KEY_ATTR_GENEVE_OPTS] = { .len = OVS_ATTR_NESTED },
+ [OVS_TUNNEL_KEY_ATTR_VXLAN_OPTS]= { .len = OVS_ATTR_NESTED },
};
/* The size of the argument for each %OVS_KEY_ATTR_* Netlink attribute. */
@@ -460,6 +465,41 @@ static int genev_tun_opt_from_nlattr(const struct nlattr
Re: [ovs-dev] [PATCH] vagrant: switch to use out of tree build
pushed to master. Thanks for the review. On Thu, Jan 8, 2015 at 2:31 PM, Thomas Graf wrote: > On 01/08/15 at 03:00pm, Andy Zhou wrote: >> Vagrant shared folder, at least on the default virtual box, does not >> support the creation of the socket files. If one were to build OVS >> under /vagrant, 'make check' would not work. >> >> Out of tree builds can be used to work around this issue. >> See Install.md for instructions. >> >> Since out of tree builds requires a clean source tree, Vagrantfile can >> not be a generated file. This commit removes Vagrantfile.in, commit >> Vagrantfile instead. >> >> Signed-off-by: Andy Zhou > > Very nice > > Acked-by: Thomas Graf ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
[ovs-dev] [PATCH RFC v6 0/1] netdev-dpdk: add dpdk vhost ports
Submitting this as an RFC as it is dependent on DPDK v1.8.0 support being added to OVS - that is being reworked at present. If anyone wants to try this out, they would need to use DPDK v1.8.0 and apply the below patches to OVS (note they cause a unit test failure, hence rework) http://openvswitch.org/pipermail/dev/2014-December/049722.html http://openvswitch.org/pipermail/dev/2014-December/049723.html Will re-submit this as non-RFC when DPDK v1.8.0 patch for OVS is ready. INSTALL.DPDK.md | 236 + Makefile.am |4 + lib/automake.mk |1 + lib/netdev-dpdk.c | 649 +++ lib/netdev.c|3 +- utilities/automake.mk |3 +- utilities/qemu-wrap.py | 389 vswitchd/ovs-vswitchd.c |4 +- 8 files changed, 1177 insertions(+), 112 deletions(-) mode change 100644 => 100755 lib/netdev-dpdk.c create mode 100755 utilities/qemu-wrap.py -- 1.7.4.1 ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
[ovs-dev] [PATCH RFC v6 1/1] netdev-dpdk: add dpdk vhost ports
This patch adds support for a new port type to userspace datapath called dpdkvhost. This allows KVM (QEMU) to offload the servicing of virtio-net devices to its associated dpdkvhost port. Instructions for use are in INSTALL.DPDK. This has been tested on Intel multi-core platforms and with clients that have virtio-net interfaces. ver 6: - rebased with master - modified to use DPDK v1.8.0 vhost library - reworked for review comments ver 5: - rebased against latest master ver 4: - added eventfd_link.h and eventfd_link.c to EXTRA_DIST in utilities/automake.mk - rebased with master to work with DPDK 1.7 ver 3: - rebased with master ver 2: - rebased with master Signed-off-by: Ciara Loftus Signed-off-by: Kevin Traynor Signed-off-by: Maryam Tahhan --- INSTALL.DPDK.md | 236 + Makefile.am |4 + lib/automake.mk |1 + lib/netdev-dpdk.c | 649 +++ lib/netdev.c|3 +- utilities/automake.mk |3 +- utilities/qemu-wrap.py | 389 vswitchd/ovs-vswitchd.c |4 +- 8 files changed, 1177 insertions(+), 112 deletions(-) mode change 100644 => 100755 lib/netdev-dpdk.c create mode 100755 utilities/qemu-wrap.py diff --git a/INSTALL.DPDK.md b/INSTALL.DPDK.md index 2cc7636..da8116d 100644 --- a/INSTALL.DPDK.md +++ b/INSTALL.DPDK.md @@ -17,6 +17,7 @@ Building and Installing: Required DPDK 1.7 +Optional `fuse`, `fuse-devel` 1. Configure build & install DPDK: 1. Set `$DPDK_DIR` @@ -264,6 +265,241 @@ A general rule of thumb for better performance is that the client application should not be assigned the same dpdk core mask "-c" as the vswitchd. +DPDK vHost: +--- + +Prerequisites: +1. DPDK 1.8 with vHost support enabled and recompile OVS as above. + + Update `config/common_linuxapp` so that DPDK is built with vHost + libraries: + + `CONFIG_RTE_LIBRTE_VHOST=y` + +2. Insert the Fuse module: + + `modprobe fuse` + +3. Build and insert the `eventfd_link` module: + + `cd $DPDK_DIR/lib/librte_vhost/eventfd_link/` + `make` + `insmod $DPDK_DIR/lib/librte_vhost/eventfd_link.ko` + +4. Remove /dev/vhost-net character device: + + `rm -rf /dev/vhost-net` + +Following the steps above to create a bridge, you can now add DPDK vHost +as a port to the vswitch. + +`ovs-vsctl add-port br0 dpdkvhost0 -- set Interface dpdkvhost0 type=dpdkvhost` + +Unlike DPDK ring ports, DPDK vHost ports can have arbitrary names: + +`ovs-vsctl add-port br0 port123ABC -- set Interface port123ABC type=dpdkvhost` + +However, please note that when attaching userspace devices to QEMU, the +name provided during the add-port operation must match the ifname parameter +on the QEMU command line. + +DPDK vHost VM configuration: + + +1. Configure virtio-net adaptors: + The guest must be configured with virtio-net adapters and offloads + MUST BE DISABLED. This means the following parameters should be passed + to the QEMU binary: + + ``` + -netdev tap,id=,script=no,downscript=no,ifname=,vhost=on + -device virtio-net-pci,netdev=net1,mac=,csum=off,gso=off, + guest_tso4=off,guest_tso6=off,guest_ecn=off + ``` + + Repeat the above parameters for multiple devices. + +2. Configure huge pages: + QEMU must allocate the VM's memory on hugetlbfs. Vhost ports access a + virtio-net device's virtual rings and packet buffers mapping the VM's + physical memory on hugetlbfs. To enable vhost-ports to map the VM's + memory into their process address space, pass the following paramters + to QEMU: + + `-mem-path /dev/hugepages -mem-prealloc` + +DPDK vHost with standard vHost: +--- + +DPDK vHost ports use a Linux* character device to communicate with QEMU. +By default it is set to `/dev/vhost-net`. This conflicts with the kernel +vHost device, hence the need to remove `/dev/vhost-net` above. However, +if you wish to use kernel vhost in parallel, you can specify an +alternative basename on the vswitchd command line like so: + + `./vswitchd/ovs-vswitchd --dpdk --basename my-vhost-net -c 0x1 ...` + +Note that the basename arguement and associated string must be the first +arguements after `--dpdk` and come before the EAL arguements. + +DPDK vHost VM configuration with standard vHost: + + +1. As with the "normal" (i.e. using `/dev/vhost-net`) DPDK vHost setup, +the guest must be configured with virtio-net adapters and offloads +MUST BE DISABLED. However, this time you must also pass in a `vhostfd` +argument: + + ``` + -netdev tap,id=,script=no,downscript=no,ifname=,vhost=on, + vhostfd= + -device virtio-net-pci,netdev=net1,mac=,csum=off,gso=off, + guest_tso4=off,guest_tso6=off,guest_ecn=off + ``` + + The open file descriptor must be passed to QEMU running as a chi
Re: [ovs-dev] [PATCH net] gso: do GSO for local skb with size bigger than MTU
于 2015年01月09日 03:55, Jesse Gross 写道: On Thu, Jan 8, 2015 at 1:39 AM, Fan Du wrote: 于 2015年01月08日 04:52, Jesse Gross 写道: My understanding is: controller sets the forwarding rules into kernel datapath, any flow not matching with the rules are threw to controller by upcall. Once the rule decision is made by controller, then, this flow packet is pushed down to datapath to be forwarded again according to the new rule. So I'm not sure whether pushing the over-MTU-sized packet or pushing the forged ICMP without encapsulation to controller is required by current ovs implementation. By doing so, such over-MTU-sized packet is treated as a event for the controller to be take care of. If flows are implementing routing (again, they are doing things like decrementing the TTL) then it is necessary for them to also handle this situation using some potentially new primitives (like a size check). Otherwise you end up with issues like the ones that I mentioned above like needing to forge addresses because you don't know what the correct ones are. Thanks for explaining, Jesse! btw, I don't get it about "to forge addresses", building ICMP message with Guest packet doesn't require to forge address when not encapsulating ICMP message with outer headers. Your patch has things like this (for the inner IP header): + new_ip->saddr = orig_ip->daddr; + new_ip->daddr = orig_ip->saddr; These addresses are owned by the endpoints, not the host generating generating the ICMP message, so I would consider that to be forging addresses. If the flows aren't doing things to implement routing, then you really have a flat L2 network and you shouldn't be doing this type of behavior at all as I described in the original plan. For flows implementing routing scenario: First of all, over-MTU-sized packet could only be detected once the flow as been consulted(each port could implement a 'check' hook to do this), and just before send to the actual port. Then pushing the over-MTU-sized packet back to controller, it's the controller who will will decide whether to build ICMP message, or whatever routing behaviour it may take. And sent it back with the port information. This ICMP message will travel back to Guest. Why does the flow has to use primitive like a "check size"? "check size" will only take effect after do_output. I'm not very clear with this approach. Checking the size obviously needs to be an action that would take place before outputting in order for it to have any effect. Attaching a check to a port does not fit in very well with the other primitives of OVS, so I think an action is the obvious place to put it. If flow is defined as: CHECK_SIZE -> OUTPUT Then traversing actions at CHECK_SIZE needs to find the exactly OUTPUT port, thus get its underlay encapsulation method as well as valid route for physical NIC MTU, with those information can calculation whether GSOed packets exceeds physical MTU. This is feasible anyway at the first look. After this, it's the controller responsibility to handle such event. If the CHECK_SIZE returns positive(over-MTU-sized packets show up), then call output_userspace to push this packet upper wards. I'm not sure this vague idea is the expected behaviour as required by "L3 processing". And not all scenario involving flow with routing behaviour, just set up a vxlan tunnel, and attach KVM guest or Docker onto it for playing or developing. This wouldn't necessarily require user to set additional specific flows to make over-MTU-sized packet pass through the tunnel correctly. In such scenario, I think the original patch in this thread to fragment tunnel packet is still needed OR workout a generic component to build ICMP for all type tunnel in L2 level. Both of those will act as a backup plan as there is no such specific flow as default. In these cases, we should find a way to adjust the MTU, preferably automatically using virtio. -- No zuo no die but I have to try. ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH net] gso: do GSO for local skb with size bigger than MTU
于 2015年01月09日 03:55, Jesse Gross 写道: On Thu, Jan 8, 2015 at 1:39 AM, Fan Du wrote: >于 2015年01月08日 04:52, Jesse Gross 写道: >>> >>>My understanding is: >>> >controller sets the forwarding rules into kernel datapath, any flow not >>> >matching >>> >with the rules are threw to controller by upcall. Once the rule decision >>> >is >>> >made >>> >by controller, then, this flow packet is pushed down to datapath to be >>> >forwarded >>> >again according to the new rule. >>> > >>> >So I'm not sure whether pushing the over-MTU-sized packet or pushing the >>> >forged ICMP >>> >without encapsulation to controller is required by current ovs >>> >implementation. By doing >>> >so, such over-MTU-sized packet is treated as a event for the controller >>> >to >>> >be take >>> >care of. >> >>If flows are implementing routing (again, they are doing things like >>decrementing the TTL) then it is necessary for them to also handle >>this situation using some potentially new primitives (like a size >>check). Otherwise you end up with issues like the ones that I >>mentioned above like needing to forge addresses because you don't know >>what the correct ones are. > > >Thanks for explaining, Jesse! > >btw, I don't get it about "to forge addresses", building ICMP message >with Guest packet doesn't require to forge address when not encapsulating >ICMP message with outer headers. Your patch has things like this (for the inner IP header): + new_ip->saddr = orig_ip->daddr; + new_ip->daddr = orig_ip->saddr; These addresses are owned by the endpoints, not the host generating generating the ICMP message, so I would consider that to be forging addresses. >If the flows aren't doing things to >> >>implement routing, then you really have a flat L2 network and you >>shouldn't be doing this type of behavior at all as I described in the >>original plan. > > >For flows implementing routing scenario: >First of all, over-MTU-sized packet could only be detected once the flow >as been consulted(each port could implement a 'check' hook to do this), >and just before send to the actual port. > >Then pushing the over-MTU-sized packet back to controller, it's the >controller >who will will decide whether to build ICMP message, or whatever routing >behaviour >it may take. And sent it back with the port information. This ICMP message >will >travel back to Guest. > >Why does the flow has to use primitive like a "check size"? "check size" >will only take effect after do_output. I'm not very clear with this >approach. Checking the size obviously needs to be an action that would take place before outputting in order for it to have any effect. Attaching a check to a port does not fit in very well with the other primitives of OVS, so I think an action is the obvious place to put it. >And not all scenario involving flow with routing behaviour, just set up a >vxlan tunnel, and attach KVM guest or Docker onto it for playing or >developing. >This wouldn't necessarily require user to set additional specific flows to >make >over-MTU-sized packet pass through the tunnel correctly. In such scenario, I >think the original patch in this thread to fragment tunnel packet is still >needed >OR workout a generic component to build ICMP for all type tunnel in L2 >level. >Both of those will act as a backup plan as there is no such specific flow as >default. In these cases, we should find a way to adjust the MTU, preferably automatically using virtio. I'm gonna to argue this a bit more here. virtio_net pose no limit at its simulated net device, actually it can fall into anywhere between 68 and 65535. Most importantly, virtio_net just simulates NIC, it just can’t assume/presume there is an encapsulating port at its downstream. How should virtio automatically adjust its upper guest MTU? -- No zuo no die but I have to try. ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
