Date: Tue, 10 Sep 2024 15:05:21 -0800 From: Rob Wing <rob.fx907@gmail.com> To: Vadim Goncharov <vadimnuclight@gmail.com> Cc: David Chisnall <theraven@freebsd.org>, Poul-Henning Kamp <phk@phk.freebsd.dk>, "tcpdump-workers@lists.tcpdump.org" <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: <CAF3%2Bn_fHTk4-_Fs6L-OXfxCUEWi%2BMSSkYohgLAJ44PDcysf9iQ@mail.gmail.com> In-Reply-To: <20240911011228.161f94db@nuclight.lan> 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> <20240911011228.161f94db@nuclight.lan>
next in thread | previous in thread | raw e-mail | index | archive | help
--0000000000007602a90621cbe8a7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Doesn't NetBSD have Lua in the kernel...anyone have any experience with it? re BPF64: 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> wrote: > 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: > > > > > > 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=E2=80=99s been proposed has a performance hit and s= everal > > 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=E2=80=99s a *very* hard problem to sol= ve. > > 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 > > --0000000000007602a90621cbe8a7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Doesn't NetBSD have Lua in the kernel...anyone have any experience with= it?<div><br></div><div>re BPF64:</div><div><br></div><div>looks like hand = waving, proposing two unwritten languages that extends an ISA that is still= being drafted by IETF...hmm</div><div><br></div><div>you can make anything= look good on paper but the devil is in the details...which there are plent= y of</div><div><br>On Tuesday, September 10, 2024, Vadim Goncharov <<a h= ref=3D"mailto:vadimnuclight@gmail.com">vadimnuclight@gmail.com</a>> wrot= e:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l= eft:1px #ccc solid;padding-left:1ex">On Tue, 10 Sep 2024 15:58:25 +0100<br> David Chisnall <theraven@FreeBSD.org> wrote:<br> <br> > On 10 Sep 2024, at 14:44, Vadim Goncharov <<a href=3D"mailto:vadimn= uclight@gmail.com">vadimnuclight@gmail.com</a>><br> > wrote:<br> > > <br> > > I am not an experience assembler user and don't understand ho= w<br> > > Spectre works - that's why I've written RFC letter even b= efore spec<br> > > finished - but isn't that (Spectre) an x86-specific thing? BP= F64<br> > > has more registers and primarily target RISC architectures if we&= #39;re<br> > > speaking of JIT.=C2=A0 <br> > <br> > No, speculative execution vulnerabilities are present in any CPUs<br> > that do speculative execution that does not have explicit mitigations<= br> > against them (i.e. all that have shipped now).=C2=A0 Cache side channe= ls<br> > are present in any system with caches and do not have explicit<br> > mitigations (i.e. all that have shipped so far).<br> > <br> > Mitigations around these things are an active research area, but so<br= > > far everything that=E2=80=99s been proposed has a performance hit and = several<br> > of them were broken before anyone even implemented them outside a<br> > simulator.<br> > <br> > > And BPF64 is meant as backwards-compatible extension of existing<= br> > > BPF, that is, it has bytecode interpreter (for(;;) switch/case) a= s<br> > > primary form and JIT only then - thus e.g. JIT can be disabled fo= r<br> > > non-root users in case of doubt. eBPF can't do this - it alwa= ys<br> > > exists in native machine code form at execution, bytecode is only= <br> > > for verifier stage.=C2=A0 <br> > <br> > This has absolutely no impact on cache side channels.=C2=A0 The JIT ma= kes<br> > some attacks harder but prime-and-probe attacks are still possible.<br= > <br> Wait, do you want to say that problem is not in JIT, that is, that<br> current BPF (e.g. tcpdump) present in the kernel - are also vulnerable?<br> Also, let's classify vulnerabilities. Is speculative execution<br> vulnerability the same as cache side channels? In any case, what impact<br> is? E.g. attacker could leak secrets, but *where* would them leak? BPF<br> typically returns one 32-bit number as a verdict (often as just<br> boolean), is it really attack vector? That is, may be solution is just<br> "don't give read access to BPF-writable memory segments to untrust= eds".<br> <br> Next, if problem is with timing, then isn't that enough to just<br> restrict BPF code on having access to timers with resolution high<br> enough?<br> <br> > BPF can be loaded only by root, who can also load kernel modules and<b= r> > map /dev/[k]mem, and FreeBSD does not protect the root <-> kerne= l<br> > boundary.<br> <br> Wrong. It is possible for decades to do `chmod a+r /dev/bpf*` and run<br> tcpdump as non-root, which will load BPF code into kernel. Is *that*<br> also a vulnerability, and if so, why it was never reported?<br> <br> > Please read some of the (many) attacks on eBPF to better understand<br= > > the security landscape here.=C2=A0 It=E2=80=99s a *very* hard problem = to solve.<br> <br> Finally, the most big (in effort) question: suppose we limited to<br> trusted root user etc. so it's of no concern. Are there now any<br> objections/suggestions/<wbr>comments on (rest of) BPF64 ?<br> <br> -- <br> WBR, @nuclight<br> <br> </blockquote></div> --0000000000007602a90621cbe8a7--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAF3%2Bn_fHTk4-_Fs6L-OXfxCUEWi%2BMSSkYohgLAJ44PDcysf9iQ>