Vendor/OEM reports of some of their code failing to build due
to larger key/value sizes.
I'd make this check mainline only, but I can't seem to find
a way to actually make that (reliably) work.
So let's just lower the minimum from 256 to 64 - this should
I think still be enough for significant performance benefits
from using bulk operations. Indeed probably even 10 would be
enough for that.
Bug: 442996907
Test: TreeHugger
Flag: EXEMPT mainline/trivial
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I69d53293dd5bb2174af7c814f531a08eba590310
Maciej Żenczykowskicommited 2025-09-11 13:01:08 -07:00
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
by joining two log lines into one with effectively the same info
(the kernel version is already printed during startup)
Test: TreeHugger
Flag: EXEMPT mainline / logging
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: Ide066edf2d54ffd6a61fdcb115a249bff80cdff9
Maciej Żenczykowskicommited 2025-09-11 11:34:49 -07:00
libbpf ignores BTF load error but this causes boot failure only when BTF
is required for some reasons (e.g. SK_STORAGE).
This CL makes boot fails regardless of the necessity of BTF on 4.19+
kernel
Test: boot kernel on 4.14, 4.19, 5.10, 6.1
Flag: EXEMPT mainline
Change-Id: I0af1e7eedcbea803c22c064ff157700a01307691
The symbol name of a static const variable defined within a function
includes a '.' and old kernel BTF ferifier rejects it.
"""
08-29 15:11:27.825 0 0 W : c3 1287 NetBpfLoad: [377] STRUCT _rodata size=64 vlen=3
08-29 15:11:27.825 0 0 W : c3 1287 NetBpfLoad: tcp_option type_id=343 bits_offset=0
08-29 15:11:27.825 0 0 W : c3 1287 NetBpfLoad: schedcls_ingress_accecn_eth_.new_cnt type_id=346 bits_offset=128 Invalid name
"""
This verifier limitation was relaxed in later kernels by
https://lore.kernel.org/bpf/20230615145607.3469985-1-revest@chromium.org/
Test: Boot on 4.19 kernel && logcat
Bug: 440448408
Bug: 442710894
Flag: EXEMPT tcpAccECN program is not used
Change-Id: If3c993bb6abb1ff8688932d682d909d335f84ca2
Motomu Utsumiauthored and Maciej Żenczykowskicommited 2025-09-04 04:50:13 -07:00
Before this CL, if the ip_ecn is 0b11, program returns without updating
byte_count->ceb
Test: TH
Bug: 440448408
Flag: EXEMPT tcpAccECN program is not used
Change-Id: I37aeddcb6807c43787b4f3ca0db26f47ffe190df
Likely not needed for kernel verifier happiness,
since even 1 'static' constant prevents .rodata from being
entirely empty/automatic and thus BTF-less.
Trivial follow up to go/ag/35341088
Bug: 441356399
Bug: 441436401
Test: TreeHugger
Flag: EXEMPT mainline/bug fix
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I396d1a4f2d47225707348f7c7dc3548cbba125a0
Maciej Żenczykowskicommited 2025-08-27 23:01:24 -07:00
Appear to be failing on pixel 7 U (which is 5.10)
Flag: EXEMPT mainline
Test: TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I12d70659a994fd2a9f57597fd4aaa1aea6bbe1c7
Maciej Żenczykowskicommited 2025-08-27 13:06:28 -07:00
As of M-2025-11 mainline is only being pushed to S+
Test: TreeHugger
Flag: EXEMPT test only
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: Id0cf9d2cce27fb90ce076fcdd0f6ee0a95ea9741
Maciej Żenczykowskicommited 2025-08-26 09:56:45 -07:00
This CL also sorts bpf targets in Android.bp
Test: m
Bug: 440448408
Flag: EXEMPT tcpAccECN is not used
Change-Id: I4a662870333f3da02d4d6cfcb3fca8c0af452d34
bpf_helpers.h has the same definitions
Test: m tcpAccECN.o
Bug: 440448408
Flag: EXEMPT tcpAccECN is not used
Change-Id: Ie5b47bdcbc2aa8d4563cf3ec0806f8dfc6861801
This CL also sets the min kver to 5.10.
skb_tcp_flags field in bpf_sock_ops was introduced on 5.10 kernel
Test: TH
Bug: 440448408
Flag: EXEMPT tcpAccECN is not used
Change-Id: I71696e0bf3b36296c5f2e7fd5b692406d96ddf97
CRITICAL section was removed by ag/33605170
Test: TH
Bug: 440448408
Flag: EXEMPT tcpAccECN is not used
Change-Id: I6de89edd7547ede1ecdd18b5ee80fb9bc1977915
$ sed -i 's/\r$//g' bpf/progs/tcpAccECN.c
$ sed -i 's/\r$//g' bpf/progs/tcpAccECN.h
Test: TH
Bug: 440448408
Flag: EXEMPT tcpAccECN is not used
Change-Id: Iffde87607e95920dc839e6901e0ba40912f83a49
netd_updatable was added during T mainline effort.
Test: TreeHugger
Flag: EXEMPT mainline
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I095cbe3a8dc75a47fca9489965a0b922ede56a8e
Maciej Żenczykowskicommited 2025-08-18 15:59:14 -07:00
Not clear what the true minimum for this should be...
30/R? 31/S? 33/T?
So let's just err on the side of 30/R for now.
Bug: 439218498
Test: TreeHugger
Flag: EXEMPT mainline
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: Iebc28671f0b6fb5b33bf943fcccb3c4f836a92e6
Maciej Żenczykowskicommited 2025-08-18 15:18:35 -07:00
Should fix observed failure on a Xiaomi S device with 4.19 kernel:
I NetBpfLoad: NetBpfLoad v0.42 (/apex/com.android.tethering/bin/netbpfload) api:31/31 kver:413009d (64-on-aarch64) libbpf: v1.4 uid:1000 rc:10
I NetBpfLoad: Tethering APEX version 360911260
E NetBpfLoad: bpfGetNextMapId(final 15) returned 0 errno 2
W NetBpfLoad: Enabling bpfCmdFixupIsNeeded.
...
W NetBpfLoad: libbpf: BTF loading error: -2
E NetBpfLoad: btf__load_into_kernel failed, errno: 2
E NetBpfLoad: Failed to create maps: (ret=-2) in /apex/com.android.tethering/etc/bpf/mainline/offload.o
E NetBpfLoad: Failed to load object: /apex/com.android.tethering/etc/bpf/mainline/offload.o, ret: No such file or directory
E NetBpfLoad: === CRITICAL FAILURE LOADING BPF PROGRAMS ===
(errno 2 is ENOENT)
Bug: 438099891
Test: TreeHugger
Flag: EXEMPT mainline
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I07eea956fe6b862c68d3679dbd9eac81bec05e71
Maciej Żenczykowskicommited 2025-08-18 12:56:44 -07:00
Corrected the comment in Android.bp regarding the target SDK version. In NetBpfLoad.cpp, added specific handling for RiscV builds to account for its undefined minimum API level. Added an error to ensure NetBpfLoad is always compiled within an APEX. Clarified that `minSupportedKernelVer` must be 0 for APEX builds to enable runtime kernel version enforcement.
Bug: 438908493
Test: TreeHugger
Flag: EXEMPT mainline
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: Ie3affbfd702ff1f6d5f2887b6f56ade0ed7fb5dd
Maciej Żenczykowskicommited 2025-08-15 14:58:10 -07:00
We're adding a lot of 'isAtLeastKernelVersion(x,y,z)' checks,
that would ideally compile time optimize out whenever possible.
Note: we should be able to bump the '__ANDROID_API__ == 30' assert
in NetBpfLoad to 31/S any day now, since technically tip-of-tree
only goes into M-2025-11 which requires S. But none of the
prep work for that is ready yet.
Test: TreeHugger
Flag: EXEMPT mainline
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I4d9a7916833f086cd36011e094005999fe770583
Maciej Żenczykowskicommited 2025-08-14 20:10:43 -07:00
Uses 16KiB ram, only caches ifindex < 1024, but in practice
that should usually be the case, as these are assigned
in sequential order by the kernel.
Note that in progs/netd.c:86 we have:
DEFINE_BPF_MAP_NO_NETD(iface_index_name_map, HASH, uint32_t, IfaceValue, 1000)
so stuff doesn't really work right once we go past 1000-ish
tracked interfaces...
(and worst case we're no worse off then we are now...)
Benefit should be significant as all our bpf map stats
dumping logic has to convert from ifindex to ifname
in order to strcmp against the interface we're trying to match,
ie. that's the first thing 3 of the 4 cases we support
do at the very top of their innermost loop.
This effectively eliminates 1 bpf() lookup systemcall, thus
getting us down to 2 (getNextKey + readValue/readValueAndDelete)
Note: the tests work because they're consistent in how they
map ifindex/ifname so they do not require cache clearing.
I believe we don't have to worry about threading, as
we're being called while traversing/consuming maps.
Thus I believe there must be locking external to us.
Also writes should be *super* uncommon, so even if this
were to run multithreaded, races should happen very rarely.
If they did, we'd just write in the same value twice (since
the mapping from ifindex->ifname should rarely if ever change)
Worst case once in a blue moon we'd fail to match an interface
that had *just* shown up (because of reading only half the name),
and we'd lose some stats...
(and since the entire value fits in 16 bytes, and thus in a single
cache line, in practice most cpus will probably write combine
and thus avoid a half write/read anyway, both x86-64 and aarch64
can potentially even do a 16-byte read/write in 1 instruction...
although unclear if that will happen, but worst case should be 2)
Test: TreeHugger, atest libnetworkstats_test
Flag: EXEMPT mainline
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I0d3ea6c5f1f2945adccd479af6c65008bf7d7c51
Maciej Żenczykowskicommited 2025-08-12 20:39:20 -07:00
To support L4S receiver functionality on TCP connections, AccECN
is implemented using eBPF programs. Eth and rawip packets are
handled by separate pairs of ingress and egress programs.
(cherry picked from https://partner-android-review.googlesource.com/q/commit:075c29658a91da2b0e9d36d871bd2403b74a4f69)
Flag: EXEMPT tcpAccECN is not used
Change-Id: Ib0a11880b3f2b1ea04e188fe33366cae9eabe898
k1.reddyauthored and Maciej Żenczykowskicommited 2025-08-12 18:44:01 -07:00
In practice this is already the case... If uname() execution
fails, or we fail to parse the result, we won't pass the
4.9+ required check in NetBpfLoad, which is required on S+,
and mainline no longer supports anything <S anyway.
We don't require subversion as technically "4.9" (ie. 4.9.0)
is enough for almost all usecases, although in practice I would
expect there will always be an LTS subversion present.
Test: TreeHugger
Flag: EXEMPT mainline
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I66a5eba5c7bcf9bd51997db93c0fefc8104945eb
Maciej Żenczykowskicommited 2025-08-11 21:27:04 -07:00
(this was basically an oversight, nothing should be setting this)
Test: TreeHugger
Flag: EXEMPT mainline
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I6e36d9cb7522272e4a725e77b630b43cb6a1494d
Maciej Żenczykowskicommited 2025-08-11 20:58:15 -07:00
Maciej Żenczykowski
commited 
Motomu Utsumi
commited 
Android (Google) Code Review
commited 
Jimi Chen
commited 
k1.reddy
authored and