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
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
netd makes sure netd can open all bpf programs at startup and exit if it
fails.
So, program status is always OK if netd starts successflly.
Bug: 241787285
Bug: 217624062
Test: atest TrafficControllerTest, dumpsys connectivityservice
trafficcontroller
Change-Id: Ida29dcbb2612e84f7030389050e2a3d2830c73ff
status dump was removed in aosp/2167962 and aosp/2165825.
But TrafficController still open these maps in init and hold them, so
dump should show the status of them.
Bug: 217624062
Bug: 241787285
Test: atest TrafficControllerTest, dumpsys connectivityservice
trafficcontroller
Change-Id: Icc1f255a619b22174abb2a7d323b7e3c4d42909f
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 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
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
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
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
In order to get counted by mts code coverage, this native test needs to
be run as part of mts.
Bug: 233904825
Test: m mts && mts-tradefed run mts-tethering-coverage
Change-Id: I4ec7108577a8a50d4419bbf387535f92f2f6d099
In order to get counted by mts code coverage, these native tests need to
be run as part of mts.
Bug: 233904825
Test: m mts && mts-tradefed run mts-tethering-coverage
Change-Id: I79313197b146c7043ffb5e164faa46c2e16dd1d2
(for consistency with rest of code base)
Test: TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I5660615f24daf4285e2b6cbacecb7cd99061c5f5
