This reverts commit fbe95d914c707c34d2c9d150a467d51c73414fcd.
Reason for revert: I've reconsidered. This is a bad idea.
(and there are not yet any users)
The NetworkStack is an apk, not an apex, and as such it cannot
ship any bpf .o files (since that requires apex disk image format
instead of apk/jar zip file format).
There's no support for this (NetworkStack shipping bpf) in the
current tip-of-tree bpfloader.
As such there's no chance of this happening before V.
And even in V+ it is *super* unlikely, because... apk...
(We'd have to add apk zip traversal into the bpfloader...)
As such NetworkStack cannot possibly own any bpf programs/maps,
and could only potentially access platform/system bpf maps or
bpf maps owned by another module (ie. the Tethering apex).
Using any bpf maps from the system is not viable, as these
are owned by the platform, and as such may be modified by
vendors/oems. Ie. their number, names, key/value layout, etc...
cannot be guaranteed. As such using them from mainline
code is simply not safe.
Furthermore none of the platform bpfs are network related
(and indeed bpfloader enforces this).
As such this the only potential use of this would be
for NetworkStack to use Tethering apex bpf maps/programs.
However, this is also unsafe.
On older devices (pre-S) we don't even have support for
tethering apex shipped programs/maps.
On pre-T only the offload program is shipped, while
roughly equivalent netd.o maps/programs for the other
stuff are still provided by the platform.
(but the format of these cannot be relied upon)
As such use would have to be limited to T+.
(because the offload bpf map isn't interesting
to the network stack)
But on T+ we run into a cross-module versioning problem:
the source (and thus bpf map name/format/struct definitions)
used to build the NetworkStack apk and Tethering apex may differ.
Even modules shipped in tandem are build from separate release branches. Additionally there's potential for only one module
to update, while the other remains older. Thus making this
work cross-module would require freezing the map name & format.
ie. they would need to become cross-module API.
This is not something I'm willing to do.
Basically, this can be summarized as:
there is no *safe* way for NetworkStack apk to use bpf maps.
Test: TreeHugger
Bug: 276230058
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I65ecf6ffca6ae88a1b72f6f4c8a5739991d78fe3
When loading BpfMap class, JNI part is needed for native
methods. Allow the static lib can be compiled with NetworkStack
JNI library.
Test: atest FrameworksNetTests:android.net.connectivity.com.android.server.BpfNetMapsTest
Bug: 276230058
Change-Id: I72ebe801dacd02de6711558d2058c1b756cf3080
(they're only of historical interest at this point)
Test: TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I0e52efda62626091c3023c5fd3622ffcdcd00ee1
This is the default for BPFLOADER_MIN_VER if not otherwise specified.
This does not affect mainline code, see:
cs/p:aosp-master file:packages/modules/Connectivity/bpf_progs define.*BPFLOADER_MIN_VER
Test: TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: Ice5b14c3b580653f8889a5292abaa89cf8434da1
Since it just came up again, and I just verified this still works
Test: N/A
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I292c94cf9af63488ed30a6ac367ac83c8912e97e
main change is checksum of zero buffer is now 0 instead of
the equivalent, but technically incorrect 0xFFFF.
Test: TreeHugger
Bug: 265591307
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I1a8b0ace704009f82d3b7ad1c299bf8a6d8964d8
(and a few minor cleanups while at it)
Test: TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I657c3314fb0ad2519dc4d1b0743e1be6a81a887a
This implements the bare minimum to read from BPF ring buffers in
userspace. The implementation uses two shared memory regions with
atomic-like access. Currently, the class only guarantees that the
element type has the same size (later can add btf support).
The alternative would be to use libbpf or bcc, but since this is a small
header-only library that seemed like it could end up being more
difficulty than it was worth.
Bug: 246985031
Test: atest libbpf_android_test
Change-Id: I7f08e76db9cb9672ef66c629bccb3db63d3c2229
This is similar to https://r.android.com/2374598 for maps.
Bug: 246985031
Test: build connectivity module
Change-Id: Id4c9f93b69e808d461b4554bf3fa591828635dd1
This updates the ringbuffer and program helpers to allow specifying
which platform builds they are ignored on. In order to use this, you
must specify a min loader version >= 0.32, so the helpers also add
options for setting this at the program/ringbuf level.
Bug: 246985031
Test: tethering build & install, full platform build & install
Change-Id: I6bf9f7945c3fbac8fd4e02b5805016ac275b7884
see kernel's
samples/bpf/bpf_helpers.h
or
tools/testing/selftests/bpf/bpf_legacy.h
Test: TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: Id331fb9abcd87df8bf87c5a86749acf0144ffbde
This is basically a no-op, but will make future compatibility checks easier.
The programs/maps already won't load on a bpfloader outside of
this range, as the entire .o will be skipped.
Test: TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I0669c7ff9e04e24a8da68aa821c9ad705a8f5a93
(this should avoid kernel reading/writing from out of bounds)
Test: TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I71fe71eee4e4e6a917477eef5fd2266439e803f3
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: I5cd9725ad8f133c98c86e6ba620a266313055157
There is only user left, let us simply move the macro
definition into the resolv_integration_test.cpp file.
Test: TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I6eb66abaa7f6392ab43300e5087e4277491e44c9
This adds a BPF program with a ring buffer and an associated test that
ensures the program and ring buffer can be loaded by the bpf loader. In
the following changes, this foundation will be used to test the user
space ring buffer wrapper class.
Unlike BpfMap, userspace can't (easily) write to the ring buffer so the
most accurate way to test a userspace ring buffer implementation is to
write to it from a BPF program.
Note: the BPF program in this change is never actually attached to a
cgroup, it is only loaded. The program will be executed manually using
BPF_PROG_RUN which is "side-effect free" (it can have side effects on
BPF maps, but not on Kernel state, e.g. dropping packets).
Bug: 246985031
Test: atest libbpf_android_test
Change-Id: Ib9c591218188f5f358a755c8854bc6f87d26af12
_EXT suffix is used for the all-args versions of these, such as the one
here.
Bug: 246985031
Test: build and flash on 4.19 and 5.10
Change-Id: Ibd76cbdc38f4d1f9df4f440147e5f18d9a2ea026
BPF ring buffers are defined like maps, but cannot specify a key or
value size (attempting to do so is a verifier error). This change also
adds the type-safe methods for interacting with the map (output, reserve
and submit).
Bug: 246985031
Test: local run of Network Tracing w/ ring buffers
Change-Id: Ie8a47d987be6cb219fe7d73f2c61a56e3a3ab21a
as this does not appear to be used anywhere anymore
Test: TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I6905c6fdb4daf48df07e758481368d441637ad13
as this does not appear to be used anywhere anymore
Test: TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I95939b0b6c66f41f776ca31ea7178bb30241b81f
See 5.12+ kernel's include/uapi/linux/bpf.h
(note that since bpf is 64-bit, int and long are the same thing)
Test: TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: Ib340a619645ad5ab8e41ff76cb7b51671f496bc5
(also note the program in p/m/C netd.C is not optional or kernel version dependent)
Bug: 237030932
Test: TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: Ia984f6a1ce0ab14a204fe47ec295db1363879b7b
Non platform ones (ie. shipped via mainline) already have
the value manually specified.
The goal here is to be able to do some bpf.o validity checking
in the bpfloader based on the bpfloader_min_ver.
Such validity checking really only makes sense for mainline
shipped bpf.o's which might need to load on older bpfloaders.
Hence we no longer want platform bpf.o's to have minver == 0.
Test: TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I9e2f670c48e30818689a42bc515eb49e86f3cbea
