It turns out this doesn't work anyway:
Both our Java and C++ higher level map opening logic on 4.14+
kernels will check key/value sizes match, which will fail due to
the kernel uapi mismatch.
(Note: that the fixup was only ever applied/enabled inside of
the NetBpfLoad process itself, not in any later .so/Java/JNI)
This removes the fixup and simply chooses to not even attempt to
load bpf. This will result in the mainline bpf provided
maps and programs simply not existing. This would/will cause
a failure of 'bpf_existence_test' - but who cares, so long
as things keep on booting.
We need to transition to libbpf, and clearly making this work
isn't worth the considerable effort it would be, since S ebpf
functionality (ie. tethering offload) hasn't worked on the
affected devices in years.
Test: TreeHugger
Flag: EXEMPT mainline
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: Ic93a5a9d5b3ba8078500e20dfdf00ef68256874c
Maciej Żenczykowskicommited 2025-09-11 13:01:01 -07:00
See https://b.corp.google.com/issues/414570528#comment96
which can be summarized as
https://github.com/MiCode/Xiaomi_Kernel_OpenSource/blob/vayu-r-oss/include/uapi/linux/bpf.h has:
enum bpf_cmd {
BPF_MAP_CREATE, <-- UAPI 0
BPF_MAP_LOOKUP_ELEM, <-- UAPI 1
BPF_MAP_UPDATE_ELEM, <-- UAPI 2
BPF_MAP_DELETE_ELEM, <-- UAPI 3
BPF_MAP_GET_NEXT_KEY, <-- UAPI 4
BPF_PROG_LOAD, <-- UAPI 5
BPF_OBJ_PIN, <-- UAPI 6
BPF_OBJ_GET, <-- UAPI 7
BPF_PROG_ATTACH, <-- UAPI 8
BPF_PROG_DETACH, <-- UAPI 9
BPF_GET_COMM_HASH, <-- breaks Linux uapi (uses 10)
BPF_PROG_TEST_RUN, <-- UAPI 10 becomes 11 (aka. BPF_PROG_RUN)
BPF_PROG_GET_NEXT_ID, <-- UAPI 11 becomes 12
BPF_MAP_GET_NEXT_ID, <-- UAPI 12 becomes 13
BPF_PROG_GET_FD_BY_ID, <-- UAPI 13 becomes 14
BPF_MAP_GET_FD_BY_ID, <-- UAPI 14 becomes 15
BPF_OBJ_GET_INFO_BY_FD, <-- UAPI 15 becomes 16
};
this addition in the middle of the userspace api enum,
causes all following enum values to be greater by one.
In particular this increases the value of
BPF_OBJ_GET_INFO_BY_FD from 15 to 16, thus break it.
It also causes UAPI 12 (BPF_MAP_GET_NEXT_ID)
to actually execute BPF_PROG_GET_NEXT_ID (normally UAPI 13)
As such this can be detected via finding the index of
the last map (on buggy kernels this will actually find
the index of the last program), then creating a map,
then checking if the last map index has changed
(on buggy kernels this will not be the case because
we did not create another program).
Bug: 414570528
Test: TreeHugger
Flag: EXEMPT mainline
Change-Id: Iecad121ac624df2d123a13e90a46792bd567a4c6
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Maciej Żenczykowskicommited 2025-06-10 02:43:28 -07:00
Programs of type raw_tp need the input to be passed in the ctx
instead of the data.
Test: with ag/33648187
Change-Id: I79ac0126d91c9eafd847a0c8709a47a0113a9430
(shot in the dark)
checking attr.info.info_len in line 265 could probably be optimized out if we pass by const reference, since one could assume it is still sizeof(info).
Bug: 414570528
Flag: EXEMPT mainline
Test: TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I1e5ba472042ecce0260f2e3b60a0a88095734f8d
Maciej Żenczykowskicommited 2025-05-29 02:43:55 -07:00
Available in Linux Kernel 4.14+
Test: TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I3e5a43ceece5826fc6019bd11df2bc5315fe405c
Maciej Żenczykowskicommited 2025-02-14 11:12:31 -08:00
Step 3 of moving bpf related stuff into a common directory,
will ease development.
Test: TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I9ec90e2f58c68e17d6e83b48b8dea2cdf31a3694
Maciej Żenczykowskicommited 2024-08-20 19:51:50 -07:00
Maciej Żenczykowski
commited 
Alessio Cosenza
commited 
Patrick Rohr
commited