This leaks (what should be) an internal only fd.
There's still multiple uses of getMap() left in:
common/native/bpf_headers/BpfMapTest.cpp
Test: TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I87a36f3f935ba9148ae4456fc6bf14b0e04f6038
in particular base::Result is needlessly verbose
Test: TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: Ide0de9acec79b9aeeaff7ec92270304907bd10d4
Example use case:
BPF_LOAD_SKB_PROTOCOL,
BPF2_ACCEPT_IF_EQUAL(ETH_P_ARP),
BPF2_REJECT_IF_NOT_EQUAL(ETH_P_IP),
BPF_LOAD_IPV4_BE16(frag_off),
BPF2_REJECT_IF_ANY_BITS_SET(IP_MF | IP_OFFMASK),
BPF_ACCEPT,
which is a sample program which accepts ARP plus non-fragmented IPv4.
Test: TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: Ibe6f9f7941f11bc7b767a092d3d108fa0291f360
The one in this file requires libbinder and cannot be used when
libbinder is not present (e.g., when compiling against the NDK).
This allows users of this code not to link against libbinder, and
have the resulting binary not depend on it:
$ m CtsNativeNetPlatformTestCases netd_integration_test
$ objdump -p out/target/product/vsoc_x86_64/testcases/netd_integration_test/x86_64/netd_integration_test64 | grep NEEDED | grep libbinder
NEEDED libbinder.so
NEEDED libbinder_ndk.so
$ objdump -p out/target/product/vsoc_x86_64/testcases/CtsNativeNetPlatformTestCases/x86_64/CtsNativeNetPlatformTestCases64 | grep NEEDED | grep libbinder
NEEDED libbinder_ndk.so
$
Bug: 268440865
Test: see other CL in topic
Merged-In: Icf982675aad4777677a36e357035809fb251d6e9
Change-Id: Icf982675aad4777677a36e357035809fb251d6e9
While at it enforce a min/max of 4 kiB and 256 MiB.
A bpf ringbuffer must be an integer multiple of page size
(which is at least 4kiB), so 4kB is forced.
256 MiB upper limit is probably higher than it should be,
but it's really only here to avoid the u32/s32 conversion
mess that happens for 2+ GiB.
Test: TreeHugger
Bug: 279819914
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I2216d2273b0956a86c4222dd6ecf7293e0bafd41
This allows it to be used from outside this header file,
and provides slightly more type safety.
Test: TreeHugger
Bug: 286369326
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I98e5e37a002188813b602e51fd4fcbb9ca4466cc
x86 has 2 obvious ABIs:
32-bit registers/pointers/system calls (i386/i486/i586/i686)
64-bit registers/pointers/system calls (amd64 / x86_64)
but there also exists a third:
the memory optimizing hybrid 'x32' which uses 64-bit registers,
with 32-bit pointers, and 64-bit system calls (with minor tweaks).
(there is also technically an aarch64/arm64-ilp32 ABI mirroring x32)
Note: It would probably be trivial to add support if we wanted to.
Test: TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I82138c5bafbc3bd37cad98eeb79441701d94c386
Consumer pos is only written to by userspace (except for
initialization), so reading from it does not require a memory barrier.
This change also moves producer pos to be acquired before anything else
and marks start_ptr as volatile, so it is only read once.
Test: atest BpfRingbufTest
Change-Id: I228578ef4b42c1732646f0ae928b9a0aa2445304
This change adds support for 32 bit kernels by capping mProducerPos to
4 bytes. mConsumerPos (which is written to by userspace) continues to
use 8 bytes. (This can be done because an entire page is allocated for
mConsumerPos to control access permissions). In a 32 bit kernel, that
means that the top order bits are just ignored. In addition, comparisons
in userspace only use the bottom 4 bytes to be bitness agnostic.
Test: atest BpfRingbufTest
Change-Id: I7fe6d9000a151512785f1aa2a53fa97d31967d19
Both consumer and producer position are wrapped in an std::atomic and
extended to uint64_t to enforce atomic access.
See resulting assembly instructions for aosp_cf_x86_phone-userdebug:
frameworks/libs/net/common/native/bpf_headers/include/bpf/BpfRingbuf.h:212
2d: 8b 41 18 mov 0x18(%ecx),%eax
external/libcxx/include/atomic:926 (discriminator 4)
30: f3 0f 7e 00 movq (%eax),%xmm0
This will not work on a 32 bit kernel (so we might want to explicitly
check for that in the test).
Test: atest BpfRingbufTest
Change-Id: I7fec435cbe49d392363d05f7e702d82ecacb9e91
I found this comment in aosp/2103424 helpful in figuring out the correct
selinux domain for a newly added map.
Test: documentation only change
Change-Id: I96c06ff33605c8ed3f2ae6e8810bbcdc8e66b51b
These were copied from
system/core/libsysutils/src/NetlinkEvent.cpp and the following changes
were applied:
- Mark isUserspace64bit as constexpr.
- Added __unused annotations
- Fixed a typo (s/meaningul/meaningful)
Test: TH
Change-Id: Ia0b8e6e02daca7e9b69f337a494d88eb1beffc22
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
