netdev - Re: in kernel 2.6.x, tun/tap nic supports vlan packets

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 22 Apr 2014 18:53:57 +0100
From:	Ben Hutchings <ben@...adent.org.uk>
To:	Willy Tarreau <w@....eu>
Cc:	zhuyj <zyjzyj2000@...il.com>,
	"David S. Miller" <davem@...emloft.net>, netdev@...r.kernel.org,
	joe@...ches.com, julia.lawall@...6.fr, dingtianhong@...wei.com,
	linux-kernel@...r.kernel.org, jasowang@...hat.com, mst@...hat.com,
	"Yang, Zhangle (Eric)" <Zhangle.Yang@...driver.com>,
	"Wu, Kuaikuai" <Kuaikuai.Wu@...driver.com>,
	"Tao, Yue" <Yue.Tao@...driver.com>
Subject: Re: in kernel 2.6.x, tun/tap nic supports vlan packets

On Thu, 2014-04-17 at 07:02 +0200, Willy Tarreau wrote:
> Hi Zhu,
> 
> On Thu, Apr 17, 2014 at 11:35:58AM +0800, zhuyj wrote:
> > Hi, all
> > 
> > In kernel 2.6.x, linux depends on nic vlan hardware acceleration to 
> > insert/extract
> > vlan tag.

This is a gross overstatement.

The problem I know of is that prior to Linux 2.6.37 the RX path behaved
differently for VLAN-tagged packets depending on whether they were
extracted by the driver/hardware.

If you put a bridge (or bond) and VLAN device on top of a single
physical device that doesn't do VLAN tag extraction, the VLAN device
didn't get any packets because the bridge packet handler was called
first.  Whereas, if the driver called the 'VLAN accelerated' RX path,
the VLAN packet handler was called first.  (Linux 2.6.37 actually
standardised on the former behaviour, and 3.2 fixed it to be the
latter.)

I don't know whether that's the problem zhuyj has run into.

[...]
> Well, 2.6.32.x is in deep freeze mode and it receives only critical fixes
> once in a while. While I can appreciate that the patch above might solve
> the issue you're facing, I'm wondering if there are not any acceptable
> workarounds for such a deep freeze kernel. You patch is not huge,

I think it's huge by the standards of 2.6.32.y.

> but it
> definitely affects a working driver, and I wouldn't like risking to break
> the tap driver for other users, and I reall don't have the skills to audit
> it completely to ensure this is not the case. And if it breaks, I'll have
> to revert it or seek for some help on netdev.
> 
> So I'd say that I'd rather not merge it unless I get an Acked-by from some
> netdev people who are willing to help in case of any future regression,
> which is unlikely but still possible.
[...]

For what it's worth, I would recommend against applying this.  I don't
think even Red Hat has backported the VLAN changes, and they have been
quite aggressive about backporting features to RHEL 6.

Ben.

-- 
Ben Hutchings
Beware of programmers who carry screwdrivers. - Leonard Brandwein

Download attachment "signature.asc" of type "application/pgp-signature" (812 bytes)