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
(this should avoid kernel reading/writing from out of bounds)
Test: TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I71fe71eee4e4e6a917477eef5fd2266439e803f3
We switch back to int from ParcelFileDescriptor,
and eliminate all calls to close(). Bpf Map FDs
now live till process exit.
Bug: 230880517
Test: TreeHugger, atest com.android.networkstack.tethering.BpfMapTest
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I89b6dc88ea56cb1e50695f8daf54ed79bce3fba2
This way, users of libnet_utils_device_common_bpfjni do not also have to
separately list the required libtcutils.
Test: build, boots
Change-Id: Id40863de83b6c40b79f38d638299626f7e025810
1. Separate bpf and struct libraries from netlink library.
2. Rename bpfmap jni library to respect its java side library.
3. Add README to explain the rules of adding shared jni library.
4. Also allow packages/modules/Connectivity to use bpf library.
Bug: 205088391
Test: atest TetheringTests
atest CtsTetheringTest
atest TetheringPrivilegedTests
atest ConnectivityCoverageTests
Change-Id: I6e668818bede63b241cd901c0967f401613ddaf6
Multiple packages need access to bpf maps. Moving to common
location to allow access from all necessary packages.
Test: atest BpfMapTest
Bug: 179733303
Change-Id: Idae7b620c15c781b2e7980c3a3157f396cfaf66e
