netdev - Re: [PATCH 1/3] vlan: Do not support clearing VLAN_FLAG_REORDER

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 for Android: free password hash cracker in your pocket

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

Date:	Mon, 23 May 2011 15:05:54 -0700
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	David Miller <davem@...emloft.net>
Cc:	shemminger@...ux-foundation.org, greearb@...delatech.com,
	nicolas.2p.debian@...il.com, jpirko@...hat.com, xiaosuo@...il.com,
	netdev@...r.kernel.org, kaber@...sh.net, fubar@...ibm.com,
	eric.dumazet@...il.com, andy@...yhouse.net, jesse@...ira.com
Subject: Re: [PATCH 1/3] vlan: Do not support clearing VLAN_FLAG_REORDER_HDR

David Miller <davem@...emloft.net> writes:

> From: Stephen Hemminger <shemminger@...ux-foundation.org>
> Date: Mon, 23 May 2011 14:00:48 -0700
>
>> IMHO the REORDER_HDR flag was a design mistake. It means supporting
>> two different API's for the application. For a packet capture application
>> it means the format of the packet will be different based on how
>> the VLAN was created. And the vlan was created outside the application.
>> 
>> If there was a requirement to support both formats, then it should
>> be a property of the AF_PACKET socket.  The application can then do
>> an setsockopt() to control the format of the data. The issue is
>> for things like mmap/AF_PACKET the re-inserted form will be slower
>> since data has to be copied.
>
> Indeed, it was a foolish thing to support in the first place.
>
> I guess we couldn't see the hw offloads in the future at that
> point.
>
> I'm all for finding a way to deprecate this over time.

There are two very similar issues here, that affect two
slightly different cases.

Let's assume the configuration is:
eth0 - Talks to the outside world.
vlan2000 - Is the vlan interface of interest.

With REORDER_HDR set when I tcpdump on vlan2000 I don't see the
vlan header, however I continue to see the vlan header when I tcpdump on eth0.

With vlan hardware acceleration.  When I tcpdump on eth0 I don't
see the vlan header.  Nor do I see the vlan header when I tcpdump
on vlan2000.

Right now both cases are problematic in Linus's tree.

For inbound packets We are testing the wrong interface for the to see if
we should play with REORDER_HDR.

Hardware acceleration vlan tagging we are hiding the vlan header from
portable applications that simply dump eth0.  Which is non-intuitive
and apparent to everyone now that this happens on both software and
hardware interfaces.

So we have a couple of questions.
1) Do we revert the software emulation of vlan header tagging to fix
   it's implementation issues in 2.6.40?

   The big issues.
   - vlan_untag is currently reading undefined data.
   - Clearing REORDER_HDR no longer works.

   I expect the issues are small enough that we can address them now.

2) Do we instead move the software implementation of vlan header
   acceleration back into the net-next.

3) What do we do with pf_packet and vlan hardware acceleration when
   dumping not the vlan interface but the interface below the vlan
   interface?

   Do we provide an option to keep the vlan header?  Should that option
   be on by default?

Eric
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html