netdev - Re: Receiving raw packets (incl. VLAN tags) on raw sockets

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] [day] [month] [year] [list]

Date:   Wed, 14 Jun 2017 11:54:25 -0500
From:   ebiederm@...ssion.com (Eric W. Biederman)
To:     Jan Grashöfer <jan.grashoefer@...il.com>
Cc:     netdev@...r.kernel.org, aeppert@...il.com
Subject: Re: Receiving raw packets (incl. VLAN tags) on raw sockets

Jan Grashöfer <jan.grashoefer@...il.com> writes:

> On 14/06/17 16:41, Eric W. Biederman wrote:
>> That does not work.  That is is just the software fallback for when
>> the device driver does not have a special case the processing
>> vlan tagged packets.
>>
>> There was a major inconsistency that for a long time the hardware
>> network drivers were stripping tags and the software ones were not.
>>
>> The code you are playing with is the fix for the rare slow path
>> that does not happen to strip the tags.  Disabling the rare slow path
>> might temporarily solve your symptoms but it will be much more painful
>> when you are entrenched in your ways and discover that high performance
>> hardware behaves differently than your software device.
>
> Thanks for your reply! Actually, I was referring to COTS hardware that
> incorporates offloading features. But, when it comes to (security)
> monitoring, offloading is usually disabled [1,2] to process the
> packets as seen on the wire. Thus the "slow path" would be the default
> path for most monitoring applications. That is, what makes this
> situation kind of weird. After turning off the NIC's VLAN offloading,
> it took me some time to realize that now the kernel strips off VLAN
> tags. If someone decides that VLAN offloading is not needed, I think
> the kernel should not enforce it.

In practice it is too too complicated to support both so we choose the
mode where vlan tags are always stripped.

I can imagine a tweak to pf_packet where it readds the vlan tag before
it gets to user space.  I can not image changing how we treat the vlan
tags internally to the kernel.

There were nasty kernel bugs before: 
bcc6d4790361 ("net: vlan: make non-hw-accel rx path similar to hw-accel")

I don't even want to contemplate opening that can of worms again.

Eric