This is a no-op refactoring that splits constants and utility
methods into standalone classes which will be shared with
a bpf reader class in subsequent CLs.
NO_IFTTT=No-op refactoring
Test: atest FrameworksNetTests:android.net.connectivity.com.android.server.BpfNetMapsTest
Test: atest ConnectivityCoverageTests:android.net.connectivity.com.android.net.module.util.StructTest
Bug: 297836825
Change-Id: I6d7ea044e43180ae001573009a166be74ebe6a5d
Experiment to verify bpf map operations refactoring showed no
change of map size metrics and no system health regressions.
So this CL update BpfNetMaps to always use new code path with kill
switch.
Test: m
Bug: 217624062
Change-Id: Ic17470ac5c075884871ea2df2c13c054f5ac2929
Build/TestCop - revert this if you see failures (just document where).
It erroneously(?) doesn't appear to cause any failures in TH
on aosp/master.
Bug: 291519274
Change-Id: I78b049302ae9bd2a8db8c03e79388dc4e51e110f
Maciej Żenczykowskicommited 2023-07-18 20:09:20 +00:00
From service-connectivity, NAMESPACE_TETHERING must be used, as
NAMESPACE_CONNECTIVITY is used for the NetworkStack module. Also the
isFeatureEnabled with module name must be used, otherwise the "android"
package version is queried instead of the tethering module version.
BpfNetMaps is using flag value 1 to workaround this issue.
flags in NsdService, AutomaticOnOffKeepaliveTracker, and ConnectivityFlags
were not pushed currently.
So, this change has no effect to devices.
Bug: 279108992
Test: TH
Change-Id: I2b4b6a13c048c20beef52b1f43b9e21aca0c637a
Upcoming CLs use this method to add chain status to failure log of
ConnectivityManagerTest#testFirewallBlocking which is a flaky test
Test: atest BpfNetMapsTest
Bug: 262141231
Change-Id: Ib130a28c708f675c79b889bf293dfe6b0f8d7f60
Having SdkLevel.isAtLeastU() as a default value of
DeviceConfigUtils.isFeatureEnabled could result confusing behavior.
For example, when flag value is pushed to only the T device and the T
device with the flag is ugraded to U, this device could disable java bpf
map while the device keeps the flag value.
This CL prevents above confusing behavior.
Bug: 246218229
Test: atest BpfNetMaps
Change-Id: I615603c337bb94101dccac77ea0e6fa857041259
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
This converts the key, which is an index in an array, of sConfigurationMap from U32 to S32.
Since the array has exactly 2 elements, there's no real difference.
In addition while the kernel does indeed index arrays with U32s,
it doesn't matter, because you'd need to have over 2 billion
elements in the bpf map (at which point you'd need GBs of ram for
the bpf map itself)...
Test: TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: If17efc25d910af642e519f9ecb6d0e8695c38d42
Maciej Żenczykowskicommited 2022-09-17 06:16:34 +00:00
This converts the key, which is a uid, of sUidOwnerMap & sUidPermissionMap from U32 to S32.
The kernel is actually not consistent in whether uids & gids
are signed or unsigned, and neither is our Java code, which
also commonly uses just 'int' for uid. In practice values
greater or equal to 2**31 often don't quite work right.
For example icmp sockets are enabled via a sysctl that
takes a minimum and maximum gid - and these are signed int32s.
It's worth pointing out that these functions already accept int's
as arguments, so when converting them to U32 (and thus long) they
technically previously did the wrong thing (though it's unlikely
it ever mattered).
Test: TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I7b389a1cf822c56134b20df5ded269963f5bf69f
Maciej Żenczykowskicommited 2022-09-17 06:06:23 +00:00
These are allocated in order by the kernel, if we go
over 2 billion, we've got other problems... besides
U32 to S32 conversion will work just fine anyway.
Test: TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I6e1da81c03bd36d8c6e7bd2b33f535d1fabfad0a
Maciej Żenczykowskicommited 2022-09-16 18:34:39 +00:00
This is a preparation for the upcoming CL that will add the test for
BpfNetMaps#dump.
Bug: 217624062
Test: dumpsys connectivity trafficcontroller, atest BpfNetMapsTest
Change-Id: I79aa6f6153dc94f806411c642d72f4801915a588
Upcoming CL will update BpfNetMaps to pull NetworkBpfMapInfo atom that
contains the cookieTagMap size field.
Test: m, atest BpfNetMaps
Bug: 217624062
Change-Id: I84bb0aa56e3916fc6fc0ca31ba5962f3b9be4b6f
Switch existing C SkDestroyListener and new Java SkDestroyListener based
on the experiment flag.
Bug: 217624062
Test: atest SkDestroyListenerTest
Change-Id: I7031ba7c155edb43e0e7b77449587058d6ba38fb
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
Currently, production code uses BpfMap type and TestBpfMap extends
BpfMap but this makes it diffcult to test because TestBpfMap loads the
JNI.
This CL updates to use IBpfMap type in the production code.
Upcoming CL updates TestBpfMap to implement IBpfMap instead of extending
BpfMap so that test can still use TestBpfMap but tests do not need to
load JNI.
Bug: 217624062
Test: atest BpfCoordinatorTest BpfNetMapsTest
Change-Id: Ie67e14bf5519fb4427474ecc0fda441877a9555f
* changes:
Switch previous and new code path in replaceUidChain
Switch previous and new code path in setUidRule
Switch previous and new code path in removeUidInterfaceRules
Switch previous and new code path in addUidInterfaceRules
Switch previous and new code path in updateUidLockdownRule
Switch previous and new code path in addNiceApp
Switch previous and new code path in removeNiceApp
Switch previous and new code path in addNaughtyApp
Switch previous and new code path in removeNaughtyApp
Motomu Utsumiauthored and Gerrit Code Reviewcommited 2022-08-09 09:33:36 +00:00
replaceUidChain was updated to use Java BpfMap class instead of native JNI
functions in aosp/2145584.
But it is better to verify this refactoring by the experiment.
So this commit update replaceUidChain to switch previous code path(JNI)
and new code path(Java) based on the flag.
Also this commit removes @GuardedBy("sUidOwnerMap") from
native_replaceUidChain.
This was needed to avoid JNI and Java code modify the UidOwnerMap
concurrently when some API uses previous code path (JNI) and other APIs
use new code path (Java BpfMap class).
But, after this topic, it will not be needed because all the APIs will use JNI
"or" all the APIs will use Java BpfMap class to update UidOwnerMap.
Bug: 217624062
Test: atest BpfNetMapsTest
Change-Id: Icc264e0665b610adae5706f57fe29a296e6e6d6e
setUidRule was updated to use Java BpfMap class instead of native JNI
functions in aosp/2145583.
But it is better to verify this refactoring by the experiment.
So this commit update setUidRule to switch previous code path(JNI)
and new code path(Java) based on the flag.
Also this commit removes @GuardedBy("sUidOwnerMap") from
native_setUidRule.
This was needed to avoid JNI and Java code modify the UidOwnerMap
concurrently when some API uses previous code path (JNI) and other APIs
use new code path (Java BpfMap class).
But, after this topic, it will not be needed because all the APIs will use JNI
"or" all the APIs will use Java BpfMap class to update UidOwnerMap.
Bug: 217624062
Test: atest BpfNetMapsTest
android.net.cts.ConnectivityManagerTest#testFirewallBlocking
Change-Id: I0d293c3eb89649c969f09578639dc4cb0233501b
removeUidInterfaceRules was updated to use Java BpfMap class instead of
native JNI functions in aosp/2141539.
But it is better to verify this refactoring by the experiment.
So this commit update removeUidInterfaceRules to switch previous code
path(JNI) and new code path(Java) based on the flag.
Also this commit removes @GuardedBy("sUidOwnerMap") from
native_removeUidInterfaceRules.
This was needed to avoid JNI and Java code modify the UidOwnerMap
concurrently when some API uses previous code path (JNI) and other APIs
use new code path (Java BpfMap class).
But, after this topic, it will not be needed because all the APIs will use JNI
"or" all the APIs will use Java BpfMap class to update UidOwnerMap.
Bug: 217624062
Test: atest BpfNetMapsTest HostsideVpnTests#testBlockIncomingPacket
Change-Id: I1fb103fb3637ef324f92bbc945568ba316b164b8
addUidInterfaceRules was updated to use Java BpfMap class instead of native JNI
functions in aosp/2141538.
But it is better to verify this refactoring by the experiment.
So this commit update addUidInterfaceRules to switch previous code path(JNI)
and new code path(Java) based on the flag.
Also this commit removes @GuardedBy("sUidOwnerMap") from
native_addUidInterfaceRules.
This was needed to avoid JNI and Java code modify the UidOwnerMap
concurrently when some API uses previous code path (JNI) and other APIs
use new code path (Java BpfMap class).
But, after this topic, it will not be needed because all the APIs will use JNI
"or" all the APIs will use Java BpfMap class to update UidOwnerMap.
Bug: 217624062
Test: atest BpfNetMapsTest HostsideVpnTests#testBlockIncomingPacket
Change-Id: Idb6400ed5808f8c5f4b0a962a356ac3850fbcff3
updateUidLockdownRule was updated to use Java BpfMap class instead
of native JNI functions in aosp/2141537.
But it is better to verify this refactoring by the experiment.
So this commit update updateUidLockdownRule to switch previous code
path(JNI) and new code path(Java) based on the flag.
Also this commit removes @GuardedBy("sUidOwnerMap") from
native_updateUidLockdownRule.
This was needed to avoid JNI and Java code modify the UidOwnerMap
concurrently when some API uses previous code path (JNI) and other APIs
use new code path (Java BpfMap class).
But, after this topic, it will not be needed because all the APIs will use JNI
"or" all the APIs will use Java BpfMap class to update UidOwnerMap.
Bug: 217624062
Test: atest BpfNetMapsTest HostsideVpnTests#testBlockIncomingPacket
Change-Id: Ifd17d8a5c3a10a92c63010e5d329f9f541b3bfbf
addNiceApp was updated to use Java BpfMap class instead of native JNI
functions in aosp/2139316.
But it is better to verify this refactoring by the experiment.
So this commit update addNiceApp to switch previous code path(JNI)
and new code path(Java) based on the flag.
Also this commit removes @GuardedBy("sUidOwnerMap") from
native_addNiceApp.
This was needed to avoid JNI and Java code modify the UidOwnerMap
concurrently when some API uses previous code path (JNI) and other APIs
use new code path (Java BpfMap class).
But, after this topic, it will not be needed because all the APIs will use JNI
"or" all the APIs will use Java BpfMap class to update UidOwnerMap.
Bug: 217624062
Test: atest BpfNetMapsTest HostsideRestrictBackgroundNetworkTests
Change-Id: I27b4dccdbfee86e772049caa702853bcab8980ca
removeNiceApp was updated to use Java BpfMap class instead of native JNI
functions in aosp/2139315.
But it is better to verify this refactoring by the experiment.
So this commit update removeNiceApp to switch previous code path(JNI)
and new code path(Java) based on the flag.
Also this commit removes @GuardedBy("sUidOwnerMap") from
native_removeNiceApp.
This was needed to avoid JNI and Java code modify the UidOwnerMap
concurrently when some API uses previous code path (JNI) and other APIs
use new code path (Java BpfMap class).
But, after this topic, it will not be needed because all the APIs will use JNI
"or" all the APIs will use Java BpfMap class to update UidOwnerMap.
Bug: 217624062
Test: atest BpfNetMapsTest HostsideRestrictBackgroundNetworkTests
Change-Id: I4bbd4480fa66ea43b9244047ae34ce4b3b764e22
addNaughtyApp was updated to use Java BpfMap class instead of native JNI
functions in aosp/2138295.
But it is better to verify this refactoring by the experiment.
So this commit update addNaughtyApp to switch previous code path(JNI)
and new code path(Java) based on the flag.
Also this commit removes @GuardedBy("sUidOwnerMap") from
native_addNaughtyApp.
This was needed to avoid JNI and Java code modify the UidOwnerMap
concurrently when some API uses previous code path (JNI) and other APIs
use new code path (Java BpfMap class).
But, after this topic, it will not be needed because all the APIs will use JNI
"or" all the APIs will use Java BpfMap class to update UidOwnerMap.
Bug: 217624062
Test: atest BpfNetMapsTest HostsideRestrictBackgroundNetworkTests
Change-Id: If18c26b805081182153d1dc67bb08f1966fa4990
removeNaughtyApp was updated to use Java BpfMap class instead of native JNI
functions in aosp/2135056.
But it is better to verify this refactoring by the experiment.
So this commit update removeNaughtyApp to switch previous code path(JNI)
and new code path(Java) based on the flag.
Also this commit removes @GuardedBy("sUidOwnerMap") from
native_removeNaughtyApp.
This was needed to avoid JNI and Java code modify the UidOwnerMap
concurrently when some API uses previous code path (JNI) and other APIs
use new code path (Java BpfMap class).
But, after this topic, it will not be needed because all the APIs will use JNI
"or" all the APIs will use Java BpfMap class to update UidOwnerMap.
Bug: 217624062
Test: atest BpfNetMapsTest HostsideRestrictBackgroundNetworkTests
Change-Id: I4df6185e85f6c5512797c1b62e14aa590f4903ee
setChildChain was updated to use Java BpfMap class instead of native JNI
functions in aosp/2131752.
But it is better to verify this refactoring by the experiment.
So this commit update setChildChain to switch previous code path(JNI)
and new code path(Java) based on the flag.
Bug: 217624062
Test: atest BpfNetMapsTest android.net.cts.ConnectivityManagerTest#testFirewallBlocking
Change-Id: I47a5e7f631bb6806716f464df26ec2eca46503b3
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
Maciej Żenczykowski
commited 
Junyu Lai
commited 
Motomu Utsumi
commited 
Gerrit Code Review
commited