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
addInterface and hasUpdateDeviceStatsPermission are not used
Test: m & flush & boot
Bug: 217624062
Change-Id: I8a0f84f607a4f35512bc72e732df8f689b8ed1c9
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
In the BPF code, per-UID network access (e.g., for doze mode,
standby, etc.) is stored in UidOwnerValue structures. Each of
these stores that UID's rules in a 32-bit bitmask of
UidOwnerMatchType values, so the code can support ~31 match
types.
However, which match types are enabled is stored in
configuration_map at index UID_RULES_CONFIGURATION_KEY, and
configuration_map only stores 8-bit values. So it's not
possible to define more than 7 match types.
Widen configuration_map to from 8 to 32 bits to match the width
of UidOwnerValue.rule. This doesn't impact memory because
configuration_map only has 2 entries.
Bug: 208371987
Test: TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I7e1eee2daedd66d27965a2dd4ce6b4c3667892f7
Lorenzo Colittiauthored and Maciej Żenczykowskicommited 2022-05-31 09:59:11 +00:00
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
Tethering module.
Delete tagSocket(), privilegedTagSocket() and untagSocket() since
they are moved out of TrafficController in aosp/1849156.
Bug: 202086915
Test: m; flash; boot;
Change-Id: Ifeaeb060fbf1add9f06748e7846b9e11e0345bda
Delete tagSocket(), privilegedTagSocket() and untagSocket() since
they are moved out of TrafficController in aosp/1849156.
Test: m
Change-Id: I6162c758446f597eb79734e00348dc8b1fe2d422