looks like hand waving, proposing two unwritten languages that extends an ISA that is still being drafted by IETF...hmm
you can make anything look good on paper but the devil is in the details...which there are plenty of
On Tuesday, September 10, 2024, Vadim Goncharov <
vadimnuclight%gmail.com@localhost> wrote:
On Tue, 10 Sep 2024 15:58:25 +0100
David Chisnall <theraven%FreeBSD.org@localhost> wrote:
> On 10 Sep 2024, at 14:44, Vadim Goncharov <vadimnuclight%gmail.com@localhost>
> wrote:
> >
> > I am not an experience assembler user and don't understand how
> > Spectre works - that's why I've written RFC letter even before spec
> > finished - but isn't that (Spectre) an x86-specific thing? BPF64
> > has more registers and primarily target RISC architectures if we're
> > speaking of JIT.
>
> No, speculative execution vulnerabilities are present in any CPUs
> that do speculative execution that does not have explicit mitigations
> against them (i.e. all that have shipped now). Cache side channels
> are present in any system with caches and do not have explicit
> mitigations (i.e. all that have shipped so far).
>
> Mitigations around these things are an active research area, but so
> far everything that’s been proposed has a performance hit and several
> of them were broken before anyone even implemented them outside a
> simulator.
>
> > And BPF64 is meant as backwards-compatible extension of existing
> > BPF, that is, it has bytecode interpreter (for(;;) switch/case) as
> > primary form and JIT only then - thus e.g. JIT can be disabled for
> > non-root users in case of doubt. eBPF can't do this - it always
> > exists in native machine code form at execution, bytecode is only
> > for verifier stage.
>
> This has absolutely no impact on cache side channels. The JIT makes
> some attacks harder but prime-and-probe attacks are still possible.
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?
Also, let's classify vulnerabilities. Is speculative execution
vulnerability the same as cache side channels? In any case, what impact
is? E.g. attacker could leak secrets, but *where* would them leak? BPF
typically returns one 32-bit number as a verdict (often as just
boolean), is it really attack vector? That is, may be solution is just
"don't give read access to BPF-writable memory segments to untrusteds".
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?
> BPF can be loaded only by root, who can also load kernel modules and
> map /dev/[k]mem, and FreeBSD does not protect the root <-> kernel
> boundary.
Wrong. 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?
> Please read some of the (many) attacks on eBPF to better understand
> the security landscape here. It’s a *very* hard problem to solve.
Finally, the most big (in effort) question: suppose we limited to
trusted root user etc. so it's of no concern. Are there now any
objections/suggestions/comments on (rest of) BPF64 ?
--
WBR, @nuclight