[PATCH] net: bpf_jit: Document evilness of negative indirect loads

[Indan Zupancic]

On Sun, March 18, 2012 23:40, Eric Dumazet wrote:
> Le dimanche 18 mars 2012 Ã 19:35 +1100, Indan Zupancic a Ãcrit :
>
>> And in the 00.00001% case that the filter uses a computed negative
>> offset the BPF JIT fails at runtime. So to not be buggy you need at
>> least a call to __load_pointer() for the negative case.
>
> Please show me how and why a real (I mean useful one...) filter could
> generate a dynamic negative value, and I'll change the code.
>
>
> Negative values are there to allow access to network/mac header
> components. I cant see how a BPF code could have a valid use of dynamic
> indexes in these headers.

E.g. when poking in a variable length IP header with a filter
attached to a TCP/UDP socket. Still a bit far fetched though.

>
> Right now we consider such code is evil and filter does "return 0"
> saying so.

I'm fine with that, but this should be documented somewhere I think.

Greetings,

Indan


[PATCH] net: bpf_jit: Document evilness of negative indirect loads

Negative offsets are used to access ancillary data. In the case of
SKF_NET_OFF and SKF_LL_OFF users may expect negative indirect loads
to work. If BPF JIT is used then such loads will fail. In any case,
negative indirect loads are considered evil and are not supported.

---

Reported-by: Eric Dumazet <eric.dumazet@xxxxxxxxx>
Signed-off-by: Indan Zupancic <indan@xxxxxx>

diff --git a/include/linux/filter.h b/include/linux/filter.h
index 8eeb205..2bd4bbb 100644
--- a/include/linux/filter.h
+++ b/include/linux/filter.h
@@ -114,6 +114,9 @@ struct sock_fprog {	/* Required for SO_ATTACH_FILTER. */
    We use them to reference ancillary data.
    Unlike introduction new instructions, it does not break
    existing compilers/optimizers.
+
+   Do not expect negative indirect loads to work, they are
+   considered evil.
  */
 #define SKF_AD_OFF    (-0x1000)
 #define SKF_AD_PROTOCOL 0


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/