This is to prepare for splitting out the method for pinning a prog.
Bug: 428792764
Flag: EXEMPT logging only change
Test: TH
Change-Id: Iedfc8f3941f8e8b0e70e4dfbc47520b29d332c3e
This is to prepare for splitting out the method for pinning a map.
Bug: 428792764
Flag: EXEMPT logging only change
Test: TH
Change-Id: Iebaeea3150a99e85c25bb106e74ce3fc7f9ddb50
This updates the BPF map macros so programs can be loaded by both the
existing code and the libbpf.
The macros now generate ".maps" section in addition to the
".android_maps" section.
To prevent name collisions, the legacy map definitions are suffixed with
_def. This CL also adds the readMapNames method to get map names from
the ".android_maps" section, allowing the existing code path to continue
working.
Bug: 428792764
Flag: EXEMPT no-op
Test: TH
Change-Id: Ibe6f100b5684bc85d2cf9c100f2431740fa516ca
The reuse boolean was set to true only in a code path that
immediately called abort().
Bug: 428792764
Test: TH
Flag: EXEMPT no-op
Change-Id: I157e9f09c87eedc82c24d4ec821dcb132a389e31
This is a no-op because the data in the ".android_maps"/"progs" section
is an array of struct bpf_map_def/bpf_prog_def.
Test: TH
Flag: EXEMPT no-op
Bug: 428792764
Change-Id: I80bd8c72c68b5359cf1b16ed5d4739a854169d7f
These tend to be huge (because they can contain the full bpf disassembly)
but not very worthwhile, because they often result in logs being rate
limitted, and thus we miss out on the useful information.
This is particularly true for user builds on non-Google devices
installing the production signed tethering apex mainline module.
We're better off seeing more of the other log lines...
Test: TreeHugger
Flag: EXEMPT mainline
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: Ie25a60c2e602772ab0de2050e7964f0202ff2685
Maciej Żenczykowskicommited 2025-07-15 15:00:25 -07:00
Not needed any more, since no more loader vs .o version skew.
Test: TreeHugger
Flag: EXEMPT mainline
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I6c0b9ff2683809f3e732ec950bc91cf87040642f
Maciej Żenczykowskicommited 2025-07-15 14:46:10 -07:00
For libbpf compatibility we will want to have a 'normal' looking
.maps section & an android-only .android_maps section.
Test: TreeHugger
Flag: EXEMPT mainline
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I9114d27c408cb084626ec1151826ae722797296f
Maciej Żenczykowskicommited 2025-07-15 14:43:49 -07:00
This is not needed, as this is now simply hard coded (along with the
.o names themselves) inside of NetBpfLoad.cpp itself - see loadAllObjects().
Even if it wasn't, we're better off using the per-map & per-program
limits instead. These will already cause all maps/programs to be skipped...
(The only reason to have a global per .o one was to solve
.o vs loader version skew issues, which we can no longer have)
Test: TreeHugger
Flag: EXEMPT mainline
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I8e8f62ed3534d54dd3382df53637f76bb72dab5e
Maciej Żenczykowskicommited 2025-07-15 14:40:11 -07:00
Flag: EXEMPT mainline
Test: Boot on 4.14 and BTF is disabled
Test: Boot on 4.19 and BTF is enabled
Bug: 429278733
Change-Id: Icdb85891c3d70f1f1949c5b6f5f82ed6bb862873
This is an array of two ints:
- index 0 should have value 0
(a value of 1 implies a kernel uapi bug)
- index 1 should have value 123
(a value of 0 implies bpf array writes at non-zero index fail)
Note that these bugs can only be present on Android S & Sv2,
as these kernel bugs are considered fatal on Android T+.
(btw. we need to do this write manually as we cannot write into
maps we pin and then reopen - due to sepolicy)
Test: TreeHugger
Flag: EXEMPT mainline
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I9b2ada7f3e299014d39461a8d0718396daf0c91a
Maciej Żenczykowskicommited 2025-06-17 01:49:23 -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
We sometimes see issues when trying to load BPF maps, it's helpful to know
what errno was set.
Bug: 414570528
Test: TreeHugger
Flag: EXEMPT mainline
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I8b78ee17ebad076d073d50bfd0f01440fe7187a2
Maciej Żenczykowskicommited 2025-05-29 01:25:26 -07:00
`ignore_on_*` directives haven't been used in a while and require a special version of bpfloader. Remove them.
While doing so, pad the `map_def` and `prog_def` structs, to maintain existing size.
Note: The mainline shipped bpf .o files are now in a location
that no platform bpfloader ever looked/looks at.
As such maintaining .o format compatibility with older release
is not needed.
Test: TreeHugger
Flag: EXEMPT dead code removal / mainline
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I485c9645bdece2ad27add08347688d0f1c93e5d2
Maciej Żenczykowskicommited 2025-05-20 15:02:15 -07:00
should be unused
Test: TreeHugger
Flag: EXEMPT dead code
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: Ice72d940dd3492d2b9e14dd32390a49f87bd54d1
Maciej Żenczykowskicommited 2025-05-20 08:45:15 -07:00
This is to identify if it actually happens.
It is expected not to happen, because we now pin every map and are run only once on boot.
Test: TreeHugger
Flag: EXEMPT dead code
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: Ie46ace40f20fb4b061a91cd53f8256caebdfa71f
Maciej Żenczykowskicommited 2025-05-20 06:41:18 -07:00
This code should be dead. Abort to see whether it is.
Test: TreeHugger
Flag: EXEMPT dead code
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: Ib5309ff683339e70bc44e135578ede75548b022d
Maciej Żenczykowskicommited 2025-05-20 06:38:57 -07:00
This is basically a no-op as 32-bit netd already fails on android-mainline @ 6.13 (we're now at 6.14, 6.15 is coming in a few weeks).
I know this because we had to fix ACK 6.12, and didn't port it forward.
Note: AFAIK TV is planning to release on 25Q2 and then 27Q2,
so this 26Q2+ doesn't actually affect them till a year later in 27Q2.
Modern arm cores are dropping 32-bit cpu instruction decode support.
This already happened on Pixel 8+ (Tensor G3+) and is soon coming
to the GCE cloud machines underpinning our cuttlefish VMs
(this is very much an industry wide trend for modern aarch64 cores,
I believe all new application cores since 2023 have been 64-bit only).
Pixel 6a is AFAIK the last pixel with 32-bit application support,
and that is reaching EOL approximately in July 2027.
(while most test coverage is on Pixel 6/6pro which EOLs in Oct 2026)
Note though that this isn't a great example: AFAIK all Pixels
have had 64-bit system userspace (which is what we care about here)
The transition happened in the final Nexus, the year before Pixel 1.
This means we're going to start losing *any* remaining vestiges
of test coverage that we still (might) have.
Test: TreeHugger
Flag: EXEMPT mainline
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: Ie8a5a5dafd2f0e20ef4651c3a69957fde374ae4b
Maciej Żenczykowskicommited 2025-05-17 06:00:03 -07:00
The full set of 5 .o's is known at build time, and basically almost
never changes (and indeed is likely to shrink, with clatd.o merged
into offload.o && dscpPolicy.c merged into netd.c).
We might as well just code this knowledge straight into the mainline
loader.
This also allows us to move all the files to an apex subdirectory
that old platform bpfloaders don't even look at, which eliminates
the need for any backward compatibility with them.
Test: TreeHugger
Flag: EXEMPT mainline
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: Ie3d27178c31a68ed7cf5173b5983ad3009a3cf94
Maciej Żenczykowskicommited 2025-05-15 01:38:16 -07:00
Netd bpf requires 5.10 at least in 25Q4.
This CL enforces that.
Test: TreeHugger
Flag: EXEMPT mainline
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I76e52b2a2702a2a6ce761a947a0749ea798778b6
Maciej Żenczykowskicommited 2025-05-06 05:28:23 -07:00
Since all mainline bpf code is now loaded by NetBpfLoad, compatibility with platform bpfloader simply doesn't matter any more.
Test: TreeHugger
Flag: EXEMPT mainline
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: Id96e3e6a4dac485f3e707cc9e6c4b05a4f9389d7
Maciej Żenczykowskicommited 2025-05-06 02:59:51 -07:00
Add 25Q3, 25Q4, 26Q1 and 26Q2 SDKs to the bpfloader helpers. The Q3 and
beyond versions are not finalized, so they are not being populated in
BpfUtils.h yet, but at least the logic is in place.
Test: TreeHugger
Flag: EXEMPT test code
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I6ea12e347462be2c8258a4fe5bc994b35d4065a5
Maciej Żenczykowskicommited 2025-05-06 02:55:33 -07:00
The lambda was capturing btf by value instead of reference. This meant
that btf__free was never called, because at the time of capture btf was
null.
This changes the lambda to capture btf by reference instead of by value.
Test: TH
Flag: EXEMPT mainline
Bug: 411323352
Change-Id: I6c6637b10f16d48f9ae5b702e44883046b46e252
This code requires
!isArm()
isUserspace32bit()
isAtLeastKernelVersion(6, 7, 0)
which implies
isAtLeastKernelVersion(6, 2, 0)
meaning we match the condition in 1801,
and don't match the isArm() conditions in 1803/1806/1810,
thus we'd have already 'returned 1' in line 1815.
Test: TreeHugger
Flag: EXEMPT mainline
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I234ba91b9bdbfeaf1077eac64248d3ebfe2f2cd2
Maciej Żenczykowskicommited 2025-04-15 13:48:19 -07:00
BTF_KIND_VAR and BTF_KIND_DATASEC were introduced in 5.2.
It should be possible to enable BTF on 4.18 or above since libbpf can
load BTF.
Also, current code should work on 5.4 but this is untested.
For now, this CL enables BTF on 5.10 or above.
Test: boot on 4.9, 4.19, 5.10
Test: adb logcat | grep NetBpfLoad
Change-Id: I3da4970464afcf9a76b1f2645ed79c44750bcd6a
Since btf is declared in inner scope, btf is null in outer scope and BTF
was always disabled.
This CL also makes NetBpfLoad buildable with -Wshadow flag
Test: adb log | grep NetBpfLoad
Change-Id: I511f21a3620ccfdadd797786e087d0d142c816ed
Motomu Utsumi
commited 
Maciej Żenczykowski
commited 
Elliott Hughes
commited 
Android (Google) Code Review
commited 
Treehugger Robot
authored and
Patrick Rohr
commited 
Gerrit Code Review
commited