From: Alexei Starovoitov
> On Tue, Jan 6, 2015 at 6:05 PM, Thomas Graf wrote:
> > +struct vxlan_gbp {
> > +#ifdef __LITTLE_ENDIAN_BITFIELD
> > + __u8reserved_flags1:3,
> ...
> > + __be16 policy_id;
> > +} __packed;
>
> are you sure that compiler will be smart enough
> to do single
On 01/06/15 at 07:46pm, Tom Herbert wrote:
> On Tue, Jan 6, 2015 at 6:05 PM, Thomas Graf wrote:
> > 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 fi
On 01/07/15 at 10:03am, David Laight wrote:
> From: Alexei Starovoitov
> > On Tue, Jan 6, 2015 at 6:05 PM, Thomas Graf wrote:
> > > +struct vxlan_gbp {
> > > +#ifdef __LITTLE_ENDIAN_BITFIELD
> > > + __u8reserved_flags1:3,
> > ...
> > > + __be16 policy_id;
> > > +} __packed;
> >
>
On 01/06/15 at 07:37pm, Alexei Starovoitov wrote:
> Even it works ok, I think this struct layout is ugly.
> imo would be much easier to read if you replace
> the whole vxlanhdr with vxlanhdr_gbp
> or split vxlanhdr into two 32-bit structs.
> then __packed hacks won't be needed.
The main reason why
> We've heard similar reports before but it's challenging to find the
> problem. I can't reproduce the problem on my 32-bit Debian system by
> just, for example, switching to GCC 4.6.
From [here]( http://openvswitch.org/pipermail/dev/2014-December/049833.html),
you'll see I have a number of boar
On 01/06/15 at 07:46pm, Pravin Shelar wrote:
> On Tue, Jan 6, 2015 at 6:10 PM, Thomas Graf wrote:
> > __vlan_put_tag() was renamed to vlan_insert_tag_set_proto() with
> > the argument list kept intact.
> >
> > Upstream: 62749e ("vlan: rename __vlan_put_tag to
> > vlan_insert_tag_set_proto")
> > S
There are other parts of the document that needs to
reference some building steps. Instead of copying
and explaining again, this patch splits the building
section in three sections that can be referenced.
Signed-off-by: Flavio Leitner
---
INSTALL.md | 138 ++-
The kernel datapath supports only port 4789 for VXLAN tunnel creation.
Added support in order to allow for the VXLAN tunnel port to be
configurable to any port number set by the userspace.
The patch also checks to see if an existing WFP filter, for the
necessary UDP tunnel port, is already created
On 01/07/15 at 12:13pm, Flavio Leitner wrote:
> There are other parts of the document that needs to
> reference some building steps. Instead of copying
> and explaining again, this patch splits the building
> section in three sections that can be referenced.
>
> Signed-off-by: Flavio Leitner
Lo
Hi Sorin, thank you for working on this.
Do you thing the default port filter had to be created during initialization ?
On another thing, since OvsTunnelAddFilterEx is called with IRQL = PASSIVE and
no lock is handled it may be called from multiple thread contexts. I am not
sure if opening. Clo
> UPDATE: With a fresh "apt-get dist-upgrade" on Ubuntu 14.10 and a fresh
> "git pull" on the openvswitch repo, the clang error and test #27 hangup are
> not reproducible on that platform.
>
> The test #27 hangup is still reproducible on CentOS 7 after a fresh "yum
> upgrade" and "git pull" on th
On Tue, Jan 6, 2015 at 6:05 PM, Thomas Graf wrote:
> 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 a
On 01/07/15 at 08:05am, Tom Herbert wrote:
> Associating a sixteen bit field with security is worrisome, especially
> considering that VXLAN provides no verification for any header fields
> and doesn't even advocate use of outer UDP checksum so the field is
> susceptible to an undetected single bit
This series is based on my latest suggestions sent
after the introduction of the security guide to the
git repo.
Flavio Leitner (3):
SECURITY.md: contributors must agree to maintain
SECURITY.md: disclosure date can be negotiated
SECURITY.md: LTS branches triggers version release
SECURITY.
There is no point in having the special process if a
contributor refuses or doesn't agree with the
confidentiality terms.
Signed-off-by: Flavio Leitner
---
SECURITY.md | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/SECURITY.md b/SECURITY.md
index e1db4cb..e66a43f 100644
--
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 Comput
Stakeholders might need extra time to provide the update,
so let's leave it open to negotiate case by case with the
final word on the Open vSwitch security team's hands. A
default policy is provided as a reference.
Signed-off-by: Flavio Leitner
---
SECURITY.md | 13 ++---
1 file changed
The release cycle is in order of months currently, so when a
security fix is applied to LTS (long-term support) branches,
it is recommended to release a new version.
The idea is to keep the latest LTS tarball less vunerable.
Signed-off-by: Flavio Leitner
---
SECURITY.md | 3 +++
1 file changed,
I know it's been a little while since you submitted these patches.
Don't worry, I'm spending a little time reworking some bits of code that
bother me a little. Before I apply anything, I'll pass along the
changes I make for your review.
___
dev mailing l
On Wed, Jan 07, 2015 at 02:26:40PM -0200, Flavio Leitner wrote:
> There is no point in having the special process if a
> contributor refuses or doesn't agree with the
> confidentiality terms.
>
> Signed-off-by: Flavio Leitner
Applied, thanks!
___
dev m
On Wed, Jan 7, 2015 at 8:21 AM, Thomas Graf wrote:
> On 01/07/15 at 08:05am, Tom Herbert wrote:
>> Associating a sixteen bit field with security is worrisome, especially
>> considering that VXLAN provides no verification for any header fields
>> and doesn't even advocate use of outer UDP checksum
On Wed, Jan 07, 2015 at 02:26:41PM -0200, Flavio Leitner wrote:
> Stakeholders might need extra time to provide the update,
> so let's leave it open to negotiate case by case with the
> final word on the Open vSwitch security team's hands. A
> default policy is provided as a reference.
>
> Signed
Thanks for the update.
Please let us know if there is anything you need us to work on.
Dennis
-Original Message-
From: Ben Pfaff [mailto:b...@nicira.com]
Sent: Wednesday, January 07, 2015 11:54 AM
To: Flynn, Dennis R (Dennis)
Cc: dev@openvswitch.org
Subject: Re: [ovs-dev] [PATCH 0/3] au
On Wed, Jan 07, 2015 at 02:26:42PM -0200, Flavio Leitner wrote:
> The release cycle is in order of months currently, so when a
> security fix is applied to LTS (long-term support) branches,
> it is recommended to release a new version.
>
> The idea is to keep the latest LTS tarball less vunerable.
On Tue, Jan 06, 2015 at 01:49:05PM -0800, Gurucharan Shetty wrote:
> In OVS, we currently use the term 'facility' to mean the place
> where we log (syslog, console or file). In Linux's syslog() and
> rfc5424, the term 'facility' is used to specify what type of program
> is logging the message (e.g:
On 01/07/15 at 08:56am, Tom Herbert wrote:
> On Wed, Jan 7, 2015 at 8:21 AM, Thomas Graf wrote:
> > If the VNI is not already used for another purpose, yes. The solution
> > as proposed can be integrated into existing VXLAN overlays separated by
> > VNI. It is also compatible with hardware VXLAN V
On Wed, Jan 7, 2015 at 3:10 AM, Thomas Graf wrote:
> On 01/06/15 at 07:37pm, Alexei Starovoitov wrote:
>> Even it works ok, I think this struct layout is ugly.
>> imo would be much easier to read if you replace
>> the whole vxlanhdr with vxlanhdr_gbp
>> or split vxlanhdr into two 32-bit structs.
>
On Tuesday, January 06, 2015 01:49:05 PM Gurucharan Shetty wrote:
> In OVS, we currently use the term 'facility' to mean the place
> where we log (syslog, console or file). In Linux's syslog() and
> rfc5424, the term 'facility' is used to specify what type of program
> is logging the message (e.g:
On 29 December 2014 at 14:46, Ben Pfaff wrote:
> On Mon, Dec 15, 2014 at 03:30:05PM -0800, Joe Stringer wrote:
>> Signed-off-by: Joe Stringer
>
> Seem obviously correct.
>
> Acked-by: Ben Pfaff
Thanks, I applied this series to master.
___
dev mailing
Thanks,
Some questions are below...
On 12/31/14 4:16 PM, Pravin Shelar wrote:
On Tue, Dec 30, 2014 at 7:12 AM, Thomas F Herbert
wrote:
This is the linux kernel datapath portion of the 802.1AD patch.
Signed-off-by: Thomas F Herbert
---
datapath/actions.c|
On Jan 6, 2015, at 3:10 PM, Ben Pfaff wrote:
> On Tue, Jan 06, 2015 at 03:11:33PM -0800, Jarno Rajahalme wrote:
>> Otherwise compiling with -msse4.2 (or -march=native on a SSE4.2
>> capable CPU) will produce a test failure due to the CRC32-based hash
>> function being different from mhash.
>>
>
>
> This term change is big enough that I think it deserves to go to
> the NEWS file as well.
I would like to clarify (to make sure we are on the same page) that
the term change does not change anything for a system admin except
that he now sees the word 'destination' instead of the word 'facility'
On Jan 7, 2015, at 3:48 AM, Finucane, Stephen
wrote:
>> We've heard similar reports before but it's challenging to find the
>> problem. I can't reproduce the problem on my 32-bit Debian system by
>> just, for example, switching to GCC 4.6.
>
> From [here]( http://openvswitch.org/pipermail/dev
On Wed, Jan 07, 2015 at 11:48:59AM +, Finucane, Stephen wrote:
> > We've heard similar reports before but it's challenging to find the
> > problem. I can't reproduce the problem on my 32-bit Debian system by
> > just, for example, switching to GCC 4.6.
>
> From [here]( http://openvswitch.org/
Hi Eitan,
I think we should keep the default port filter creation at the initialization
phase because most users are using the default port.
Regarding the new filter creation for other tunnel port, the
OvsTunnelAddFilterEx function does not open the session to the filtering
engine. The session
Hi,
On Tue, Dec 30, 2014 at 5:45 PM, Syam Sidhardhan wrote:
> version.h inclusion is not necessary as detected by versioncheck.
>
> Signed-off-by: Syam Sidhardhan
> ---
> net/openvswitch/vport-geneve.c |2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/net/openvswitch/vport-geneve.c b
This patch is against net-next, you need to post it on netdev
(net...@vger.kernel.org) mailing list as well.
On Tue, Dec 30, 2014 at 4:15 AM, Syam Sidhardhan wrote:
> version.h inclusion is not necessary as detected by versioncheck.
>
> Signed-off-by: Syam Sidhardhan
> ---
> net/openvswitch/vpo
On Tue, Jan 6, 2015 at 9:58 PM, Fan Du wrote:
> 于 2015年01月07日 03:11, Jesse Gross 写道:
One of the reasons for only doing path MTU discovery
>>for L3 is that it operates seamlessly as part of normal operation -
>>there is no need to forge addresses or potentially generate ICMP whe
Hi Sorin,
On the default port, it is also created through the user mode using the NL
interface so if we create all other ports dynamically I would prefer to create
the default port using the same method. (unless you see an issue here).
On the concurrency issue: The spec reads as follows:
" Eac
On Wednesday, January 07, 2015 10:54:18 AM Gurucharan Shetty wrote:
> >
> > This term change is big enough that I think it deserves to go to
> > the NEWS file as well.
> I would like to clarify (to make sure we are on the same page) that
> the term change does not change anything for a system admin
On Wednesday, January 07, 2015 01:10:10 PM Thomas F Herbert wrote:
> Thanks,
>
> Some questions are below...
>
> On 12/31/14 4:16 PM, Pravin Shelar wrote:
> > On Tue, Dec 30, 2014 at 7:12 AM, Thomas F Herbert
> > wrote:
> >> This is the linux kernel datapath portion of the 802.1AD patch.
> >>
>
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
On Wed, Jan 7, 2015 at 2:27 AM, Thomas Graf wrote:
> On 01/06/15 at 07:46pm, Tom Herbert wrote:
>> On Tue, Jan 6, 2015 at 6:05 PM, Thomas Graf wrote:
>> > The VXLAN receive code is currently conservative in what it accepts and
>> > will reject any frame that uses any of the reserved VXLAN protoco
On Tue, Jan 6, 2015 at 6:05 PM, Thomas Graf wrote:
> 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
This is generally a good idea (even outside
On Tue, Jan 6, 2015 at 6:05 PM, Thomas Graf wrote:
> A VXLAN net_device looking for an appropriate socket may only
> consider a socket which has the exact set of extensions enabled.
> If none can be found, a new socket must be created.
Maybe it's just the phrasing of the commit message but won't
On Tue, Jan 6, 2015 at 6:05 PM, Thomas Graf wrote:
> The group policy metadata is handled in the same way as Geneve options
> and transported as binary blob in a new Netlink attribute
> OVS_TUNNEL_KEY_ATTR_VXLAN_OPTS which is mutually exclusive to the
> existing OVS_TUNNEL_KEY_ATTR_GENEVE_OPTS.
C
On 01/07/15 at 02:45pm, Jesse Gross wrote:
> On Tue, Jan 6, 2015 at 6:05 PM, Thomas Graf wrote:
> > A VXLAN net_device looking for an appropriate socket may only
> > consider a socket which has the exact set of extensions enabled.
> > If none can be found, a new socket must be created.
>
> Maybe
On 01/07/15 at 02:46pm, Jesse Gross wrote:
> On Tue, Jan 6, 2015 at 6:05 PM, Thomas Graf wrote:
> > 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: Tho
On 01/07/15 at 02:46pm, Jesse Gross wrote:
> On Tue, Jan 6, 2015 at 6:05 PM, Thomas Graf wrote:
> > The group policy metadata is handled in the same way as Geneve options
> > and transported as binary blob in a new Netlink attribute
> > OVS_TUNNEL_KEY_ATTR_VXLAN_OPTS which is mutually exclusive to
On 01/07/15 at 02:45pm, Jesse Gross wrote:
> My concern is that having multiple (and potentially overlapping)
> extensions is going to make the VXLAN code very messy and hard to
> follow. I think there's already quite a big of complexity there from
> the DOVE extensions (which are basically dead at
On 01/07/15 at 09:32am, Alexei Starovoitov wrote:
> I'm afraid 'union' style with first u8 flags working as selector
> won't work for the case you're describing, but since
> md.gbp = ntohs(vxh->gbp.policy_id);
> 2652: 41 0f b7 55 0a movzwl 0xa(%r13),%edx
> t
On Wed, Jan 7, 2015 at 3:27 PM, Thomas Graf wrote:
>
> Would you like something like this?
yes. imo this version is much easier to read
and reason about different bits in protocol.
May be even use a flag mask on '__be32 vx_flags'
instead of calling out 'gbp_present' as explicit bitfield.
Then di
On Wed, Jan 7, 2015 at 3:24 PM, Thomas Graf wrote:
> On 01/07/15 at 02:45pm, Jesse Gross wrote:
>> My concern is that having multiple (and potentially overlapping)
>> extensions is going to make the VXLAN code very messy and hard to
>> follow. I think there's already quite a big of complexity ther
On 01/07/15 at 04:02pm, Tom Herbert wrote:
> Do you know how could GPE work with GBP they want to use the same bits
> in header for data? Seems like these are mutually exclusive
> extensions. RCO should be fine with either :-)
Yes, GBP and GPE are mutually exclusive extensions. Although
GPE would
On Wed, Jan 7, 2015 at 4:14 PM, Thomas Graf wrote:
> On 01/07/15 at 04:02pm, Tom Herbert wrote:
>> Do you know how could GPE work with GBP they want to use the same bits
>> in header for data? Seems like these are mutually exclusive
>> extensions. RCO should be fine with either :-)
>
> Yes, GBP an
On Wed, Jan 7, 2015 at 3:01 PM, Thomas Graf wrote:
> On 01/07/15 at 02:46pm, Jesse Gross wrote:
>> On Tue, Jan 6, 2015 at 6:05 PM, Thomas Graf wrote:
>> > The group policy metadata is handled in the same way as Geneve options
>> > and transported as binary blob in a new Netlink attribute
>> > OVS
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
---
vswitchd/automake.mk | 2 +-
vtep/automake.mk | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/vswitchd/automake.mk b/vswitchd/aut
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
Ben,
Please find attached a tar ball containing _debian/config.{h, log, status}
of my environment where I experienced this problem. I am running Ubuntu on
Vagrant atop MacBookPro. VM has 1 vCPU core and 512MB memory as shown below.
vagrant@precise64:~$ cat /proc/cpuinfo
processor : 0
vendor_id
On Thu, Jan 08, 2015 at 02:02:11PM +0900, Motonori Shindo wrote:
> Please find attached a tar ball containing _debian/config.{h, log, status}
> of my environment where I experienced this problem. I am running Ubuntu on
> Vagrant atop MacBookPro. VM has 1 vCPU core and 512MB memory as shown below.
60 matches
Mail list logo