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

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

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

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

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

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.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse%rodents-montreal.org@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B