We cannot submit this as long as we want current mainline releases
bpf .o objects to be loaded by images with bpfloader v0.0.
Bug: 190519702
Test: atest, TreeHugger - existing bpf programs load
examination of bpfloader logs
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I157458a4f798e455fb563fad569e20bfde5248fd
This is bpfLoader v0.1, previously we had no version number,
the version immediately preceding this commit we'll call v0.0.
Versions older than that are either pre-S and don't matter, since
loading mainline eBpf code was only added in S, or are from early
during the S development cycle (ie. pre-March 5th 2021 or earlier)
and simply no longer supported (no need to maintain compatibility).
Bug: 190519702
Test: atest, TreeHugger - existing bpf programs load
examination of bpfloader logs
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I36fa5b917540be7ea3ecfddc5fe7834e9eb18d88
This is due to changing how many bits are assigned to individual fragments,
which was done to support kernel version 4.9.256.
Test: atest, TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I7f556352beab009cd114e2241f3d7fe6d878a458
Instead of doing 16/8/8 bits for major/minor/subver macro,
switch to 8/8/16 bits, since this gives plenty of space:
- major versions are bumped every few years, so 256 last forever
- minor versions are bumped every few months (~5-6 per year),
so 256 lasts for decades, additionally Linus Torvalds doesn't
like big numbers, and eventually bumps the major instead
- sub versions are the problematic ones, because they're bumped
on every LTS security release, however even at one release per day,
16 bits lasts for 180 years
Note: before this change 4.9.256 was treated as equivalent to 4.10.0.
Luckily all our tests were only ever (by chance) against the LTS release
bases (ie. 4.9.0, 4.14.0, 4.19.0, 5.4.0) and thus we wouldn't have hit
an actually failure until 4.9.(5*256) === 4.14.0 which would have caused
the bpfloader to attempt to load bpf code requiring 4.14 on a 4.9 kernel,
and resulted in failure of device to successfully boot.
Test: atest, TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I0535ce081967af092f3342c0abfd05a1e5028eb6
This measure is not affected by uid removals and is monotonic. That
makes it a good fit for CPU telemetry in statsd.
Bug: 174245730
Test: manually compare total with uid breakdown
Change-Id: I0f04f2ff09d77a4c7d9fe1e2b492f983b61987f6
This is useful for critical functions with fallbacks, but
may even be useful for non-critical functions, where a function
in the middle of the file may fail to load, but you still want
other (later) functions to be attempted.
Critical applies to the entire .c file (or to be more correct to
the entire resulting .o). Optional applies to a specific section
of that .o (ie. a specific individual function).
This new optional attribute is necessary to be able to declare
a .c/.o file critical even if *some* of the individual functions
might fail to load due to missing kernel patches.
(Note: we currently have no way to specify a map as optional)
Critical guarantees that all non-optional programs, and all maps,
have been created, pinned, chowned, and chmoded successfully
(or that they already existed).
For an example of use see:
system/netd/bpf_progs/offload.c
(while at it also add retrieveProgram() and mapRetrieve{RW,RO,WO}()
helpers to BpfUtils.h)
Test: builds, atest, see paired netd change for extra details
Bug: 150040815
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I50b292c061b05fc8f4b4b8574f128345c45c78db
Some ebpf code cannot be loaded on too old kernels.
Sometimes we want a different - more advanced - version of an ebpf program
to be loaded on a newer kernel.
Test: build, atest
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I9e93e7246951916e6d60544575337a7a19c82886
Unlike maps, BPF programs currently have no natural place to declare
metadata like their desired owner & group. Add a bpf_prog_def struct
to allow setting these, located in a new "progs" section, and update
bpfloader to chown pinned programs appropriately based on this
information.
Add a #DEFINE_BPF_PROG macro to simplify adding this data for
programs. The struct name is the name of the corresponding function
with "_def" appended, which bpfloader uses to correlate a bpf_map_def
with the correct program.
Also have bpfloader set mode to 0440 for all programs, since only read
access should ever be needed
Bug: 149434314
Test: load a program that uses DEFINE_BPF_PROG and check that owner &
group are set as expected
Change-Id: I914c355f114368fe53de2c7f272d877463cba461
Signed-off-by: Connor O'Brien <connoro@google.com>
Keys and values passed in to lookup/update/delete are not modified.
Test: builds
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I222615af7695f41bfb59c872c7368829631c08a9
Key and value formats for time in state related BPF maps currently
have to be kept in sync between the BPF prog and
libtimeinstate. Add a new bpf_timeinstate.h header file in a directory
that already gets added to the include path for BPF progs, and add
this file to a cc_library_headers module so it can be used from
libtimeinstate as well.
Test: build libtimeinstate and time_in_state.o
Bug: 138317993
Change-Id: Ic56b2b64746f2211f3c802e074339750f26303c0
Merged-In: Ic56b2b64746f2211f3c802e074339750f26303c0
Signed-off-by: Connor O'Brien <connoro@google.com>
(cherry picked from commit badb20f528)
Test: treehugger will, plus no other references found by:
repo grep 'unsafe_bpf_map_(lookup|update|delete)_elem'
Bug: 132703771
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I59b8fe8f5a00fd005f466f8f2177a2e01cff58aa
This is needed for the iorapd project (i/o readahead).
Change-Id: If6a3de682296bbce0fc808a0eced6bd778106292
Signed-off-by: Joel Fernandes <joelaf@google.com>
For the eBPF programs that only related to networking, move them back
to netd so for the future changes in networking eBPF area, there is not
need to make changes in both netd project and bpf project.
Bug: 112334572
Test: mmma -j32 system/bpf
Change-Id: Icd0efd165c60c055a00fe88705a0c8070c0d22f5
The BPF helper is moved into system/bpf/include/ and is available
to all BPF programs in the include search path. Make use of it.
Only minor refactor, no functional change.
Bug: 122665156
Change-Id: Ib5b495aff83874d39abe3640fb369b2ff92b3239
Signed-off-by: Joel Fernandes <joelaf@google.com>
For new kernel that support cgroup socket filter, use bpf programs to
control the creation of inet socket.
Bug: 111560570
Bug: 111560739
Test: dumpsys netd trafficcontroller
Change-Id: I94efcdccfcd17f08c731caa700ea5797f2f56e7d
Add support for cgroup socket filter program loading in bpfloader,
and create a uid permission map to store the uids that have INTERNET
permission.
Bug: 111560570
Bug: 111560739
Test: dumpsys netd trafficcontroller
Change-Id: I658f533d302cb594d7b36d4a3a2a70e394874c33
Use two maps to record the details of network stats and swap and clean
up after system server pulls the stats. The kernel program checks the
bpf map currently enabled before updating the stats and updates on the
corresponding map. Remove the TAG_STATS_MAP since we don't need to worry
about uid stats overflow problem. All the stats can be stored in the
same map until system server scrapes the stats and clean it up.
Bug: 79171384
Test: dumpsys netd trafficcontroller
CtsUsageStatsTestCases
Change-Id: Ic79e382f51bf21eee78c4cac5a8a97edaf3654cd
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
