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
Maciej Żenczykowskicommited 2022-07-01 20:18:38 +00:00
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
Maciej Żenczykowskicommited 2022-06-17 18:08:00 -07:00
(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
Maciej Żenczykowskicommited 2022-04-21 06:45:25 -07:00
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
Steven Morelandcommited 2022-02-09 00:59:37 +00:00
netd.c is moved from netd to tethering mainline module.
Bump BpfLoader to v0.9
Bug: 202086915
Test: cd system/netd; atest
Test: atest TrafficStatsTest NetworkUsageStatsTest
Change-Id: I0b8ba90bbbe4e16d979c4a40d6fdbbaac0d14d27
Ken Chenauthored and Maciej Żenczykowskicommited 2022-01-19 04:18:53 +00:00
This makes it harder for system and mainline bpf programs to
conflict with each other, thus enabling easier mainline module
updates.
Test: builds and boots, atest, TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: Ic1b69bb1ddc4a10bd4861dadbd6b97e2520c532d
Maciej Żenczykowskicommited 2021-01-20 05:17:14 +00:00
(should make it easier to observe logs via adb)
Test: atest, TreeHugger
Bug: 150040815
Bug: 160546011
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I20d6ede4ddf516a91c707aa08cf3a92aed39b03b
Maciej Żenczykowskicommited 2020-07-15 01:44:12 -07:00
Reasoning: critical load failures for netd bpf programs will just result
in unpredictable behaviour later on. For example netd/systemserver
crash loops.
Test: builds
Bug: 150040815
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: Iefa01e60cd0a9a223e96411726a199bfb4857a5a
Maciej Żenczykowskicommited 2020-06-15 08:01:50 +00:00
... which also means waitForProgsLoaded() has to be a no-op on pre-bpf devices.
This is more consistent: it's weird to have bpf.progs_loaded set on a 4.4 device.
Test: builds, atest
Bug: 150040815
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: Iddabcf56c187ea518dd2e4d8db451b2f6902aa8e
Maciej Żenczykowskicommited 2020-06-13 22:41:48 -07:00
Currently the bpfloader does not try to load programs if
bpf.progs_loaded is set. However there is no harm in trying to reload
programs because the loader is designed to reuse previously created maps
and programs if they were created. On the other hand, not trying to load
if property is set is harmful since the property prevents retries. So
prevent this from happening.
Bug: 134558982
Change-Id: I61dfb8827ca37c9a1ff4e0912ca96f06a36c37d6
Signed-off-by: Joel Fernandes <joelaf@google.com>
The bpfloader should not try to load bpf objects on unsupported devices
since devices with 4.4 kernel can have bpf maps but not bpf pogram
support. Creating bpf maps on those devices would mislead the framework
code to use an unsupported code path and crash system server.
Bug: 130687855
Test: cuttlefish boot test for 4.4 kernel.
Change-Id: I43ffc01e1099ee3effaa6ba30aa78080d5bec72f
Chenbo Fengauthored and Maciej Żenczykowskicommited 2019-04-17 21:40:39 +00:00
This was necessary when the netd BPF program lived in system/bpf,
but it's no longer necessary.
Test: m
Bug: 65674744
Change-Id: I1fcf7e41276341b1258adf9d3795e81b6139f84f
Lorenzo Colitticommited 2019-03-26 13:52:15 +09:00
The property bpf.progs_loaded will be used by services expecting BPF
programs to be loaded and wait before they are loaded.
Bug: 112334572
Change-Id: I19daa0caa84e2659e8790f0dd551d95ab824e13b
Signed-off-by: Joel Fernandes <joelaf@google.com>
Change the netd bpf program to the new format. Adding map definition and
necessary helper functions to the kernel program code. Move the netd bpf
programs out of bpfloader to a new directory.
Test: dumpsys netd trafficcontroller
Bug: 112334572
Change-Id: I9287285d188e966193532b1522b5d3e67e32e930
Chenbo Fengauthored and Joel Fernandescommited 2019-01-07 20:17:42 -05:00
* Wrote a relocatable ELF loader from scratch. The loader library loads
all objects in /system/etc/bpf/, parses and fixes up eBPF instructions
based on relocation information, creates maps and programs and pins
them. A single API call without arguments is made which results in this
operation. The API has all the information it needs from the filesystem
and the ELF objects, so there is no configuration stored in the code
calling the loader API essentially making it zero conf. Initially this
will be used by time_in_state statistics collection using tracepoints.
In the future, netd's eBPF C code should be rewritten to use this
infrastructure and the old ELF loader can be gotten rid off. This is the
first step.
* Link libbpf with libbpf_android which will come from the external/ bcc
project. This will be used for tracepoint and perf eBPF support. In the
future it can be used for other things as kernel eBPF support advances.
This patch will be merged only after bcc is cloned into external/ to
prevent build breakage.
Bug: 112334572
Change-Id: Ic0fd9504e18031132d40bb627c5e44058d59c9f8
Signed-off-by: Joel Fernandes <joelaf@google.com>
system/bpf/bpfloader/BpfLoader.cpp:79:23: error: comparison of integers of different signs: 'int' and 'std::__1::vector<android::bpf::BpfMapInfo, std::__1::allocator<android::bpf::BpfMapInfo> >::size_type' (aka 'unsigned long') [-Werror,-Wsign-compare]
for (int i = 0; i < mapPatterns.size(); i++) {
~ ^ ~~~~~~~~~~~~~~~~~~`
Test: m checkbuild
Change-Id: If2891bfc7655aea34499975763f72e0a25b32289
Apply the git clang format on the bpf project to make sure the existing
code compliance with the standard.
Test: project compiles and bpfMapTest pass.
Bug: 112334572
Change-Id: I4774aa2a197be2c671f6fb307c1fc9b71edfeeec
Add the necessary Android.bp file and fix the compile error for the new
bpf project.
Fix the run time restart false alarm in bpf loader.
Bug: 112334572
Test: device boot and dumpsys netd show eBPF object okay, runtime
restart netd and no bpfloader error showed in logcat.
Change-Id: Iae193bda45e50b7d22479086d6403e3c4fb185c4
Copied the files from system/netd into system/bpf. No modification is
made to the files.
Test: this doesn't build since the Android.bp file is missing
Bug: 112334572
Change-Id: Ia090a429dd416e07c46766784fb3dd2037201525
Maciej Żenczykowski
commited 
Stephane Lee
commited 
Steven Moreland
commited 
Ken Chen
authored and
Hungming Chen
commited 
Joel Fernandes
commited 
Chenbo Feng
authored and
Lorenzo Colitti
commited 
Chih-Hung Hsieh
commited 
Yi Kong
commited