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

[Vadim Goncharov <vadimnuclight%gmail.com@localhost>]

On Wed, 11 Sep 2024 12:21:09 +0100
David Chisnall <theraven%freebsd.org@localhost> wrote:

> 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. 

This is just not true. See, for example, FreeBSD-SA-17:06.openssh for
vulnerability disabled by default, and workaround proposed to return
to default (disabled) state.

> > 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.

Stop. Just stop, and re-read carefully. You (and perhaps Philip)
confusing two things: BPF and eBPF (and BPF64 third), all completely
different beasts. Last two letters in this thread, I was talking about
classic BPF existing in *BSD for decades (on FreeBSD allowed to have
permissions on dev/bpf*). So you assert that THIS classic BPF also
vulnerable to aforementioned attacks, and thus SA must be issued, just
like that FreeBSD-SA-17:06.openssh, with a fix (at least preventing
changing default permissions) of hole existing for *decades*. This is
too strong assertion to be accepted without proofs, and as I can deduce
from your other words and readings about Spectre (see below), this
statement is not true (classic /dev/bpf is not vulnerable).

> 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.
> 
> 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.

Again, you are talking about eBPF here, not classic BPF. So far Spectre
was mentioned as example of those speculative, cache, and timing side
channels: https://en.wikipedia.org/wiki/Spectre_(security_vulnerability)
refers to mitigations e.g. in Firefox -
https://www.mozilla.org/en-US/security/advisories/mfsa2018-01/
with key phrase

"The precision of performance.now() has been reduced from 5μs to 20μs,"

So to prevent this class of attacks you need to deprive untrusted code
from (precise) timers. And if we then go eBPF sources, we see at
https://elixir.bootlin.com/linux/v6.10/source/include/uapi/linux/bpf.h#L1884
 * u64 bpf_ktime_get_ns(void)
 * 	Description
 * 		Return the time elapsed since system boot, in nanoseconds.
 * 		Does not include time the system was suspended.
 * 		See: **clock_gettime**\ (**CLOCK_MONOTONIC**)

This is because eBPF is used in Linux as one-catch-all for tracing and
profiling - they do not have DTrace. And we have. And BPF don't need to
be DTrace and don't need timers.

Thus, we can conclude, your eBPF assertion is simply not applicable to
*BSD classic BPF, and consequently, to current state of BPF64 which
don't include any timers or time sources available to user code at all.

>  - 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 requires further explanations (including to ensure we're not
mixing things again). As far as I can see currently, this is also not
applicable to BPF64 due to lack of pointers.

-- 
WBR, @nuclight