Information in the dump does not change
....
current ownerMatch configuration: 516 DOZABLE_MATCH OEM_DENY_1_MATCH
....
Bug: 217624062
Test: dumpsys connectivity trafficcontroller, atest BpfNetMapsTest
Change-Id: I5f7b56e4ba03256414f49d0e82d65477fb97f05a
Information in the dump does not change
....
current statsMap configuration: 0 SELECT_MAP_A
....
Bug: 217624062
Test: dumpsys connectivity trafficcontroller, atest BpfNetMapsTest
Change-Id: I42a844227f258b91ba5b368d8e8abf82a773a801
Also remove the dump of mPrivilegedUser because this is not used now and
the information is duplicated with uidPermissionMap dump.
Before this CL
....
mUidPermissionMap:
10049 PERMISSION_NONE
10027 BPF_PERMISSION_INTERNET BPF_PERMISSION_UPDATE_DEVICE_STATS
1041 BPF_PERMISSION_UPDATE_DEVICE_STATS
....
After this CL
....
sUidPermissionMap:
10049 PERMISSION_NONE
10027 PERMISSION_INTERNET PERMISSION_UPDATE_DEVICE_STATS
1041 PERMISSION_UPDATE_DEVICE_STATS
....
Bug: 217624062
Test: dumpsys connectivity trafficcontroller, atest BpfNetMapsTest
Change-Id: I416501d5a28a5443f954f9c8c58ea255e5cdc897
Map status dump will do access check if map is null.
This could show different message from the current dump output.
Information in map content dump does not change
$ dumpsys connectivity trafficcontroller
....
mIfaceIndexNameMap:
ifaceIndex=5 ifaceName=ip6_vti0
ifaceIndex=19 ifaceName=r_rmnet_data3
ifaceIndex=17 ifaceName=r_rmnet_data1
ifaceIndex=18 ifaceName=r_rmnet_data2
ifaceIndex=23 ifaceName=wifi-aware0
....
$ dumpsys netstats
....
BPF map content:
ifaceIndex=5 ifaceName=ip6_vti0
ifaceIndex=19 ifaceName=r_rmnet_data3
ifaceIndex=17 ifaceName=r_rmnet_data1
ifaceIndex=18 ifaceName=r_rmnet_data2
ifaceIndex=8 ifaceName=rmnet_ipa0
....
Bug: 217624062
Test: dumpsys netstats, atest
com.android.server.net.BpfInterfaceMapUpdaterTest
Change-Id: If182bd97f72713b6347028668cf7bd4676b8aea4
aosp/2167063 moved mCookieTagMap dump from TrafficController to
NetworkStatsService.
But this dump was used from Cts TagSocketTest.
So, this CL re-adds mCookieTagMap dump to TrafficController to avoid
failure of released Cts.
Upcoming CL will update Cts test to check dump both from
TrafficController and NetworkStatsService.
And after the old Cts support period is over, mCookieTagMap dump in
TrafficController can be removed.
Bug: 241787285
Test: atest TagSocketTest TrafficControllerTest
Change-Id: Ie2ef09fa7d91cf96f56c5efcbe9d863dd68a1020
Map status dump will do access check if map is null.
This could show different message from the current dump output.
Information in map content dump does not change
$ dumpsys connectivity trafficcontroller
....
mUidCounterSetMap:
10093 1
10060 1
1073 1
1001 1
10089 1
....
$ dumpsys netstats
....
mUidCounterSetMap:
uid=10093 set=1
uid=10090 set=1
uid=1073 set=1
uid=10089 set=1
uid=1000 set=1
....
Bug: 217624062
Test: dumpsys netstats, dumpstate, atest NetworkStatsServiceTest
Change-Id: Ia70379a3cee820f3f05d1f036947b357d9da4bd7
Map status dump will do access check if map is null.
This could show different message from the current dump output.
Information in map content dump does not change
$ dumpsys connectivity trafficcontroller
....
mCookieTagMap:
cookie=1398 tag=0x0 uid=1029
cookie=1433 tag=0xffffff82 uid=1051
cookie=1166 tag=0xfffffe01 uid=1073
$ dumpsys netstats
....
mCookieTagMap:
cookie=1144 tag=0xfffffe01 uid=1073
cookie=1376 tag=0x0 uid=1029
cookie=1408 tag=0xffffff82 uid=1051
Bug: 217624062
Test: dumpsys netstats, dumpstate, atest NetworkStatsServiceTest
Change-Id: I14dd6f969a0b5eb24ace62361ce2484cf18b7470
This eliminates the need for netd_updatable BpfHandler.cpp
to initialize the hash map with a zero.
On startup the map will be freshly initialized and thus zero.
On restart it might not be empty, but it doesn't matter to netd.
Furthermore the mainline component of the system server will
re-initialize it again anyway:
see service/native/TrafficController.cpp initMaps()
This does remove the ability to call deleteValue on a key,
since that would always return -EINVAL, but since we don't
currently do that, that's really a feature.
(It does suggest though that we should have a BpfMapNonNullable
class which is writeable, but without a deleteValue() function)
Additionally BpfMap arrays are more efficient for the kernel bpf jit
compiler, as - on newer kernels - it can optimize the read/write
into a simple memory access (as opposed to a bpf helper call).
Before:
$ adb shell ls -l /sys/fs/bpf/netd_shared/map_netd_configuration_map
-rw-rw---- 1 root net_bw_acct 0 2022-06-11 08:20 /sys/fs/bpf/netd_shared/ map_netd_configuration_map
After:
$ adbz shell ls -l /sys/fs/bpf/netd_shared/map_netd_configuration_map
-r--rw---- 1 root net_bw_acct 0 2022-06-16 15:03 /sys/fs/bpf/netd_shared/map_netd_configuration_map
Bug: 235590615
Test: TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I21730e4fa22fbf0c94ab0ca5c5db03aa000b7680
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
dump function has no enough code coverage for error handling.
Add a simple unit test so that code lines can be executed and counted.
Test: atest TrafficControllerTest
Change-Id: I65a322cc93d559896f0b481ca849b39315432df3
uidMatchTypeToString function has no enough line coverage currently.
Add a simple unit test so that code lines can be executed and counted.
NO_MATCH(0) can't be verified because match type flag is added by OR
operator. See TrafficController::addRule.
Bug: N/A
Test: atest
Change-Id: I6178d4a8cc21430882fae3c1f53f7bc1cebb6c01
Add more values in different maps to cover more code lines in dump
function.
The original test code is also modified to have one entry per map.
Because the entries are hashed in the map. The order of each entry is
not a fixed order.
Bug: N/A
Test: atest
Change-Id: Ie21016768309e8501a127cb3da02211d21b06c2c
Dump function has no code line coverage currently. Add a simple unit
test so that code lines can be executed and counted.
Bug: N/A
Test: atest
Change-Id: I6362a679d11c26be66ab49216666f0f8c6f2c4f0
BpfMap.reset(createMap()) is equivalent to newly added BpfMap.resetMap(),
except that the latter makes it impossible to screw up the Key/Value sizes.
Test: TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I290986e9ae8660f3fc6f73b086d33f4ab93d6095
We notice that:
BpfMap.reset(dupFd_with_cloexec(BpfMap.getMap())
is equivalent to
BpfMap = BpfMap
due to the current implementation of the BpfMap assignment operator.
Except the latter also verifies BpfMap<K,V> template types match.
Test: TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I99fcf77bc6aa360b6a19e22c2cd58d67a1e62976
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
(for consistency with rest of code base)
Test: TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I5660615f24daf4285e2b6cbacecb7cd99061c5f5
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
netlink_listener_test tests the socket destroy listener, so it makes
sense to just merge it into the TrafficControllerTest.
Test: atest traffic_controller_unit_test
Change-Id: Ibc0b483203150aa2d7898a761fa4715dce6f4218
Delete tagSocket(), privilegedTagSocket() and untagSocket() revelant
test cases since thay are moved out of TrafficController in
aosp/1849156.
Bug: 202086915
Test: atest traffic_controller_unit_test passed
Change-Id: I605577ee4d7076f0c8ad75888a4d32bff90f6104
Delete tagSocket(), privilegedTagSocket() and untagSocket() since
they are moved out of TrafficController in aosp/1849156.
Test: m
Change-Id: I6162c758446f597eb79734e00348dc8b1fe2d422
