netdev - Re: [PATCH net-next v2] net: filter: add insn for loading internal transport header offset

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, 5 May 2014 11:42:00 -0700
From:	Chema Gonzalez <chema@...gle.com>
To:	David Miller <davem@...emloft.net>
Cc:	Eric Dumazet <edumazet@...gle.com>,
	Daniel Borkmann <dborkman@...hat.com>,
	Alexei Starovoitov <ast@...mgrid.com>,
	Network Development <netdev@...r.kernel.org>
Subject: Re: [PATCH net-next v2] net: filter: add insn for loading internal
 transport header offset

On Fri, May 2, 2014 at 7:52 PM, David Miller <davem@...emloft.net> wrote:
>> Once you get the L3 proto and noff/toff, you get everything. The
>> rationale of adding toff/noff is that it's very similar to poff, which
>> we already have.
>
> But you're implementation is calling a function to do all of that work
> already, just to get only the transport header and then throwing away
> all of the other useful bits that function is calculating, so you'll
> end up doing it twice which is wasted work.
The problem here is that (classic) BPF works only with 2 registers. We
need at least 2 fields to get a valid point in the packet, namely the
offset and the protocol of the inner-most header (either L3 or L4).
The idea of this patch is to run the flow dissector twice, once to get
the protocol type, and a second to get the offset (this patch
implements the offset part of the L4 header). This is 2 calls, but it
provides flow dissection inside BPF.

I guess we could have this call return 2 values, one in A, the other
in X. This is strange in BPF, but we could do it (and then the user
should probably push one of the values right away if she wants to use
it later). Does it sound good?

> We can probably add an extension to AF_PACKET which provides the flow
> key at the end of the tpacket3_hdr if a certain socket option is set.
>
> That would provide the transport header as well as a side effect, and
> be much more powerful and efficient than this particular BPF
> instruction.
I'm not sure whether I follow this. The goal is to be able to access
the inner-most headers inside BPF, not in userland by calling
getsockopt().

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