A new firewall chain is needed to configure background network
restrictions for apps.
This change only adds the API stubs and traffic controller constants to
make the chain work. Policy changes using this chain will follow in
the framework code.
Test: atest CtsNetTestCases:ConnectivityManagerTest
Test: atest ConnectivityServiceTest
NO_IFTTT=The Lint rule along with the relevant code in Common.h is
being deleted in aosp/2819759
Bug: 304347838
Change-Id: I33e2db6671431f7c576fc931d9f96e684fc1e78a
Make ADnsHelper_isUidNetworkingBlocked() to reference 'metered'
information and Data Saver related BPF maps to make the final decision.
Bug: 288340533
Test: atest dns_helper_unit_test
Change-Id: I51b1dadd56a8d6fda3f8b18d64740e52b76e1bfe
The library provides an init function and an API for DNS resolver to
query whether the application is allowed to send DNS query based on BPF
maps settings.
Bug: 288340533
Test: atest dns_helper_unit_test (with test CL)
Change-Id: Ibfb383bfb074da2104a25aa4f04ebc32b22d11da
The information is needed by modules who want to know whether a
specific UID is blocked by Data Saver feature.
1. Add a one-element map data_saver_enabled_map.
2. Update current data saver setting to the map.
Bug: 288340533
Test: atest FrameworksNetTests:android.net.connectivity.com.android.serv
er.BpfNetMapsTest
Test: atest bpf_existence_test
Change-Id: I981da4b569247c33cba2d365cb6f2691f673474e
1. Move it to header file so that it can be reused by others.
2. Correct the return type from int to bool.
3. Replace __always_inline by inline to avoid -Werror,-Wunused-function.
Bug: 288340533
Test: build
Change-Id: I9062686d9c2f98c2d24e4673f82b1732b180ffc4
BPF needs upstream prefixes information to filter spoofing IPv6 source
addresses carried in downstream traffic.
We retrieve prefixes from upstream interface's LinkProperties and pass
it to the BpfCoordinator. Forwarding rules will also be updated when
upstream interface's IPv6 link addresses change.
Test: atest TetheringTests
Bug: 261923493
Change-Id: If8cfc3b191e520ca838654d1b5211ab9e9ec021d
UidOwnerMatchType Java definition moved from BpfNetMaps.java to
BpfNetMapsConstants.java in change I6d7ea044e43180.
Bug: 297836825
Test: presubmit
Change-Id: I4fc28406750cac9143ea47e9304b455ab616d462
funky naming 'stream.down', because downstream.downstream is just too long...
Test: TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: Id234654fa8960e7430fc33119f36fd94b858d242
(reversing logic, as 'rawip.rawip' is much shorter then 'ethernet.ethernet')
Test: TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: Ib48cc2b889e8b587e14edbe89606f887a884af87
Generated via:
for f in bpf_progs/{block,dscpPolicy,netd,offload,test}.c; do
sed -i -r 's@KVER[(]([45]), ([0-9]+), 0[)]@KVER_\1_\2@g' "${f}"
done
Test: TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I8f211e47bf259fc75aa1caaaf82f41c1929ceab2
(in preparation for moving it into netbpfload)
The programs themselves (in bpf_progs/block.c) required a 5.4+ kernel.
We relax this restriction to 4.19+ as we don't have any 5.4 device coverage
(while the pixel 4a 5G / 5 / 5a are all 4.19 devices).
I believe we could relax it further to 4.14+ but Pixel 4/4xl/4a that
would exercise those code paths are EOL and probably have poor to
non existent test coverage, and we cannot do anything for 4.9 T devices
anyway.
Note: on <4.19 kernels (ie. T devices running 4.9/4.14, U running 4.14)
this results in ConnectivityNativeService going from null to initialized
(as the bpf map will exist).
This doesn't hurt as the set/clear port interfaces are only ever
called by vendor code on devices where the kernel doesn't support
the older mechanism. And even if you call them it will just set/clear
the bits in the bpf bitmap, they just won't actually affect anything.
We could flag the map itself as being 4.19+ as well, but I think
I prefer the no-op map to exist...
Test: TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I1085addd22f4f3b709e1875049633832c5dac836
use them & IGNORE_ON_* LOAD_ON_* as needed.
Test: TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: Ibadd782d289e6a2ce1467778a1930c6f1b609f98
tm-mainline-prod is no longer in use
Test: TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I8704dccff1432ba811e99a89ea60028fd63365b5
Network tracing was only available on userdebug and eng builds. This
change makes it available on all build types behind a flag.
Bug: 298197881
Test: flash & trace, toggle flag on/off
Change-Id: I75d854aee74adf7e23f7a970b20233790f9b0354
As an inline function, the logic can be reused by others.
Bug: Bug: 288340533
Test: build; presubmit
Change-Id: I8e57829e304e829eed72cc165b051cd22088260d
This is based on network driver populated skb->mark magic bit.
This is the bit used by netd's WakeupController.
We mandated the location of this bit in U, though we haven't
(yet??) mandated it being supported by all network drivers.
If the driver doesn't support it, it could always
be false (skb->mark should default to 0),
or potentially (this is very very unlikely) be garbage.
IFIRC nettrace isn't enabled on pre-U devices anyway.
Test: TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I2b3b91315d77c08c022396253b26954593dd3f5a
Due to try_make_writable's implementation:
// try to make the 1st 'len' header bytes r/w via DPA
void try_make_writable(struct __sk_buff* skb, int len) {
if (len > skb->len) len = skb->len;
if (skb->data_end - skb->data < len) bpf_skb_pull_data(skb, len);
}
This *should* normally result in nothing actually being done.
This is because the 'len' we request should trivially be <= skb->len
(by virtue of how we construct the packet / get here),
and because skb->data_end - skb->data < len was previously
(to this patch) already checked below in line 251
(and thus the packet would have been dropped if it was false).
However, there's a tentative theory that we could somehow end up
with the entire payload in the non-linear portion of the packet,
and thus need to move it into the linear header portion where
we actually have direct packet access to it.
Note also that we already called this in line 71, so it should
be safe to add another call without causing bpf verifier unhappiness...
Test: TreeHugger
Bug: 298879031
Signed-off-by: Maciej Żenczykowski <maze@google.com
Change-Id: If3531c3cf6932ac3f1d384a43d28326d17544aa3
On ingress:
(a) the socket is not a normal socket (it's AF_PACKET)
and thus (likely) doesn't hit this code path
[if it did... we'd have double or more accounting
of any traffic captured by AF_PACKET sockets,
I haven't checked - but I assume that doesn't happen]
(b) is created by the system server (so not AID_CLAT)
(c) is not tagged by the system server (so not AID_CLAT)
So this is a no-op, but it simplifies the bpf program,
since 'egress' is a compile time evaluated constant.
Test: TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: Iec693548789eb2752f9f30038e72e35c876f986c
while this is a little bit more code,
it seems much better for the accumulation operation
to be next to the struct definition itself
(in case we ever add more fields)
Test: TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I26022db4566e69c964298d7b3f2cc4fa4a9a5152
(next step is to replace use of Stats struct with
identical (except field order) StatsValue struct)
Test: TreeHugger
Bug: 294604315
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I9be3c411f9592bf4edc75386b1c5b386ebeb5905
This patch is based on aosp/2535559 from maze@.
Add source prefix into the upstream key such that only packets which
source IPv6 address matches it will be forwarded to the upstream
interface.
In this patch, the source prefix is set to zero so there is no
behavior changes. Next CL in patch series will use the real source
prefixes retrieved from upstream interface.
Test: atest TetheringTests
Bug: 261923493
Change-Id: I43d068a29b937c7dfeb6fab632a8effb47ee2263
This is trivial - as the UDPLITE pseudoheader is identical
to the UDP pseudoheader (except that the UDPLITE pseudo length
is derived from the IPv4 total length / IPv6 payload length
field, instead of being copied from the UDPLITE header 'coverage
length' field - but this doesn't matter, as it [ie. the udplite
payload length] doesn't change during 464xlat translation).
Additionally UDPLITE never sends a checksum value of 0,
as at least 8 bytes (the UDPLITE header) *must* be included
in the checksum field, and a 0 must be sent as 0xFFFF.
See: https://datatracker.ietf.org/doc/html/rfc3828
Test: TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I00a110b793fcf3cf705a9a706811da7866c3e810
This is to cut down bpfloader boot time.
Potential savings might be on the order of 30+% (300ms).
Loading BTF requires fork-execing the btfloader,
and currently BTF is only used to facilitate debugging.
Bug: 286369326
Test: TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: Ifa5f0052135b9dc826b18ca4622784615ed9c3c8
It is just a constant source of bugs, with no real tests,
let's stop pretending this is a supported configuration.
The only tested configuration is out-of-process tethering
updatable apex.
Test: TreeHugger
Bug: 279942846
Change-Id: I4b659a3cd32b89a65549b56006b926a5ac755f7b
Android T beta3/4 haven't been tested in ages,
and were really only tested for the transition to final T
nearly a year ago.
Test: TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I520e60026179c078859572231b86184796182142
