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 PHC | |
Open Source and information security mailing list archives
| ||
|
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
Powered by blists - more mailing lists