we can't use java for this, because pre-U-QPR2 does not include:
https://android-review.googlesource.com/c/platform/system/sepolicy/+/2821590
system_server dontaudit key_socket getopt
so we'll spew lots of:
11-08 07:52:43.776 1469 1469 I auditd : type=1400 audit(0.0:4): avc: denied { getopt } for comm="system_server" scontext=u:r:system_server:s0 tcontext=u:r:system_server:s0 tclass=key_socket permissive=0
11-08 07:52:44.360 1469 1469 I auditd : type=1400 audit(0.0:5): avc: denied { getopt } for comm="NetworkStats" scontext=u:r:system_server:s0 tcontext=u:r:system_server:s0 tclass=key_socket permissive=0
11-08 07:52:44.508 1469 1469 I auditd : type=1400 audit(0.0:7): avc: denied { getopt } for comm="android.bg" scontext=u:r:system_server:s0 tcontext=u:r:system_server:s0 tclass=key_socket permissive=0
and the like.
This is due to Java's Os.close() in:
libcore/luni/src/main/java/libcore/io/BlockGuardOs.java;l=100
calling:
if (fd.isSocket$()) if (isLingerSocket(fd)) ...
Test: TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: Ib87fa5e8f0dfd9fbbccb25fb58a9fa78d6a07111
Returning the number of the file descriptor isn't actually useful since
it doesn't really tell you anything once the program has terminated.
(most logs we look at are long after the fact)
However, it does involve a fair bit of string processing to generate
the errors. This is particularly an issue for things we constantly
call and sometimes expect to fail. For example it is normal for
getNextKey() to fail with ENOENT at the end of iteration...
Test: TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: Ib94037440b5fcaa34cc8aa01b165431efabeb377
(mostly to improve code coverage)
We can always revert if it ever turns out this is useful,
but I'd prefer for cgroup attach to be a once-at-boot
thing and handled either from bpfloader or the netd updatable
which are both directly C++ code.
Test: TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I79b5ca8a47388cb6b9189234942e74ab6056aab9
Mainline no longer supports Q.
These files were recently moved into p/m/C as part of a refactor.
Test: TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I0f06ace921db6c79d63c0048bdb73d167ff606cf
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