From nobody Tue Sep 10 14:58:25 2024 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4X36KB534yz5Vxnp; Tue, 10 Sep 2024 14:58:38 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R10" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4X36KB4M8tz4bZ8; Tue, 10 Sep 2024 14:58:38 +0000 (UTC) (envelope-from theraven@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1725980318; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=RgfWg2bulIbwtlV/4Gjmiz25NxsSSsRKimR8IwQMrQE=; b=Yqjp1onLc6T66JnXpukvkLGCGByhHTqXQ/326gFljqWs22byt1+e31gu+GCi/qbx1Qe6is 19z0z9mVS66YgQnLUcS8Fz5A2RX2KYusseSh5luBCoLs5aUugArFyS9I70IO7MGUA5Kz6d lWjLGexiEHflu+Vbtgb4qeqaKpr5cLMisHU7Nt47w8Kmuudk3TS1OHJwwx85Ru4oJ156U3 l8R7uKdnkjq0HlcgFFQlrd8u+/TqjRFjvd30cVT72QopUl2IpcAEUxhWyC0YYCJIvhnkP5 +zeQyqQpg+Q9/lmtGm4wXowi5s2CZYfEBp0XtFOFICzaDFaX6K+LnUTLU+uS+A== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1725980318; a=rsa-sha256; cv=none; b=r7J1AAmkrkm88Vv2xWg8U5zAVGa+oX4cpBbaBVKACfFD7x3NRSIVu05KyQwMQL5yG2WZyt Q3mPi9W6FkJr+qTpzJlpVZ6BiGdlc9ekOH8MGH46zWjkNV+CNRQlHBabZvH/r3O4sUHqPs 6c5dUmvpMZEEEBSJvn23ioPLwYjA7g0f7v+EuPSR3yDVoDFZpMFonBC5rg7cI7ceP/yn8s 1NtdgdOcRPVVpI6xEKbTSMOWiFonw7QgqQcRTBkUe3K7Ez/rW+p2WYCZ4BpkwfiQ1bjFmS j/LAwD8cbfSJUr7cvByrmKoDrbTBfDjDrLRVzVeYYxnVZO7f2gk2DsaP+GPMqw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1725980318; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=RgfWg2bulIbwtlV/4Gjmiz25NxsSSsRKimR8IwQMrQE=; b=q7NHQXHrOSUosQwO+DzcksYTdwz4obEKP7ay6HIibVp7dwPFksuNRXj5sP48Tj396u9aAp +nWPswQuT7dFtKGmNEIWLzx/QaAzKaNUQzQO1Q5d+vPgTD7sJgK4u5kTgexTYzKf7h8dus 3DspqJvgkEq+rSS/7k55rXxyOGUICY3pRc0cAuvGsfhelj0rqRi3CTGFuO9+eqT1T9xBJz RSASC+aARtnuWwLKcKyhPz3StD71XHDdzb8aEOzcFcQkv3JnUsQ/7PY/Ya2SZ9yA4fr+6i 7JB2X+kMw0q+nvd1HxmuuP55rhSdwyT28vfUxIZjLQS5ihaUonNv4WbU0fZbiA== Received: from smtp.theravensnest.org (smtp.theravensnest.org [45.77.103.195]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: theraven) by smtp.freebsd.org (Postfix) with ESMTPSA id 4X36KB3VKczSKG; Tue, 10 Sep 2024 14:58:38 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from smtpclient.apple (host109-155-136-107.range109-155.btcentralplus.com [109.155.136.107]) by smtp.theravensnest.org (Postfix) with ESMTPSA id DA1E365B7; Tue, 10 Sep 2024 15:58:36 +0100 (BST) From: David Chisnall Message-Id: <3F3533E4-6059-4B4F-825F-6995745FDE35@FreeBSD.org> Content-Type: multipart/alternative; boundary="Apple-Mail=_C79A00F0-FADC-4B5C-84B5-8912A75C117E" List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@FreeBSD.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3776.700.51\)) Subject: Re: BPF64: proposal of platform-independent hardware-friendly backwards-compatible eBPF alternative Date: Tue, 10 Sep 2024 15:58:25 +0100 In-Reply-To: <20240910164447.30039291@nuclight.lan> Cc: Poul-Henning Kamp , tcpdump-workers@lists.tcpdump.org, "freebsd-arch@freebsd.org" , "freebsd-hackers@freebsd.org" , "freebsd-net@freebsd.org" , "tech-net@netbsd.org" , Alexander Nasonov To: Vadim Goncharov 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> X-Mailer: Apple Mail (2.3776.700.51) --Apple-Mail=_C79A00F0-FADC-4B5C-84B5-8912A75C117E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On 10 Sep 2024, at 14:44, Vadim Goncharov = 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. 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 = 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=E2=80=99s a *very* hard problem to solve. David --Apple-Mail=_C79A00F0-FADC-4B5C-84B5-8912A75C117E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 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 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=E2=80=99s a *very* hard problem to = solve.

David

= --Apple-Mail=_C79A00F0-FADC-4B5C-84B5-8912A75C117E--