From nobody Tue Sep 10 23:05:21 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 4X3K6s624kz5Tn5V; Tue, 10 Sep 2024 23:05:25 +0000 (UTC) (envelope-from rob.fx907@gmail.com) Received: from mail-ej1-x629.google.com (mail-ej1-x629.google.com [IPv6:2a00:1450:4864:20::629]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4X3K6s2thtz4268; Tue, 10 Sep 2024 23:05:25 +0000 (UTC) (envelope-from rob.fx907@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ej1-x629.google.com with SMTP id a640c23a62f3a-a8d2b4a5bf1so177810666b.2; Tue, 10 Sep 2024 16:05:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1726009523; x=1726614323; darn=freebsd.org; h=cc:to:subject:message-id:date:from:references:in-reply-to :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=lxaC1kdp70ZxV3KhRBwEMA5ciML5mPC6AyD8PtVl0sQ=; b=kLq1X+gCCrUQAJJaAkCqbGcSTEZHY9cvmHKdUTUFndDY/T1HTTrRt0u+8Cs93F8M9X uHxW++6AlYWnjXkfVMTnEiT614VeNsZv6wUImzv7unqwbN2WWJtNxBUi4W5Cvi3EkzhV 6NU6ODFJLgJ0FOd7QLE0wyOJNjFASs6bKwXEcN11IDL3YyCvJe1SrynK22nJkOKR7wvF d7pDv9SUG3ryLdpOtcULL8EeZTQ9zeQrlmjrWvC1RDI7Tf3OR84j4flkfI+JrXk8Rxf5 hjl98BABFt44dqDQQ5lWzvKZVzfX+2hfTiMmnXjQzpOY3LTZA+hab5JLNo9taieV5PhY mSsg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1726009523; x=1726614323; h=cc:to:subject:message-id:date:from:references:in-reply-to :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=lxaC1kdp70ZxV3KhRBwEMA5ciML5mPC6AyD8PtVl0sQ=; b=PY/IgHulPwi3VauhmS+qt1KIZPzkc7Bi6GxdQf83naGM1ODd9kRdZ8l2y/L7Utn4zB DDaHXqjKz3TPQCJBfhl8K76mmXZhiojN+u2q9dhLbVwXOOb2HlzyUqQAEJA29Q9S3klG Ph71rR8GxFk9PrjN523AeXRvbno19mlzOOF/jq93aZ5w6jAUP9nv6fenFc2i0z1B+gmo rgr3ldwm7CTGMBbDgeUpDhODfIbzc2pjfTmsPlcQRuu5d1HzRp0mlgH3878vRkVhvJw5 AitMmk95wTdOENZke7+aC88XkhfCT4LLkNaKGYXruTBFPNQEFqyhSwfJ8h+/zHfMhKnB X+Cg== X-Forwarded-Encrypted: i=1; AJvYcCUg9TU2r0kns0kO8tgvGJxIFxuMmLNVPrpyVp+jZE4BSlRgSGIZ462Cz729fCWoaRi1SptFK3/rXYzEcGk=@freebsd.org, AJvYcCVBh/aO361mgc/x6YZ22lxe+FNANYZy+dgia8i/s9EwWRIeF2UGTw3WMj5Esc2oWm9azDgVtatV/z7x6I8gYjow@freebsd.org, AJvYcCVO32wBtAyJEhvVq7jkboSbUPPcdTOck2vkjH8E4+0K91bxRl5kM/ifW97+No/xWa+xZs6oBphixvU9g6U=@freebsd.org X-Gm-Message-State: AOJu0YzxSISue3ez/7tVjxonI74ZkVjTe14ihc7kuEext4zTjV1qHYY5 92bj5EaBIxpHMBdVnaLDrEBrJfRtBVWXvlBBL7NRniBw9F6Pym8Eqvj5uBFc4YS23bz0unGv/9I tB5x2gMDGpApQVTurRI1WnvDfx4A= X-Google-Smtp-Source: AGHT+IHZii59aDQK4QI8qZz8O0y3eAwMpxF/hv2Me7NMwX/JK67b7rovaAf8S362Hp23Z8LjUTKKIGV9KyCum8Ktx00= X-Received: by 2002:a17:907:e651:b0:a7a:97ca:3056 with SMTP id a640c23a62f3a-a900482f97dmr100131666b.16.1726009522387; Tue, 10 Sep 2024 16:05:22 -0700 (PDT) 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 Received: by 2002:a17:907:7b06:b0:a7a:caa2:b01 with HTTP; Tue, 10 Sep 2024 16:05:21 -0700 (PDT) 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> From: Rob Wing Date: Tue, 10 Sep 2024 15:05:21 -0800 Message-ID: Subject: Re: BPF64: proposal of platform-independent hardware-friendly backwards-compatible eBPF alternative To: Vadim Goncharov Cc: David Chisnall , 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 Content-Type: multipart/alternative; boundary="0000000000007602a90621cbe8a7" X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; TAGGED_FROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] X-Rspamd-Queue-Id: 4X3K6s2thtz4268 --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 wrote: > On Tue, 10 Sep 2024 15:58:25 +0100 > David Chisnall wrote: > > > On 10 Sep 2024, at 14:44, Vadim Goncharov > > 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?

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 plent= y of

On Tuesday, September 10, 2024, Vadim Goncharov <vadimnuclight@gmail.com> wrot= e:
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 ho= w
> > Spectre works - that's why I've written RFC letter even b= efore spec
> > finished - but isn't that (Spectre) an x86-specific thing? BP= F64
> > has more registers and primarily target RISC architectures if we&= #39;re
> > speaking of JIT.=C2=A0
>
> No, speculative execution vulnerabilities are present in any CPUs
> 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
> 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<= br> > > BPF, that is, it has bytecode interpreter (for(;;) switch/case) a= s
> > primary form and JIT only then - thus e.g. JIT can be disabled fo= r
> > non-root users in case of doubt. eBPF can't do this - it alwa= ys
> > exists in native machine code form at execution, bytecode is only=
> > for verifier stage.=C2=A0
>
> This has absolutely no impact on cache side channels.=C2=A0 The JIT ma= kes
> 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 untrust= eds".

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 <-> kerne= l
> 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.=C2=A0 It=E2=80=99s 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

--0000000000007602a90621cbe8a7--