There is no need / benefit to do(ing) it twice, so might as well
remove it from the non-mainline location.
Test: TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I9887d983714903731f26c9d2478983d8276bfdba
(note: bpf.progs_loaded is set by the network bpf loader)
Test: TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: Ie1a906f31afacd656fcaa402ff348955c5f510b0
This is safe as there are no LTS 6.2+ kernels yet.
Test: TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I2766ee9eb54017451a301b4d7dcf81368fb41723
This fixes up yesterday's commit that added
the error message in the first place.
Android U hopefully launches ~Sep/Oct 2023
Android U QPR1 should be approx. a quarter after that,
so ~Dec 2023 or ~Jan 2024.
Android U QPR2 presumably releases another quarter later,
ie. around March/April 2024.
Per: https://www.kernel.org/category/releases.html
The 4.14 LTS kernel series projected EOL is Jan, 2024
This means that U QPR1 is the last one that 'should'
still support 4.14.
We are free to drop support in U QPR2+ as those will
be released after 4.14 goes EOL.
aosp/main only merges into branches *after* the current
udc-qpr-dev and thus will not end up in U QPR1.
Test: TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I3ad6cada3d40c8d2bb0ee07ff52b4e36e1689bde
due to a regression in boot speed, caused by the extra fork-exec of btfloader
(Loosely based on https://android-review.git.corp.google.com/c/platform/system/bpf/+/1909155 )
Test: TreeHugger
Bug: 286369326
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I258a9437aedb10d1fa7e91e1a7f22fd8cb99a4a2
The default list of memtag targets found in
build/make/target/product/memtag-common.mk
Bug: 280343521
Test: no functional change
Change-Id: I7b2713fa0065f8c0317cc7634eedf6143f7fefec
The logic dealing with in vs out-of-process tethering flags
was added in aosp/master once it was already not merging to tm-dev,
thus ending up only in udc-dev, it was later removed in aosp/master,
and then cherrypicked to udc-dev.
As such there is no shipping version of the bpfloader
(besides early U developer previews and betas)
with this requirement.
Ignore-AOSP-First: change must land in U first,
since it's not safe if it isn't approved for udc-dev
Test: TreeHugger
Bug: 279942846
Signed-off-by: Maciej Żenczykowski <maze@google.com>
(cherry picked from https://googleplex-android-review.googlesource.com/q/commit:48cd8236816ef8d29002fb0c7c66ff480fa3a396)
Merged-In: If7c3ca47891d53f478f7b784580efb2a0014c617
Change-Id: If7c3ca47891d53f478f7b784580efb2a0014c617
This should now be safe on Android V+
(we should have aged out of kernels that don't support this),
as we're not really considering R->S->T->U->V 4 OS version upgrade path
supported (without at least some work on the part of vendor/oem).
Note that 4.14 was the minimal version supported for U,
so presumably the minimal version for V is 4.19,
which happens to also be the only version < 5.4 (ie. where
this isn't already enforced).
Test: TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I22487bf54d8f8e235b4dde3cdde5c3c2c1ccf9e8
This should now be safe on Android V+
(we should have aged out of kernels that don't support this),
as we're not really considering R->S->T->U->V 4 OS version upgrade path
supported (without at least some work on the part of vendor/oem).
Note that 4.14 was the minimal version supported for U,
so presumably the minimal version for V is 4.19,
which happens to also be the only version < 5.4 (ie. where
this isn't already enforced).
Test: TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I70485b5da1aeba190218c06e8e5179f8b851cce1
This feature allows skipping a program or map based on the type of the
build. This allows things like userdebug-only programs.
Bug: 246985031
Test: added test program and watched it skipped on userdebug
Change-Id: I981e3447b40751926cbfd1692e13772ec582d3d4
as discovered on some sunfish 4.14 kernels
Note that CONFIG_BPF_JIT=y is required for 4.14-r,
but sunfish was 4.14-q and thus missed VINTF enforcement of this
(it was enabled for b1c1[blueline/crosshatch]/bonito & floral[flame/coral]).
Bug: 262115216
Test: N/A, comment only
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: If6ee9f7f9e449526602fd0e5cffd49f132e681a2
Simplify the loadProg() interface by passing struct Location instead
of passing its fields as separate arguments. Move struct Location into
libbpf_android.h to accommodate the change.
Change-Id: I39834b2645d38ba4c2eb5ea901a3da0f56a1912c
Signed-off-by: Connor O'Brien <connoro@google.com>
This adds an example BPF program with a ring buffer. The program using
the ring buffer is limited to kernel versions 5.8 and above (the same as
the ringbuffer internally). The program is marked critical to ensure
that the platform can support ringbuffers in the bpfloader.
This is only done for userdebug builds currently since tests that use it
can only be run in userdebug builds and statically allocates a 4KB ring
buffer.
Bug: 246985031
Test: build and flash on 4.19 and 5.10
Change-Id: I3cdb4a03051f832915bb784d43c01392c087f54c
this allows tightening the sepolicy for 'proc_bpf' in:
https://android-review.git.corp.google.com/c/platform/system/sepolicy/+/2323635
'sepolicy - move proc bpf writes from bpfloader.rc to bpfloader binary'
While we're at it, this also allows us to actually verify
that these sysctls are being successfully set.
Test: TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: Ibde9d817b690395e3eb12f6b5acdf3060aca67b9
we also take this opportunity to enforce that all the
directory creations actually succeed (there really
is no reason why that could fail though)
Test: TreeHugger, manually inspected /sys/fs/bpf contents on cuttlefish
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: Icd7c1e6eba5736a58cf81476ddafc70df2807dd4
(this is a test for a kernel bug)
Bug: 240347583
Test: TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I0cad47113a83dbd837cccc5229ef52b605cda203
Until fuse-bpf is upstreamed, the value BPF_PROG_TYPE_FUSE is
dynamically defined, so use BPF_PROG_TYPE_UNSPEC as a placeholder and read
the actual value from sys/fs/fuse
Bug: 202785178
Test: fuse bpf can be enabled successfully
Change-Id: I67d3ff45768b581a6b239e235edaa6e46a2f6fe0
Underscore character may cause bpf prog/map naming collision. For
example, x.o with map y_z and x_y.o with map z both result in x_y_z
prog/map name, which should be prevented during compile-time.
aosp/2147825 will prohibit underscore character in bpf source name
(source name derives the obj name). Existing bpf modules with underscore
characters in source name need to be updated accordingly.
Bug: 236706995
Test: adb root; adb shell ls -l /sys/fs/bpf/ | grep timeInState
Change-Id: Ia4eefd8b7debed2c81e194052488e15df72cab69
(this is instead of relying on the CAP_CHOWN capability it has)
The goal is to allow bpfloader to open maps/programs it creates,
so that it can reuse them. By virtue of CAP_CHOWN it can create,
pin, then give away ownership, and no longer be able to bpf_obj_get()
the pinned map or program (to reuse it at a later time).
This could be considered a partial (more targetted) workaround
for the lack of bpfloader CAP_DAC_OVERRIDE (or CAP_DAC_READ_SEARCH).
But for obvious reasons jeffv@ doesn't really want to grant that.
In some sense this doesn't actually really grant any privs on a writeable
filesystem, as CHOWN already allows stealing ownership...
However explicit membership is much easier to reason about,
and does not require playing:
- stat (to get current uid/gid/mode)
- chown (set uid to root, ie. self -- works due to CAP_CHOWN)
- chmod (grant user read if missing)
- bpf_obj_get (this now succeeds -- does not require capabilities)
- chmod (restore mode)
- chown (restore uid -- works due to CAP_CHOWN)
games in order to open pinned bpf maps/programs we'd normally be unable
to open due to unix uid/gid/mode restrictions.
Yes, I've verified the above 'magic' actually works with current privs,
provided we grant the missing 'getattr' selinux priv to allow the stat() call.
(obviously without it we can still gain access, we just can't undo things)
Currently /sys/fs/bpf maps and program ownership on a tip-of-tree T device looks like:
$ adb shell getprop ro.build.fingerprint
google/oriole/oriole:13/TP1A.220624.007/8785063:userdebug/dev-keys
$ adb shell ls -l /sys/fs/bpf/* | egrep '^-' | cut -d' ' -f3-4 | sort | uniq -c
count uid gid examples
5 root graphics platform: gpu_mem.o & gpu_work.o
5 root net_admin tethering apex T+: netd.o skfilter_..._xtbpf & schedact_ingress_account programs
10 root net_bw_acct tethering apex T+: netd.o maps
24 root network_stack tethering apex S+: offload.o & test.o
1 root root tethering apex T+: netd.o cgroupsock_inet_create program
38 root system platform & tethering apex T+: time_in_state.o, block.o, clatd.o, dscp_policy.o, netd.o cgroupskb_(e|in)gress_stats
And additionally due to the utter lack of a 'groups' line in bpfloader.rc,
the default bpfloader gid is of course 'root'.
This suggests we should use:
groups root graphics network_stack net_admin net_bw_acct system
(but only really mainline updatable stuff matters, so we could limit
this to just networking and strip out 'graphics'...)
A glance through:
system/core/libcutils/include/private/android_filesystem_config.h
Finds the following groups which might be of interest to bpfloader & mainline networking:
* root
* system
* graphics
dhcp
vpn
mdnsr
clat
dns
dns_tether
* network_stack
inet
net_raw
* net_admin
net_bw_stats
* net_bw_acct
[stars mark the one's we've already identified previously]
Networking mainline code runs in 3 processes: netd, system_server and network_stack.
Based on looking at a live oriole device, these processes have the following
uid/gid/groups/capabilities:
netd - uid:0[root] gid:0[root] + 3005[net_admin]
Cap: 00000000000074ef=cap_chown,cap_dac_override,cap_dac_read_search,cap_fowner,cap_kill,cap_setgid,cap_setuid,cap_net_bind_service,cap_net_admin,cap_net_raw,cap_ipc_lock
networkstack.process - uid:1073[network_stack] gid:1073[network_stack] + 1073[network_stack]
3002[net_bt] 3003[inet] 3004[net_raw] 3005[net_admin] 3006[net_bw_stats] 3007[net_bw_acct] 9997[everybody]
Cap: 0000000000003c00=cap_net_bind_service,cap_net_broadcast,cap_net_admin,cap_net_raw
system_server - uid:1000[system] gid:1000[system] + 1001[radio] 1002[bluetooth] 1003[graphics]
1004[input] 1005[audio] 1006[camera] 1007[log] 1008[compass] 1009[mount] 1010[wifi]
1018[usb] 1021[gps] 1023[media_rw] 1024[mtp] 1032[package_info] 1065[reserved_disk]
3001[net_bt_admin] 3002[net_bt] 3003[inet] 3005[net_admin] 3006[net_bt_stats] 3007[net_bw_acct]
3009[readproc] 3010[wakeloc] 3011[uhid] 3012[readtracefs]
Cap: 0000001806897c20=cap_kill,cap_net_bind_service,cap_net_broadcast,cap_net_admin,cap_net_raw,cap_ipc_lock,cap_sys_module,cap_sys_ptrace,cap_sys_nice,cap_sys_time,cap_sys_tty_config,cap_wake_alarm,cap_block_suspend
Since netd has DAC_OVERRIDE, it really doesn't matter from a group analysis perspective
(side note: it probably should have a lot more groups than it actually does...)
Either way, both *root & *net_admin are already in the above list.
For the network stack process the obvious groups are:
*network_stack, net_raw, *net_admin, net_bw_stats, *net_bw_acct
which means we should add:
net_raw, net_bw_stats
to the above list.
(I'm assuming 'inet' & 'everybody' are too generic groups to be of use for bpf,
and that we don't [yet] care about bluetooth (net_bt) being able to use bpf directly)
For the system server the choice is harder, but I'd tend to pick:
*system, *graphics, *net_admin, *net_bw_acct
(Again ignoring non-networking stuff, and assuming radio/bluetooth/wifi bpf
use will come at some later point in time.)
This gives us decent coverage of the 3 processes (and combinations there-of):
netd process -> group root
network stack process -> group network_stack
system server process -> group system
both network stack and system server -> group net_bw_acct
Note that due to DAC_OVERRIDE netd always has unix access no matter what,
and needs to be limited via selinux contexts instead.
Additionally 'net_admin' is used for xt_bpf iptables programs due to need
for netutils_wrappers support and it is also usable by all 3 processes.
This means we can fully explain all groups that currently show up as in use.
Adding net_raw & net_bw_stats is possibly not needed, but also won't hurt,
and might be useful in the future.
We could also argue that we should add:
dhcp, vpn, mdnsr, clat, dns, dns_tether & inet
But since none of our mainline code running processes are currently
members of those groups (besides netd due to DAC_OVERRIDE), there doesn't
seem to be much benefit (this can't be changed with mainline pushes).
I assume new stuff which would need these groups will actually only be loaded
on U+ bpfloader, which will have a less hacky solution for this problem anyway.
Note: on U+ bpfloader we should probably fix this by simply caching
all bpf map/prog filedescriptors in a path->fd hashmap, and thus
avoid the need to ever reopen anything. This is a far more invasive change,
but once done we should be able to revert this change.
For safety we'll also want to make sure we abort() if we detect cases
that cannot be safely handled by S bpfloader, an example would be
maps with uid != root in tethering location.
Bug: 218408035
Bug: 237716689
Test: TreeHugger, manual testing
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I742868b1a6819547fcd7a3573946a2fc479a21a5
This is to prevent platform and tethering mainline module updatable
code from being to step on each other.
Bug: 218408035
Test: TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I8f4ffafb72efb17d07aaf993892c5d395bd6876d
For use by:
- maps netd should have read but not write access to
(needed due to netd being root with DAC_OVERRIDE,
and thus not obeying standard unix permissions)
- programs that netd should have access to but
not netutils_wrappers (which due to being able to
run iptables, needs access to xt_bpf programs)
Bug: 218408035
Test: booted on cuttlefish
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I72b106692a25077ff54252fd93db81f46b52125d
(no selinux consequences to this in and of itself,
though required for follow up selinux changes)
Test: TreeHugger, manual
Bug: 218408035
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: Id5ef7f3b119743ef26b062068756c4e0f754e694
This also fixes a permissions issue if a non-root user is set. The read
permissions should be set before the file is set as non-root to ensure
that the permissions can be set without error.
Bump the BPF loader version.
Bug: 203462310
Test: Ensure that vendor skfilter bpf programs can load
Change-Id: Ib6b9a64d8652ff464c9d4d734bb8ae351673b6ce
Allow vendors to use bpf programs, but limit to tracepoints
for now (other types of programs, for instance skfilter, aren't
safe to expose, because the kernel gives us limited ways to
control which resources can have BPF programs attached, and
some shared resources only support a single BPF program at an
attach point).
Bug: 140330870
Bug: 162057235
Test: install bpf program to /vendor/etc/bpf/ and use it.
Test: atest libbpf_load_test
Change-Id: I6c876fe52739c38db73689ffd784167e7d35d58a
