This CL prepares for upcoming CL.
Upcoming CL will add SkDestroyListener with Java BpfMap and switch
current C SkDestroyListener and new Java SkDestroyListener based on the
experiment flag.
Bug: 217624062
Test: atest SkDestroyListenerTest
Change-Id: I5ebb319d1b2262199d4ef6a3549894fee24c4ccf
Hitting this abort() likely means map initialization failed,
and basically things won't work correctly.
Another possibility detected on wembley is a kernel bpf bug
which prevents writes into index != 0 of bpf array maps.
But such a kernel bug will make TC useless.
Best to abort() and cause a mainline module rollback.
Test: TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: Iddb9b32944f1cddc299d2af3dd8c2eb9c84f94a3
This reverts commit b1144d7671.
Reason for revert: We decided to have experiment and switch old code path and new code path based on a flag. So the codes removed by this CL is needed.
Bug: 217624062
Test: m
Change-Id: Icb8a353a74935ed97f8e102ba54020825676b817
Previous commit update BpfNetMaps#setChildChain to use Java BpfMap.
This commit remove the code that is no longer used due to the previous
commit.
Bug: 217624062
Test: atest BpfNetMapsTest android.net.cts.ConnectivityManagerTest#testFirewallBlocking
Change-Id: I02656096c8752daf20d3578f209778c5adae9b0c
LOCKDOWN_VPN was in the FirewallChain IntDef but this was not a right
place because LOCKDOWN_VPN was not a valid value for Connectivity APIs
that take an argument annotated with @FirewallChain(setUidFirewallRule,
setFirewallChainEnabled, replaceFirewallChain).
LOCKDOWN_VPN was in the FirewallChain IntDef because
BpfNetMaps#setUidRule was used to add/remove LOCKDOWN_VPN entries.
This commit adds BpfNetMaps#updateUidLockdownRule and uses this to
add/remove LOCKDOWN_VPN entries instead of BpfNetMaps#setUidRule and
removes LOCKDOWN from FirewallChain.
Bug: 206482423
Test: atest TrafficControllerTest ConnectivityServiceTest
PermissionMonitorTest HostsideVpnTests#testBlockIncomingPacket
Change-Id: Iff9b9792fc0f208f153e10e396c6d5034b412d7c
(a) jni static methods take 'jclass clazz' as 2nd argument,
while non-static methods take 'jobject this/thiz/self'
(b) use a macro for error handling to remove duplicate code
(c) also fix some whitespace
Test: TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I2773617dc7129efb87e28266f97ec3e01a35efc3
Currently, even when VPN Lockdown mode is enabled, incoming packets are
not dropped if VPN is not connected.
This commit fixed this issue.
After this commit, If VPN Lockdown mode is enabled, incoming packets
are dropped regardless of the VPN connectivity.
Bug: 206482423
Test: atest TrafficControllerTest ConnectivityServiceTest PermissionMonitorTest
Change-Id: If52ece613c8aac1073355e43b6fb9cb3fcc87d1d
We are ready to remove traffic controller from netd, so
TrafficController::start() should be called from the system server.
This reverts commit c2984fdca8.
Test: atest FrameworksNetTests FrameworksNetIntegrationTests
CtsNetTestCases:android.net.TrafficStatsTest NetworkUsageStatsTest
CtsHostsideNetworkTests
Change-Id: Ic324ad0c064271977ab35d7f55badee00098e196
TrafficController is currently still started by netd, and this should
not happen in two places. Instead, native_init should init (open) the
maps.
Test: atest FrameworksNetTests
Change-Id: Ifd6be50aa5f62e59a5b1c5c0a97550389fd0e7e1
There is not really a point to separate these two as they are all used
in ConnectivityService.
As a future TODO, we might want to rename libservice-connectivity to
libcom_android_server_jni to be more inline with the jarjar'ed jni lib
versions.
Test: atest FrameworksNetTests:ConnectivityServiceTest
Change-Id: I1b9f4fde345038bda6b3ffcf8e3f47cf9262e052