A Comparative Evaluation of Emerging eBPF-Sandboxing Approaches

• Motivation: Unprivileged eBPF
  • Mitigate verifier bugs
  • Spectre defense
• Related research to be reproduced
  • VeriFence (only for Spectre)
  • BeeBox: Hardening BPF against Transient Execution Attacks
  • MOAT: Towards Safe BPF Kernel ExtensionT
  • Hive: A Hardware-assisted Isolated Execution Environment for eBPF on AArch64
    • Patches not available as of 2024-09
  • SafeBPF: Hardware-assisted Defense-in-depth for eBPF Kernel Extensions (https://arxiv.org/abs/2409.07508)
    • Towards Secure Kernel Extensibility With eBPF - Soo Yee Lim (https://www.youtube.com/watch?v=B1-41oTXeS8)
    • Uses ARM MTE.
• Related concepts and background
  • KFlex: https://rishabh246.github.io/files/kflex.pdf
    • They improve eBPF’s expressiveness but not it’s security.
  • Address Space Isolation - JACKMAN, Brendan (https://www.youtube.com/watch?v=uzJ-Z4dzT0c)
    • He mentions that these could be changed to use MPKs as an optimization. Therefore, applying this to eBPF would likely be the most promising practical route towards having eBPF isolated from the kernel.
  • Cheri (fat pointers) on ARM?
    • Only a research prototype
  • MPKs: Intel Analysis of Speculative Execution Side Channels.
    • Will cont. to work against Spectre because documented
    • Do MPKs work under speculation also on ARM/AMD/RISC-V?
  • Page Tables
    • The hardware (currently mostly, and in the future maybe completely) guarantess that it does not speculate on values outside of the current address space, this could be used to guarantee security by unmapping secret data.
    • Generalized address-space isolation
      • https://lwn.net/Articles/886494/
        • Can be used for a system-call address space. This could then be used for AnyCall.
        • It likely makes sense to separate privileged from unprivileged BPF programs to avoid the isolation overheads for the latter.
      • FastCalls
        • goal: prevent side-channel attacks on the kernel from within BPF
        • method: before invoking the BPF program:
          • still
            • unmap secret kernel memory to protect side-channel attacks on it
              • include everything containing kernel pointers!
            • with meltdown: flush the tlb
          • no longer
            • switch to user mode because BPF will never execute privileged instructions
      • Mike Raport’s System Call Address Space https://lwn.net/ml/linux-kernel/1556228754-12996-1-git-send-email-rppt@linux.ibm.com/
        • Faults in pages during syscalls on demand to prevent ROP
        • Only allows the jump if it is local or the destination address is external