netdev - Re: [PATCH] filter: introduce SKF_AD_VLAN

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]

Message-ID: <20150305092330.GC25656@unicorn.suse.cz>
Date:	Thu, 5 Mar 2015 10:23:30 +0100
From:	Michal Kubecek <mkubecek@...e.cz>
To:	Guy Harris <guy@...m.mit.edu>
Cc:	Jiri Pirko <jpirko@...hat.com>,
	Alexei Starovoitov <ast@...mgrid.com>,
	Michal Sekletar <msekleta@...hat.com>, netdev@...r.kernel.org
Subject: Re: [PATCH] filter: introduce SKF_AD_VLAN_PROTO BPF extension

On Thu, Mar 05, 2015 at 12:35:01AM -0800, Guy Harris wrote:
> 
> On Mar 4, 2015, at 11:24 PM, Michal Kubecek <mkubecek@...e.cz> wrote:
> 
> > To be more precise, it does not need it now as there is no syntax for
> > pcap filter on TPID,
> 
> In the current version of libpcap (and the commit dates back to November
> 2011), the filter "vlan" checks both for 0x8100 and 0x9100

Actually, there are four different pieces of code:

  - userspace checking packet contents
  - userspace checking packet metadata
  - kernel BPF checking packet contents
  - kernel BPF checking packet metadata

As far as I can see, only the BPF generated to check packet contents
does check TPID value, BPF checking metadata does not (neither in kernel
nor in userspace).

> (it should perhaps also check for other TPID values), in userland and
> in the kernel on platforms other than Linux, as the generated code
> checks for both values.
...
> (I presume that one can, from the data delivered to a PF_PACKET
> SOCK_RAW socket, reconstruct the packet as received, with all the VLAN
> tags in place in the packet just as they were when the packet hit the
> adapter's transceiver from the network.  If not, that's a *separate*
> deficiency.)

These two issues were addressed by

  https://github.com/the-tcpdump-group/libpcap/pull/351

but the code changed since then so I'll have to check the changes and
create a new pull request.

                                                       Michal Kubecek

--
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