Speakers
Description
Host-side hardening for a confidential VM is not one control, it's an onion. AMD SEV protects guest memory, MetalOS and a measured/verified boot chain establish the platform, signing and provisioning gate what lands on disk, and process isolation constrains the runtime. This talk is about one specific layer of that onion, the eBPF LSM that enforces binary identity and process protection at runtime. WhatsApp runs user workloads inside AMD SEV-backed TEEs where the guest is a QEMU process; eBPF LSM is how we add a defense-in-depth layer for that host without becoming a new single point of trust.
The core of the talk is the BPF and the goal is to give attendees a full picture of how we use BPF at Meta to supplement confidential workloads in WhatsApp. Specifically, we attach a set of LSM programs bprm_creds_from_file for exec-time identity, ptrace_access_check/ptrace_traceme for anti-trace, and task_kill for anti-signal and drive them entirely from BPF maps keyed by role. The design choice we want to dig into is persistence through pinning that has been discussed in other talks from Tetragon discussed in this lwn article and fully explore how we pin, configure our maps, set up keychains used for binary identification and how we track processes. We will also talk about the need for options for logging as is done in the initial article, but it will be a small portion to ask for opinions and discuss some other options that we are exploring, as opposed to standing exclusively behind UDP packet sending that has been discussed previously. We will mention potential malware opportunities from this approach. Our method will be contrasted with pros and cons of a typical resident daemon. In the use case at Meta, a run-to-completion init binary loads the programs, pins every program, link, and map into bpffs, and exits. Because the LSM links survive pivot root, enforcement is live before the confidential workload starts. We'll walk through the map layout, how policy is expressed per-role, and how pinned state lets the enforcement layer survive independently of any userspace processes. We will also discuss some of the strategies we use to disallow malicious userspace processes from removing these programs once they are in place and how we manage the potential fallout from this.
On identity, we'll show the in-kernel verification path in detail. At exec, the bprm_creds_from_file hook reads an extended attribute on the binary user.bpfj.policy.exec naming its role, which forces calls to bpf_get_fsverity_digest and bpf_verify_pkcs7_signature to check the binary's fs-verity digest and detached PKCS7 signature against a kernel keyring seeded from that role's certificates enrolling the process into a role only if its on-disk contents are signed for that role. Here the BPF layer leans on fs-verity, the keyring subsystem, and our custom signing pipeline do the heavy cryptographic lifting. Our programs make the runtime authorization decision from that verified identity. We'll cover the kfuncs we depend on, the sleepable-LSM constraints, and the pitfalls we eliminated by moving to signature-gated, exec-time enrollment.
Finally, we show what verified identity buys at runtime with QEMU pinned to a verified role, the ptrace and task_kill hooks enforce per-role allow-lists so nothing on the host can attach a debugger to, or signal, the confidential VM closing common paths for extracting or faulting guest state. We'll be explicit about the layer's limits what it does not defend against and which sibling controls cover those gaps — so the audience sees where a focused eBPF LSM fits in a real confidential-computing threat model.