NetBpfLoad: workaround for Xiaomi kernel uapi bug
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>
2 files changed
