With the addition of special handling for SDK sandbox uids, the UID
definitions provided by this header are needed in order to compile the
mock time_in_state program for testing.
Bug: 219080829
Test: m bpf-time-in-state-tests
Signed-off-by: Connor O'Brien <connoro@google.com>
Change-Id: I92464cf76fb49bcf7490794ed5b7c07d865a7e14
BPF headers used by both platform and mainline modules should be in
frameworks/libs/net.
Bug: 202086915
Test: build and boot
Test: cd packages/modules/Connectivity/netd; atest
Change-Id: Id9ac888d5519b2a8663232610d36386cabfe4e94
This will allow shipping .o's targetting only T and not S devices.
Test: TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I651b4442625df9011ff7c5ad283943caae579565
The only purpose of this is to break cut-and-paste of examples
that use SEC() causing people to think things through, look
at Android bpf program examples and use a better macro.
In particular programs with SEC("license") / SEC("maps") need to be
changed to use LICENSE("license") and the map helpers or the map
section is wrong and cannot be correctly parsed by the bpfloader.
Generated via:
git grep 'SEC\(' | cut -d: -f1-2 | while read i; do mcedit $i; done
and manually editting found locations
Test: TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: Idb333967e054e096fe74f910a5f8aaf1d6c5dc81
This is also bpfloader v0.2.
Some newer map types (for example DEVMAP) are unusable
on older kernel versions.
Bug: 190519702
Test: atest, TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I085cc723ff1c19d8acc8972a391f894e16dd1875
It really turns out that till now we've just been lucky to not have
ever used a 64-bit type.
See also discussion on:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69560
(and other places on the internet)
Bug: 190519702
Test: atest, TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: Ibe74a6f97bdbba490a7848060d07dc3efcee0e68
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>
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>
