bpfLock() does nothing on 4.9 as it relies on bpfGetFdMapId which is not available until 4.14.
Change-Id: Ib737db61a5d8fb39bcbbe1bb5937afb0c63bd1d1
Test: TH
Bug: 349034378
This reverts commit 4b28336a7a.
Fixed trivial comment conflicts in netd/BpfHandler.cpp
This is targetting mainline release M-2024-09.
Test: TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I048af33789590dda4e1f0be0660419ca6b3ad57f
Maciej Żenczykowskicommited 2024-06-21 15:47:00 +00:00
This reverts commit 231598bc92.
This is targetting mainline release M-2024-09.
Note: left the failure message in netbpfload/netbpfload.33rc
to mention 'netbpfload-failed' and not 'bpfloader-failed'.
Test: TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: Iaf99360a215b1a74bda457ed55b7f56a5a3f2b48
Maciej Żenczykowskicommited 2024-06-21 15:46:42 +00:00
We adjust and extend the trivial programs on:
{connect,recvmsg,sendmsg}{4,6}
inet_release
{g,s}etsockopt
so that they also work on older kernels.
Bug: 347584126
Test: TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I925b443f77e081f5eeb9be6c133581900a9f943d
Maciej Żenczykowskicommited 2024-06-18 17:55:54 -07:00
Only the non-CRITICAL test@mainline.o is loaded from netbpfload
on T and U < QPR3, everything else is loaded by platform bpfloader
Test: TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: Ic07a57cf93851d3a1411b62c97d8ce057507360b
Maciej Żenczykowskicommited 2024-06-14 15:09:41 -07:00
As requested by Patrick on http://go/aog/3132975
Test: TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: Ie49426c5e8c19bd0329e93c78a0918ca1120f164
Maciej Żenczykowskicommited 2024-06-14 14:27:28 -07:00
We stop calling 'service mdnsd_netbpfload' from libnetd_updatable.so.
To make this work we need to change all bpf .o minimum bpfloader versions
from mainline BPFLOADER_MAINLINE_X_VERSION to non-mainline
BPFLOADER_X_VERSION equivalents (at least for X < U QPR3).
The {offload,test}@mainline.o files are now misnamed, but we leave this be:
- 'mainline' now means 'U+ BTF enabled version',
- S and (official) T use the baseline non-BTF version.
However, there are *some* oem/vendor T's with @ supporting bpfloade,
so they will use the @mainline.o files instead... (this is harmless)
Bug: 335124875
Test: TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: Ibe285aefc315e6cb224450d1487980df3cba0eff
Maciej Żenczykowskicommited 2024-06-14 05:49:17 -07:00
Note that 'true iff U QPR3 or V+' comment is subtle.
netbpfload.35rc runs netbpfload as 'root' uid, so V+ is obvious.
However, netbpfload.33rc runs netbpfload as 'system' uid, so one
would think that this isn't true on T/U.
However the U QPR2 and U QPR3 'service bpfloader' actually run
platform netbpfload, and the U QPR3 platform netbpfload immediately
executes the apex provided netbpfload...
Once the apex netbpfload finishes mainline init is considered
'done', and thus we won't (need to) start service mdnsd_netbpfload.
As a result even on U QPR3, we never run netbpfload as system uid.
Test: TreeHugger
Change-Id: I02661dff07c317394a9d8ba3d48e4cb9cd694fd0
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Maciej Żenczykowskicommited 2024-06-14 05:48:49 -07:00
and add an accessor to grab an exclusive lock on a R/W map open
(such a map could be accessed with a write-through cache)
Note: we can't grab a flock as that would occupy the full inode,
and all bpfmaps are actually (currently) the *same* anonymous inode.
As such we actually grab a lock on a range (a single byte),
the offset being determined by the unique bpf map id.
We include some very simple, but sufficient, correctness tests
in the critical boot path: this is to prevent any surprises
caused by kernel implementation changes.
$ adb root && sleep 1 && adb wait-for-device shell grep OFDLCK /proc/locks
id: OFDLCK ADVISORY [WRITE|READ] pid blkmaj:min:inode min_offset max_offset
11: OFDLCK ADVISORY READ -1 00:0e:1048 36 36
14: OFDLCK ADVISORY READ -1 00:0e:1048 35 35
15: OFDLCK ADVISORY READ -1 00:0e:1048 41 41
16: OFDLCK ADVISORY READ -1 00:0e:1048 40 40
22: OFDLCK ADVISORY READ -1 00:0e:1048 24 24
23: OFDLCK ADVISORY READ -1 00:0e:1048 17 17
24: OFDLCK ADVISORY READ -1 00:0e:1048 16 16
25: OFDLCK ADVISORY READ -1 00:0e:1048 13 13
OFDLCK probably means 'Open File Descriptor LoCK' since an OFDLCK
is associated with (held by) the file descriptor and not a process/pid,
on the given (anonymous in this case) block device + inode.
Where READ=shared and WRITE=exclusive.
There are (as yet) no exclusive locks held post boot.
The pid field is unfortunately always -1 (and cannot be manually set).
The 00:0e:1048 (or at least the inode portion) is random
(likely depends on boot ordering)
The final two fields (min and max offset) are the bpf map id.
Test: TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I208e3450da3fe4689ad5fd578539f401f25a4fef
Maciej Żenczykowskicommited 2024-06-14 10:51:25 +00:00
(perhaps a clearer name, especially once we switch what this does)
Test: TreeHugger
Change-Id: I99c811fc357ab0bb3b4065658c9e5e4733689728
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Maciej Żenczykowskicommited 2024-06-13 15:26:55 -07:00
Mainline netbpfload is mandatory on V+, so it matters little
whether we perform the checks in it, or in BpfHandler
(which runs as part of netd startup via libnetd_updatable.so),
and this avoids the need to reimplement isTV() opt-out.
Bug: 333970930
Test: TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I599f2c9d6710f0caa2cd71f0946459d43ddbfc17
Maciej Żenczykowskicommited 2024-06-02 22:28:35 +00:00
BpfHandler.cpp is only used (along with NetdUpdatable.cpp)
by libnetd_updatable.so
There is no good reason for there to be two different tags...
It just makes filtering logs annoying
(since you need to filter on both).
Test: TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: Ia1dc1c99c624180e29c2f42f09c55ca48137b3c2
Maciej Żenczykowskicommited 2024-05-20 12:52:15 -07:00
(for now for better testing we don't make V special)
Test: TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: Id2835bd393c0ec9e1710644681bc5aab0d7d2aae
Maciej Żenczykowskicommited 2024-03-19 21:45:21 +00:00
Instead of logging and aborting from the BpfHandler::initPrograms(),
return a Status object with an error message. The caller
NetdUpdatable::libnetd_updatable_init() will log the message. Netd
main() will exit and restart.
Bug: 312094533
Test: m
Change-Id: I6717da871a9a53357ac895709ea0094c089e7bbd
Debugging the SIGABRT of this function is annoying because the module
can be built from source or pre-built. It requires finding the correct
version of the symbol to get the correct line number. In addition, there
are 7 consecutive aborts in source code, it is hard to tell whether the
symbolized call stack shows the right line number or not. Adds error
trace before abort so we can identify the root cause without even
symbolizing the call stack of SIGABRT.
Bug: 312094533
Test: make; flash; adb logcat
Change-Id: I74713029d059e10bf5d34694cdb96712bc806696
(in preparation for moving it into netbpfload)
The programs themselves (in bpf_progs/block.c) required a 5.4+ kernel.
We relax this restriction to 4.19+ as we don't have any 5.4 device coverage
(while the pixel 4a 5G / 5 / 5a are all 4.19 devices).
I believe we could relax it further to 4.14+ but Pixel 4/4xl/4a that
would exercise those code paths are EOL and probably have poor to
non existent test coverage, and we cannot do anything for 4.9 T devices
anyway.
Note: on <4.19 kernels (ie. T devices running 4.9/4.14, U running 4.14)
this results in ConnectivityNativeService going from null to initialized
(as the bpf map will exist).
This doesn't hurt as the set/clear port interfaces are only ever
called by vendor code on devices where the kernel doesn't support
the older mechanism. And even if you call them it will just set/clear
the bits in the bpf bitmap, they just won't actually affect anything.
We could flag the map itself as being 4.19+ as well, but I think
I prefer the no-op map to exist...
Test: TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I1085addd22f4f3b709e1875049633832c5dac836
Maciej Żenczykowskicommited 2023-10-06 14:31:20 -07:00
https://android-developers.googleblog.com/2022/09/optimize-for-android-go-lessons-from-google-apps-part-1.html
Year Android MinRAM
2017 8/O 512 MB
2018 9/P 512 MB
2019 10/Q 512 MB
2020 11/R 1 GB
2021 12/S 1 GB
2022 13/T 2 GB
More than 4GB (and really even ~3..3.5 GB) of ram basically
requires a 64-bit kernel, as no one wants to deal with
debugging PAE kernel complexities.
Devices newly launching on 2023's Android 14/U must use
a 64-bit kernel. 5.15 LTS is highest supported by T.
Hence 5.16+ must be a 64-bit kernel.
(see vts_kernel_isa_test.cpp)
Note:
This change doesn't take effect until 2024's Android 15/V,
and only then on the latest 6.~6 LTS, which will only be used
with the latest SoCs, and will thus only affect the latest
and thus premium devices (which likely have 10+ GB).
By the time these 6.6 using SoCs reach lower end devices,
it'll be 2026 or later, at which point I expect even
low end devices will have 4+GB.
Additionally note that technically this only affects
mainline using devices. Non mainline usecases can
be customized (ie. for example this change reverted)
by oems/vendors however they wish. Although we
won't be providing support (but considering the
existing state of 32-bit testing, that's already
pretty much the case).
Test: TreeHugger
Bug: 163141236
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I64f5db5a440465f0b48368815fea3029619a9681
Maciej Żenczykowskicommited 2023-09-29 04:30:17 +00:00
The FD number isn't actually useful debugging information,
and I want to get rid of this fd leak out of BpfMap class.
Test: TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I981832b019b57f534bed1c1fbfedf6457abba6fa
Maciej Żenczykowskicommited 2023-08-20 16:42:09 +00:00
while at it add 'const' to satisfy the linter
Test: TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I207be20c75b103bc5332c111291e4c439ba82219
Maciej Żenczykowskicommited 2023-06-14 10:09:08 +00:00
The random grab bag of stuff in BpfUtils.h is weird,
and I'm trying to trim it down.
Since this is coming from the kernel, 0 meaning error / no socket
is actually kernel api and thus guaranteed.
IMHO if (!cookie) is also clearer to read.
Test: TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I433dfca5695a04a42d632b7e0c2434db26c4ed00
Maciej Żenczykowskicommited 2023-04-19 11:53:38 +00:00
These two checks are theoretically equivalent,
since netd.o marks the program as requiring 4.14+.
Thus unless netd.o bpf program is broken, or bpfloader
is misbehaving, this change is a no-op.
Bug: 270276754
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I2c6982e7476c2fa56b67532c80d97d7389030d32
Maciej Żenczykowskicommited 2023-02-22 22:10:48 +00:00
This effectively reverts commit 6ed2ab9b57,
while ensuring that the program has the right permissions as
defined in r.android.com/2130014 :
oriole:/ # ls -lZ /sys/fs/bpf/netd_shared/prog_netd_cgroupsock_inet_create
-r--r----- 1 root root u:object_r:fs_bpf_netd_readonly:s0 0 2022-10-27 20:05 /sys/fs/bpf/netd_shared/prog_netd_cgroupsock_inet_create
Reason for revert: need to support 4.9 devices upgrading to T.
The only thing that cannot currently be supported on those
devices is the inet_create program which implements the
INTERNET permission.
Also, update bpf_existence_test so it does not check for the
existence of the program on pre-4.14 devices.
Bug: 254001921
Test: atest bpf_existence_test
Change-Id: I14f26cee5feeaae93b4d9710a7b9a2f835ff405f
Lorenzo Colitticommited 2022-10-27 20:06:16 +09:00
since it doesn't actually work (this runs in netd, but is meant
to protect against system server modifications)
Test: TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I87f268f1a68c559b19caa4d625cb9eb8395c91e2
Maciej Żenczykowskicommited 2022-09-01 12:36:17 +00:00
This eliminates the need for netd_updatable BpfHandler.cpp
to initialize the hash map with a zero.
On startup the map will be freshly initialized and thus zero.
On restart it might not be empty, but it doesn't matter to netd.
Furthermore the mainline component of the system server will
re-initialize it again anyway:
see service/native/TrafficController.cpp initMaps()
This does remove the ability to call deleteValue on a key,
since that would always return -EINVAL, but since we don't
currently do that, that's really a feature.
(It does suggest though that we should have a BpfMapNonNullable
class which is writeable, but without a deleteValue() function)
Additionally BpfMap arrays are more efficient for the kernel bpf jit
compiler, as - on newer kernels - it can optimize the read/write
into a simple memory access (as opposed to a bpf helper call).
Before:
$ adb shell ls -l /sys/fs/bpf/netd_shared/map_netd_configuration_map
-rw-rw---- 1 root net_bw_acct 0 2022-06-11 08:20 /sys/fs/bpf/netd_shared/ map_netd_configuration_map
After:
$ adbz shell ls -l /sys/fs/bpf/netd_shared/map_netd_configuration_map
-r--rw---- 1 root net_bw_acct 0 2022-06-16 15:03 /sys/fs/bpf/netd_shared/map_netd_configuration_map
Bug: 235590615
Test: TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I21730e4fa22fbf0c94ab0ca5c5db03aa000b7680
Maciej Żenczykowskicommited 2022-06-16 22:53:42 +00:00
We'd like to switch more of these, but this is the only one
where tests don't get in our way.
We'll fix the rest later. This gives us an *example* for
further testing.
Test: TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I9b280c7ba2d19644fc3cdd0c132de85f45df69b4
Maciej Żenczykowskicommited 2022-06-13 19:39:06 -07:00
(for consistency with rest of code base)
Test: TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I5660615f24daf4285e2b6cbacecb7cd99061c5f5
Maciej Żenczykowskicommited 2022-05-23 20:53:12 +00:00
Configuration map index 1(CURRENT_STATS_MAP_CONFIGURATION_KEY) can only
have value 0(SELECT_MAP_A) or 1(SELECT_MAP_B). Return error if it is any
other values. Otherwise, read out of array boundary can cause memory
corruption or security issues.
Bug: 231420457
Test: TH
Change-Id: Ia800ad78781f72b8118469c0230cc550796d334e
S had a minimum kernel requirement of 4.9,
T bumps this up to 4.14, which adds net cgroup bpf support.
It's important to ship T with this otherwise we'll be forced
into trying to somehow support 4.9 kernels with T mainline
module updates for years and years, when we no longer have
any tests of the old code paths...
Test: TreeHugger
Bug: 232017472
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I6e873f0815f176f5618278087132156c9974d6ea
Maciej Żenczykowskicommited 2022-05-16 11:04:22 -07:00
This is a follow up commit for the family validation {INET, INET6}.
The protocol validation {TCP, UDP} has been added in previous
commit.
The TrafficController socket destroy listener only monitors
on the group {INET_TCP, INET_UDP, INET6_TCP, INET6_UDP}.
Tagging listener unsupported socket causes that the tag can't
be removed from tag map automatically. Eventually, the tag map
run out of space because of dead tag entries.
See TrafficController::makeSkDestroyListener in
packages/modules/Connectivity/service/native/TrafficController.cpp
Also address the comments from previous commit.
- Remove the useless else-statment in tagSocket protocol validation.
- Make the socket cookie query and test into one line in
BpfHandlerTest#TestTagSocketWithUnsupportedProtocol
Bug: 223094609
Test: atest BpfHandlerTest
Change-Id: I0f571fc00caa01c86399f0dbb593e8a40ad94bbd
The TrafficController socket destroy listener only monitors
on the group {INET_TCP, INET_UDP, INET6_TCP, INET6_UDP}.
Tagging listener unsupported socket causes that the tag can't
be removed from tag map automatically. Eventually, the tag map
run out of space because of dead tag entries.
See TrafficController::makeSkDestroyListener in
packages/modules/Connectivity/service/native/TrafficController.cpp
Bug: 223094609
Test: atest BpfHandlerTest
Change-Id: Icc19b7c9f37fef498b89f43e44767f6b9e931a5a
The process is not allowed to tag socket to AID_CLAT via tagSocket()
which would cause process data usage accounting to be bypassed.
Bug: 218407445
Test: atest BpfHandlerTest
Change-Id: Ia7b071e1065733da25e9f02f34ccd17f63653217
1. Add libnetd_updatable.so in com.android.tethering. The library is
loaded by netd. Currently, it mainly targets on a few functions which
access BPF maps. The functionality may extend in the future.
2. Attach gcroup progs from libnetd_updatable.so.
3. Move (privileged)TagSocket and untagSocket implementation to mainline
module. Combine privilegedTagSocket and untagSocket into a single
function.
4. Split related unit tests from netd_unit_test to
libnetd_updatable_unit_test as well.
Bug: 202086915
Test: cd system/netd; atest
Test: atest TrafficStatsTest NetworkUsageStatsTest
Change-Id: Ib556458103a4cbb643c1342d9b689ac692160de0
Patrick Rohr
commited 
Maciej Żenczykowski
commited 
Gerrit Code Review
commited 
Ken Chen
commited 
Nick Wille
commited 
Lorenzo Colitti
commited 
Treehugger Robot
authored and
Hungming Chen
commited