Date: Wed, 11 Sep 2024 01:12:28 +0300 From: Vadim Goncharov <vadimnuclight@gmail.com> To: David Chisnall <theraven@FreeBSD.org> Cc: Poul-Henning Kamp <phk@phk.freebsd.dk>, tcpdump-workers@lists.tcpdump.org, "freebsd-arch@freebsd.org" <freebsd-arch@FreeBSD.org>, "freebsd-hackers@freebsd.org" <freebsd-hackers@FreeBSD.org>, "freebsd-net@freebsd.org" <freebsd-net@FreeBSD.org>, "tech-net@netbsd.org" <tech-net@NetBSD.org>, Alexander Nasonov <alnsn@NetBSD.org> Subject: Re: BPF64: proposal of platform-independent hardware-friendly backwards-compatible eBPF alternative Message-ID: <20240911011228.161f94db@nuclight.lan> In-Reply-To: <3F3533E4-6059-4B4F-825F-6995745FDE35@FreeBSD.org> References: <20240910040544.125245ad@nuclight.lan> <202409100638.48A6cor2090591@critter.freebsd.dk> <20240910144557.4d95052a@nuclight.lan> <4D84AF55-51C7-4C2B-94F7-D486A29E8821@FreeBSD.org> <20240910164447.30039291@nuclight.lan> <3F3533E4-6059-4B4F-825F-6995745FDE35@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 10 Sep 2024 15:58:25 +0100 David Chisnall <theraven@FreeBSD.org> wrote: > On 10 Sep 2024, at 14:44, Vadim Goncharov <vadimnuclight@gmail.com> > wrote: > >=20 > > 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. =20 >=20 > 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). >=20 > Mitigations around these things are an active research area, but so > far everything that=E2=80=99s been proposed has a performance hit and sev= eral > of them were broken before anyone even implemented them outside a > simulator. >=20 > > 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. =20 >=20 > 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=E2=80=99s a *very* hard problem to solve. =20 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 ? --=20 WBR, @nuclight
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20240911011228.161f94db>