blob: 04d9b81081d968eb60a50452fbed8efb102738d9 [file] [log] [blame]
Maciej Żenczykowski6bd207e2020-06-19 18:12:25 -07001# zygote-start is what officially starts netd (see //system/core/rootdir/init.rc)
2# However, on some hardware it's started from post-fs-data as well, which is just
3# a tad earlier. There's no benefit to that though, since on 4.9+ P+ devices netd
4# will just block until bpfloader finishes and sets the bpf.progs_loaded property.
5#
6# It is important that we start bpfloader after:
7# - /sys/fs/bpf is already mounted,
8# - apex (incl. rollback) is initialized (so that in the future we can load bpf
9# programs shipped as part of apex mainline modules)
10# - system properties have been set, this is because isBpfSupported() calls
11# getUncachedBpfSupportLevel() which depends on
12# ro.kernel.ebpf.supported, ro.product.first_api_level & ro.build.version.sdk
13# - logd is ready for us to log stuff
14#
15# At the same time we want to be as early as possible to reduce races and thus
16# failures (before memory is fragmented, and cpu is busy running tons of other
17# stuff) and we absolutely want to be before netd and the system boot slot is
18# considered to have booted successfully.
19#
20on load_bpf_programs
21 # Enable the eBPF JIT -- but do note that on 64-bit kernels it is likely
22 # already force enabled by the kernel config option BPF_JIT_ALWAYS_ON
23 write /proc/sys/net/core/bpf_jit_enable 1
24 # Enable JIT kallsyms export for privileged users only
25 write /proc/sys/net/core/bpf_jit_kallsyms 1
Maciej Żenczykowski838b81d2020-06-23 21:05:17 -070026 start bpfloader
Maciej Żenczykowski6bd207e2020-06-19 18:12:25 -070027
Joel Fernandes6e1341e2018-11-29 11:36:13 -080028service bpfloader /system/bin/bpfloader
Maciej Żenczykowski669f7382020-02-13 13:08:30 -080029 capabilities CHOWN SYS_ADMIN
Maciej Żenczykowskie1deaec2020-01-27 22:27:02 -080030 #
31 # Set RLIMIT_MEMLOCK to 1GiB for bpfloader
32 #
33 # Actually only 8MiB would be needed if bpfloader ran as its own uid.
34 #
35 # However, while the rlimit is per-thread, the accounting is system wide.
36 # So, for example, if the graphics stack has already allocated 10MiB of
37 # memlock data before bpfloader even gets a chance to run, it would fail
38 # if its memlock rlimit is only 8MiB - since there would be none left for it.
39 #
40 # bpfloader succeeding is critical to system health, since a failure will
41 # cause netd crashloop and thus system server crashloop... and the only
42 # recovery is a full kernel reboot.
43 #
44 # We've had issues where devices would sometimes (rarely) boot into
45 # a crashloop because bpfloader would occasionally lose a boot time
46 # race against the graphics stack's boot time locked memory allocation.
47 #
48 # Thus bpfloader's memlock has to be 8MB higher then the locked memory
49 # consumption of the root uid anywhere else in the system...
50 # But we don't know what that is for all possible devices...
51 #
52 # Ideally, we'd simply grant bpfloader the IPC_LOCK capability and it
53 # would simply ignore it's memlock rlimit... but it turns that this
54 # capability is not even checked by the kernel's bpf system call.
55 #
56 # As such we simply use 1GiB as a reasonable approximation of infinity.
57 #
58 rlimit memlock 1073741824 1073741824
Joel Fernandes6e1341e2018-11-29 11:36:13 -080059 oneshot
Maciej Żenczykowski6bd207e2020-06-19 18:12:25 -070060 reboot_on_failure reboot,bpfloader-failed
61 # we're not really updatable, but want to be able to load bpf programs shipped in apexes
62 updatable