Date: Tue, 10 Sep 2024 15:58:25 +0100 From: David Chisnall <theraven@FreeBSD.org> To: Vadim Goncharov <vadimnuclight@gmail.com> 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: <3F3533E4-6059-4B4F-825F-6995745FDE35@FreeBSD.org> In-Reply-To: <20240910164447.30039291@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>
next in thread | previous in thread | raw e-mail | index | archive | help
[-- Attachment #1 --] 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’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. 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. Please read some of the (many) attacks on eBPF to better understand the security landscape here. It’s a *very* hard problem to solve. David [-- Attachment #2 --] <html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;">On 10 Sep 2024, at 14:44, Vadim Goncharov <vadimnuclight@gmail.com> wrote:<br><div><blockquote type="cite"><br class="Apple-interchange-newline"><div><span style="caret-color: rgb(0, 0, 0); font-family: SourceCodePro-Regular; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; float: none; display: inline !important;">I am not an experience assembler user and don't understand how Spectre</span><br style="caret-color: rgb(0, 0, 0); font-family: SourceCodePro-Regular; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;"><span style="caret-color: rgb(0, 0, 0); font-family: SourceCodePro-Regular; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; float: none; display: inline !important;">works - that's why I've written RFC letter even before spec finished - but</span><br style="caret-color: rgb(0, 0, 0); font-family: SourceCodePro-Regular; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;"><span style="caret-color: rgb(0, 0, 0); font-family: SourceCodePro-Regular; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; float: none; display: inline !important;">isn't that (Spectre) an x86-specific thing? BPF64 has more registers</span><br style="caret-color: rgb(0, 0, 0); font-family: SourceCodePro-Regular; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;"><span style="caret-color: rgb(0, 0, 0); font-family: SourceCodePro-Regular; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; float: none; display: inline !important;">and primarily target RISC architectures if we're speaking of JIT.</span><br style="caret-color: rgb(0, 0, 0); font-family: SourceCodePro-Regular; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;"></div></blockquote><div><br></div><div>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).</div><div><br></div><div>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.</div><div><span style="caret-color: rgb(0, 0, 0); font-family: SourceCodePro-Regular; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; float: none; display: inline !important;"><br></span></div><blockquote type="cite"><div><span style="caret-color: rgb(0, 0, 0); font-family: SourceCodePro-Regular; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; float: none; display: inline !important;">And BPF64 is meant as backwards-compatible extension of existing BPF,</span><br style="caret-color: rgb(0, 0, 0); font-family: SourceCodePro-Regular; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;"><span style="caret-color: rgb(0, 0, 0); font-family: SourceCodePro-Regular; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; float: none; display: inline !important;">that is, it has bytecode interpreter (for(;;) switch/case) as primary</span><br style="caret-color: rgb(0, 0, 0); font-family: SourceCodePro-Regular; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;"><span style="caret-color: rgb(0, 0, 0); font-family: SourceCodePro-Regular; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; float: none; display: inline !important;">form and JIT only then - thus e.g. JIT can be disabled for non-root</span><br style="caret-color: rgb(0, 0, 0); font-family: SourceCodePro-Regular; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;"><span style="caret-color: rgb(0, 0, 0); font-family: SourceCodePro-Regular; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; float: none; display: inline !important;">users in case of doubt. eBPF can't do this - it always exists in native</span><br style="caret-color: rgb(0, 0, 0); font-family: SourceCodePro-Regular; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;"><span style="caret-color: rgb(0, 0, 0); font-family: SourceCodePro-Regular; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; float: none; display: inline !important;">machine code form at execution, bytecode is only for verifier stage.</span><br style="caret-color: rgb(0, 0, 0); font-family: SourceCodePro-Regular; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;"></div></blockquote></div><br><div>This has absolutely no impact on cache side channels. The JIT makes some attacks harder but prime-and-probe attacks are still possible.</div><div><br></div><div>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.</div><div><br></div><div>Please read some of the (many) attacks on eBPF to better understand the security landscape here. It’s a *very* hard problem to solve.</div><div><br></div><div>David</div><div><br></div></body></html>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3F3533E4-6059-4B4F-825F-6995745FDE35>