Maciej Żenczykowski | 6bd207e | 2020-06-19 18:12:25 -0700 | [diff] [blame] | 1 | # 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) |
Maciej Żenczykowski | 6bd207e | 2020-06-19 18:12:25 -0700 | [diff] [blame] | 10 | # - logd is ready for us to log stuff |
| 11 | # |
| 12 | # At the same time we want to be as early as possible to reduce races and thus |
| 13 | # failures (before memory is fragmented, and cpu is busy running tons of other |
| 14 | # stuff) and we absolutely want to be before netd and the system boot slot is |
| 15 | # considered to have booted successfully. |
| 16 | # |
| 17 | on load_bpf_programs |
| 18 | # Enable the eBPF JIT -- but do note that on 64-bit kernels it is likely |
| 19 | # already force enabled by the kernel config option BPF_JIT_ALWAYS_ON |
| 20 | write /proc/sys/net/core/bpf_jit_enable 1 |
| 21 | # Enable JIT kallsyms export for privileged users only |
| 22 | write /proc/sys/net/core/bpf_jit_kallsyms 1 |
Maciej Żenczykowski | 2a775a4 | 2020-06-23 21:06:38 -0700 | [diff] [blame] | 23 | exec_start bpfloader |
Maciej Żenczykowski | 6bd207e | 2020-06-19 18:12:25 -0700 | [diff] [blame] | 24 | |
Joel Fernandes | 6e1341e | 2018-11-29 11:36:13 -0800 | [diff] [blame] | 25 | service bpfloader /system/bin/bpfloader |
Maciej Żenczykowski | 265d131 | 2021-03-01 23:09:27 -0800 | [diff] [blame] | 26 | capabilities CHOWN SYS_ADMIN NET_ADMIN |
Maciej Żenczykowski | e1deaec | 2020-01-27 22:27:02 -0800 | [diff] [blame] | 27 | # |
| 28 | # Set RLIMIT_MEMLOCK to 1GiB for bpfloader |
| 29 | # |
| 30 | # Actually only 8MiB would be needed if bpfloader ran as its own uid. |
| 31 | # |
| 32 | # However, while the rlimit is per-thread, the accounting is system wide. |
| 33 | # So, for example, if the graphics stack has already allocated 10MiB of |
| 34 | # memlock data before bpfloader even gets a chance to run, it would fail |
| 35 | # if its memlock rlimit is only 8MiB - since there would be none left for it. |
| 36 | # |
| 37 | # bpfloader succeeding is critical to system health, since a failure will |
| 38 | # cause netd crashloop and thus system server crashloop... and the only |
| 39 | # recovery is a full kernel reboot. |
| 40 | # |
| 41 | # We've had issues where devices would sometimes (rarely) boot into |
| 42 | # a crashloop because bpfloader would occasionally lose a boot time |
| 43 | # race against the graphics stack's boot time locked memory allocation. |
| 44 | # |
| 45 | # Thus bpfloader's memlock has to be 8MB higher then the locked memory |
| 46 | # consumption of the root uid anywhere else in the system... |
| 47 | # But we don't know what that is for all possible devices... |
| 48 | # |
| 49 | # Ideally, we'd simply grant bpfloader the IPC_LOCK capability and it |
| 50 | # would simply ignore it's memlock rlimit... but it turns that this |
| 51 | # capability is not even checked by the kernel's bpf system call. |
| 52 | # |
| 53 | # As such we simply use 1GiB as a reasonable approximation of infinity. |
| 54 | # |
| 55 | rlimit memlock 1073741824 1073741824 |
Joel Fernandes | 6e1341e | 2018-11-29 11:36:13 -0800 | [diff] [blame] | 56 | oneshot |
Maciej Żenczykowski | 6bd207e | 2020-06-19 18:12:25 -0700 | [diff] [blame] | 57 | reboot_on_failure reboot,bpfloader-failed |
| 58 | # we're not really updatable, but want to be able to load bpf programs shipped in apexes |
| 59 | updatable |