This simply cannot happen as the NetBpfLoad binary is built
and shipped together with *all* of the bpf .o files it parses
(we *only* look in /apex/com.android.tethering/etc/bpf/ and subdirectories
thereof, while the loader itself is /apex/com.android.tethering/bin/netbpfload).
So the only way an unrecognized value can happen is a code bug:
someone adds something new to a .o without also updating NetBpfLoad
(in a previous or the same commit).
That's worth explicitly flagging in TreeHugger via refusal to boot.
Test: TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I29b9ef982bf728a35b6c9d9abbbab1138a4796ce
Maciej Żenczykowskicommited 2024-08-07 15:38:03 -07:00
This actually makes things build,
and removes some duplication.
Test: TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: Ie5f95c7cc7f21525e649db0eebccb8e6933678b3
Maciej Żenczykowskicommited 2024-08-07 15:18:31 -07:00
This eliminates loader.{h,cpp} which exist only for historical
reasons (this stuff used to be the libbpf_android library,
but the split between what was in and outside the lib never
really made all that much sense, and now it is not even a lib...).
Generated via:
cd //packages/modules/Connectivity/netbpfload
cat loader.h loader.cpp NetBpfLoad.cpp > z
cat z > NetBpfLoad.cpp
rm z loader.cpp loader.h
git add NetBpfLoad.cpp
git rm loader.cpp loader.h
Test: does not build, see follow up
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: Ie1a41a9ce935a7db6be5af810ce92a2d3e290264
Maciej Żenczykowskicommited 2024-08-07 15:17:21 -07:00
Arm-only because the 32 bit userspace vs 64-bit kernel
issues are worse on x86 because of some extra 4 vs 8 byte
alignment (when included in structs) ABI issues.
Wear is unlikely to ever run on comparatively high
power usage x86 cpus, so this should be fine.
Manually tested by adding:
if (isWear()) ALOGI("Wear!");
and additionally logging 'bool watch' within isWear()
on 'cf_gwear_x86-trunk_staging-userdebug'.
Resulting output:
I NetBpfLoad: NetBpfLoad v0.46 (/apex/com.android.tethering/bin/netbpfload) api:35/36 kver:601004b (32-on-x86-64) uid:0 rc:01
I NetBpfLoad: isWear(ro.cw_build.wear_sdk.version=6[6] ro.build.characteristics='nosdcard,watch'[1]): true
I NetBpfLoad: Wear!
Bug: 346252668
Test: TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I9b2a3b88095264245935950bd1a7dfbb5293334b
Maciej Żenczykowskicommited 2024-06-25 10:39:43 +00:00
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
Maciej Żenczykowski
commited 
Treehugger Robot
authored and
Gerrit Code Review
commited 
Rishi Sikka
authored and