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

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

On Tue, 10 Sep 2024 23:12:32 -0400 (EDT)
Mouse <mouse%Rodents-Montreal.ORG@localhost> wrote:

> > Wait, do you want to say that problem is not in JIT, that is, that
> > current BPF (e.g. tcpdump) present in the kernel - are also
> > vulnerable?  
> 
> I'm not sure I'd say that either BPF or eBPF is, per se, vulnerable to
> Spectre-style attacks.  Rather, I'd say that they are - or, rather,
> may be, because I haven't looked closely enough to be sure -
> particularly convenient ways to exploit Spectre-style processor bugs.
> 
> > Also, let's classify vulnerabilities.  Is speculative execution
> > vulnerability the same as cache side channels?  
> 
> No.  They are not the same, but they can work together.
> 
> Speculative execution without side channels is, as far as I know, not
> a vulnerability at all.  Side channels without some way to abuse them
> also do not a vulnerability make.  But put them together and you have
> Spectre.
> 
> Also, other side channels are possible; anything that can exfiltrate
> information from speculatively executed code to the architecturally
> visible world can be exploited by Spectreish attacks.  (An example
> might be timing measurements used to determine whether certain
> execution units, such as an FPU, are busy.)
> 
> > In any case, what impact is?  
> 
> At its simplest, the impact is that the attacker's process can read
> memory present in its address space but nominally protected against
> access - kernel memory is an example.  (It typically does this by
> speculatively executing a read to it and leaking the result through a
> side channel before the speculatively executed code is discovered to
> be ephemeral.  Read the paper by Kocher, Genkin, Gruss, Haas, et al -
> I can make a copy available if you have trouble finding it.
> 
> There probably are other impacts I haven't seen described (nor thought
> of myself).  But I haven't put much thought into it.
> 
> > E.g. attacker could leak secrets, but *where* would them leak?  
> 
> They would leak from something the attacker is architecturally not
> allowed to access into architecturally-visible state the attacker
> _can_ access.

So that's impossible if BPF code has no write access to memory
available for, hm, scratch needs, and is available to attacker. Then it
must be documented to not give it memory segments it don't need.

> > Next, if problem is with timing, then isn't that enough to just
> > restrict BPF code on having access to timers with resolution high
> > enough?  
> 
> No.  All that does is coarsen the resolution, introducing noise into
> the measurement.  Statistical techniques can pull the signal out of
> the noise.  This doesn't close the channel; it just cuts its data
> rate.

As I've googled and just wrote reply to David Chisnall, seems not to be
the case. Let me repeat from that letter:

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

> > It is possible for decades to do `chmod a+r /dev/bpf*` and run
> > tcpdump as non-root, which will load BPF code into kernel.  Is
> > *that* also a vulnerability, and if so, why it was never reported?  
> 
> Philip Paeps writes that this is "equivalent to chmod a+w /dev/mem".
> While that is a bit of an exaggeration - BPF access is not nearly as
> much "keys to the kingdom" as unrestricted /dev/mem - there is a grain
> of truth in it.

Well, as far as I can tell current BPF in our BSDs not vulnerable. So
is BPF64, at least if we put "don't give user code a time source" :-)

> I've pondered this for some time: why is it that we (well, I) say
> things like "userland, even root, should never be able to panic the
> kernel" but then don't consider "dd if=/dev/urandom of=/dev/kmem" a
> bug?  I haven't come up with a satisfactory (to me) resolution of that
> paradox.

Because it's very intentional to exactly to cause panic? Just like
setting kernel debugger's sysctl for calling panic()

-- 
WBR, @nuclight