Re: BPF64: proposal of platform-independent hardware-friendly backwards-compatible eBPF alternative

[David Chisnall <theraven%freebsd.org@localhost>]

On 11 Sep 2024, at 10:06, Vadim Goncharov <vadimnuclight%gmail.com@localhost> wrote:
> 
> But then a possibility to give this to non-root is. And many things are
> considered vulnerabilitites even if they are only available to root -
> for example, when root can be tricked into running malicious code etc.
> (unconscious) actions without direct intention.

When the root user intentionality changes some thin from a secure default to an insecure setting, it is not a security vulnerability in the system that shipped the safe defaults. 

> Equivalency of classic BPF to writable /dev/mem is too loud and
> controversial statement. Demonstrate how it can be done on stock
> FreeBSD 13 with /dev/bpf available to attacker (e.g. `sudo tcpdump`
> allowed).

Two things to unpick here. First:

Demanding a proof of concept before you accept that something is a vulnerability is how you build insecure systems. Ask the Matrix team how well that attitude has worked for them in the last few weeks. You build secure systems by defining a threat model and then evaluating primitives against that threat model, not by throwing together a bunch of primitives and saying ‘well, *I* can’t assemble them into an exploit and so no one can’.

Second, there are documented attacks on eBPF that give the equivalent of *read* access to /dev/mem. This is why BPF is restricted to root. We have a threat model. The threat model says that we do not need to ensure that BPF cannot leak kernel data indirectly because only the user who has the ability to leak kernel data directly can use it and this user has a simpler way of achieving the same result. If you allow non-root users to run code (native or against any virtual machine) then you are changing the threat model. You *must* prevent users from leaking kernel data that they could not leak via existing mechanisms.

The two most common attacks using eBPF are generally in the following two categories:

 - Use eBPF to mount a speculative execution attack on the kernel. Please read up on what these can do. No one should be building a thing that runs code in the kernel without understanding speculative, cache, and timing side channels.
 - Use eBPF to build a set of gadgets that you can then use to go from one memory-safety bug in the kernel to arbitrary-code execution.

This is the threat landscape in which something in the same space as eBPF must exist. A proposed design should *start* with an explanation of how it mitigates both of these categories of attack.

David