eBPF Technology and Its Application on Android Platform

eBPF (Extended Berkeley Packet Filter) is an emerging Linux kernel function extension technology that allows dynamic loading of programs without modifying kernel code, providing flexible kernel functionality extension while ensuring security.

This article introduces eBPF support on the Android platform and demonstrates the workflow of integrating and debugging eBPF programs on mobile devices through typical usage scenarios.

1. BPF Program Writing

Android eBPF program source code is located in system/bpfprogs. A typical BPF program consists of three parts: DEFINE_BPF_MAP for defining Map data structures (shared caches for data exchange between user programs and kernel), DEFINE_BPF_PROG for defining BPF functions that can be loaded into the kernel as hook functions, and LICENSE("GPL") declaration.

2. BPF Program Generation

After writing a BPF program in C language and compiling, a ".o" file is generated. This file uses BTF (BPF Type Format) bytecode-encoded metadata format and cannot be executed directly. It needs to be loaded into the kernel for parsing and execution, or executed after JIT conversion.

3. Loading BPF Programs

Android has strict permission control for BPF programs. The bpfloader.te file contains sepolicy restrictions that limit bpfloader as the only program allowed to load BPF programs:

neverallow { domain -bpfloader } *:bpf { map_create prog_load };

bpfloader only executes once during phone startup, preventing other modules from loading unauthorized BPF programs. bpfloader uses loadAllElfObjects to traverse BTF-format ".o" files in /system/etc/bpf, then uses android::bpf::loadProg to create BPF programs and corresponding Maps. After loading, BPF objects are pinned to /sys/fs/bpf file nodes to prevent destruction.

4. Attaching BPF Programs

After loading, BPF programs need to be attached to specific kernel monitoring points through operations like tracepoint or kprobe. Once successfully attached, the BPF program becomes a function in the kernel code. For tracepoint attachment, parameters can be confirmed via:

cat /sys/kernel/tracing/events/task/task_rename/format

5. Update Map

Maps serve as data exchange media between user monitoring programs and the kernel. Typical operations include:

void *bpf_map_lookup_elem(struct bpf_map *map, const void *key)

long bpf_map_update_elem(struct bpf_map *map, const void *key, const void *value, u64 flags)

long bpf_map_delete_elem(struct bpf_map *map, const void *key)

6. Event Reporting

Using perf event map enables monitoring data changes. Kernel data can be stored in custom data structures and sent to user space processes via perf event ring buffer. The process involves creating an event map with size equal to CPU count, then using epoll in user space to listen for notifications.

In kernel, data notification is done via:

bpf_perf_event_output(ctx,&events,BPF_F_CURRENT_CPU, &data, sizeof(data));

7. Debugging

To redeploy a BPF program on Android: push new .o file to /system/etc/bpf/, remove old mapping files from /sys/fs/bpf/, then run bpfloader again. To disable ratelimiting for debugging: echo on > /proc/sys/kernel/printk_devkmsg . Use bpf_printk for kernel logging:

#define bpf_printk(fmt, ...) \ ({ \ char ____fmt[] = fmt; \ bpf_trace_printk(____fmt, sizeof(____fmt), \ ##__VA_ARGS__); \ })

View kernel logs via:

$ echo 1 > /sys/kernel/tracing/tracing_on

$ cat /sys/kernel/tracing/trace_pipe

Note: bpf_printk only supports 3 parameters maximum.

8. Conclusion

eBPF can hook system calls, tracepoints, and kernel functions with wide application scenarios. Currently, its usage on Android is still preliminary, leaving significant room for further exploration in practice.