it doesn't work due to sepolicy anyway:
I auditd : type=1400 audit(0.0:6): avc: denied { search } for comm="netbpfload" name="gsi" dev="sda8" ino=23 scontext=u:r:bpfloader:s0 tcontext=u:object_r:gsi_metadata_file:s0 tclass=dir permissive=0
Bug: 347309609
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: Ic8c56a096a89a89950585b939379634accb78e56
Maciej Żenczykowskicommited 2024-06-14 20:23:16 +00:00
aosp/main is currently still sdk 34/U, and netbpfload
runs as root (like on U QPR3 and V) which makes us treat
it as U QPR3.
This change will make us treat it as 35/V.
This will also potentially result in us already seeing
sdk 36 in places (goog/main?), but this won't currently hurt
(because we don't distinguish anything >=35).
And indeed it likely won't ever hurt us, as too high
a version on dev branches (goog/main?) is unlikely
to be a practical problem.
Test: TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I318df93e5b3a06af2ee2c6ab1cb40d8a8dffa212
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
since this is dynamic, it seems like a useful thing to log
Test: TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I073e76ab54b4f2182c9b5c2b128425a5294ed50a
Maciej Żenczykowskicommited 2024-06-13 15:38:33 -07:00
(and add a few more comments for what access is needed in general)
Test: TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I2aa596f4f2d34179bb36360ad1c9a795fbb97d0d
Maciej Żenczykowskicommited 2024-06-13 15:26:55 -07:00
This isn't actually useful as it is apparently always just 10000
Test: TreeHugger
Change-Id: Ibf625150ee8f964a386a5e9f15e0552d611ce927
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
Android TV OEMs & vendors are more interested in keeping costs down
rather than keeping networking functional.
Considering this probably mostly affects more advanced networking,
like VPNs and/or network statistics, it may be an acceptable trade off.
Bug: 333970930
Test: TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I7bf8d1bbd87b7af4f7c98372b6c1d3d3be62a600
Maciej Żenczykowskicommited 2024-05-30 11:10:06 +00:00
This reverts commit 75caacdd10.
Reason for revert: The policy is already checked in VTS. It seems delaying the boot is out-of-scope for NetBpfLoad.
Change-Id: I12cec43dc2efb90ae35ccda7203317d198054d0e
Rishi Sikkaauthored and Gerrit Code Reviewcommited 2024-05-28 16:55:49 +00:00
(such kernels are already in violation of VTS)
I don't quite want to break boot, but I figure a slow
boot will result in devices getting fixed rather than
released with ancient/unsupported/buggy kernels...
Test: TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: Ia2cf550f661ce468acbc5ecff0ce5b6fa16b0e3a
Maciej Żenczykowskicommited 2024-05-20 12:02:47 +00:00
Not actually needed, we already log the result.
Test: TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I8391825cb5171162afb9bdf8fdf695d9f85693cb
Maciej Żenczykowskicommited 2024-04-30 10:10:12 +00: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
Note:
2 == BPFLOADER_S_VERSION
19 == BPFLOADER_T_VERSION
25 == BPFLOADER_OBJ_AT_VER_VERSION
33 == BPFLOADER_IGNORED_ON_VERSION
37 == BPFLOADER_U_VERSION [*]
41 == BPFLOADER_V_VERSION [**]
and currently we have:
42 == BPFLOADER_MAINLINE_VERSION
43 == BPFLOADER_MAINLINE_T_VERSION
44 == BPFLOADER_MAINLINE_U_VERSION
45 == BPFLOADER_MAINLINE_V_VERSION
[*] udc-dev/udc-release are actually 38, as 37 was some earlier
udc beta2 (2.1 ifirc), and beta3+ switched to 38
[**] 24Q{1,2}-release (ie. U QPR2+) are technically actually 41,
but their platform bpfloader no longer even looks in /apex/com.android.tethering/etc/bpf/...
so it doesn't really matter (although 24Q1's platform
netbpfload still does, however that is obsoleted by
this change)
Thus we need to (as minimum for NetBpfLoad):
BPFLOADER_T_VERSION -> BPFLOADER_MAINLINE_T_VERSION
BPFLOADER_IGNORED_ON_VERSION -> BPFLOADER_MAINLINE_U_VERSION
to cause these to load appropriately from mainline.
One would perhaps also expect (as minimum for NetBpfLoad):
BPFLOADER_OBJ_AT_VERSION -> BPFLOADER_MAINLINE_U_VERSION
but (as maximum for platform bpfloader):
BPFLOADER_OBJ_AT_VERSION -> BPFLOADER_MAINLINE_U_VERSION
However, since the goal is actually for those to load via mainline on T+,
(with the 'old' version of the .o's loading on S via platform bpfloader)
thus one actually needs (as minimum for NetBpfLoad):
BPFLOADER_OBJ_AT_VERSION -> BPFLOADER_MAINLINE_T_VERSION
and (as maximum for platform bpfloader):
BPFLOADER_OBJ_AT_VERSION -> BPFLOADER_T_VERSION
Test: TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I4b688692ffca0db7ead20cefd9e7e892ca92c70a
Maciej Żenczykowskicommited 2024-03-19 21:33:55 +00:00
(in preparation for this being run-time dynamic)
Test: TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: Icac8d1afdd3d55b80c232dd5a124a79a9063f350
Maciej Żenczykowskicommited 2024-03-18 14:40:08 -07:00
since there is no longer a platform netbpfload...
hence we can simplify
Now:
git grep 'platformNetBpfLoad|apexNetBpfLoad|is_mainline|is_platform'
comes up empty
Test: TreeHugger, manual
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I834656bc4860386b6463db3f6a898d249a05e3a4
Maciej Żenczykowskicommited 2024-03-08 02:19:09 +00:00
(instead of in platform bpfloader)
Better to do it earlier so we can use it for
auto/permanently pinned/attached networking programs.
Test: TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I202e150e6d48e63ba643c1bd2247cefcdebc07a5
Maciej Żenczykowskicommited 2024-02-29 02:02:19 +00:00
should never fail, since we now have M-2024-1 module prebuilts:
$ adb shell ls -d /apex/com.android.tethering*
/apex/com.android.tethering
/apex/com.android.tethering@341310230
Test: TreeHugger, manually on a Pixel device
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: Ib145fba8e3c47bc300f4589723d9c80749770a19
Maciej Żenczykowskicommited 2024-02-28 01:23:32 -08:00
(this will land in M-2024-05 ie. May mainline tethering module)
Test: TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I250b691eb03751da05ce10d41d6721f4964dd1d5
Maciej Żenczykowskicommited 2024-02-13 00:31:30 +00:00
(super useful for debugging)
Sample output:
I NetBpfLoad: NetBpfLoad '/apex/com.android.tethering/bin/netbpfload' starting...
I NetBpfLoad: NetBpfLoad api:10000/34 kver:6010019 platform:0 mainline:1
D NetBpfLoad: Found Tethering Apex mounted from blockdev /dev/block/dm-55
I NetBpfLoad: Tethering APEX version 340090000
Test: TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: Iaf1bc22b02913ea21ff9368abd9933e6ef4017f1
Maciej Żenczykowskicommited 2024-02-09 23:31:17 +00:00
netbpfload.mainline.rc is derived from:
initrc-doc/bpfloader-sdk34-14-U.rc,
except that it is 'override' instead of 'updatable' and uses
the apex netbpfload instead of the platform bpfloader.
Test: TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I1ecf14e3d927ece136a0669a9b209be7112e55b5
Maciej Żenczykowskicommited 2024-01-31 22:36:39 +00:00
proc file writes were only moved from .rc into bpfloader binary in U.
Test: TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I20eda71d4f4e16130401d1cfff239c7cd8ea9bf6
Maciej Żenczykowskicommited 2023-10-25 18:40:53 +00:00
No need for this, as we simply only support those selinux
contexts (and directories) which are available to networking.
Test: TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I35b134c57411f82514b9f7148411f83d3aee1927
Maciej Żenczykowskicommited 2023-10-10 03:46:06 -07:00
(it's already created by the platform bpfloader)
Test: TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: Ie22f585cab17fd2bded3d97a9cfe1019b792b69d
Maciej Żenczykowskicommited 2023-10-10 03:37:14 -07:00
No need for this, as we simply only support network
program types in the first place.
Test: TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I163e21fd4d4089882cf37fc68bc4299003b514d7
Maciej Żenczykowskicommited 2023-10-09 00:32:36 -07:00
These are unmodified files, without history.
Getting these to do something useful will come later.
Generated via:
cp //system/bpf/bpfloader/bpfloader.rc netbpfload.rc
cp //system/bpf/bpfloader/BpfLoader.cpp NetBpfLoad.cpp
cp //system/bpf/libbpf_android/include/libbpf_android.h loader.h
cp //system/bpf/libbpf_android/Loader.cpp loader.cpp
Change-Id: I1677b899a51e1289a7a9806d6f5c34450b9e7c47
Maciej Żenczykowskicommited 2023-10-02 14:59:10 -07:00
Maciej Żenczykowski
commited 
Treehugger Robot
authored and
Gerrit Code Review
commited 
Rishi Sikka
authored and