linux-kernel - Re: [PATCH bpf-next 00/11] bpf: Mitigate Spectre v1 using barriers

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <f6f08d64c777a6022771ab0adf96cefb6b631d75.camel@gmail.com>
Date: Fri, 14 Mar 2025 16:40:08 -0700
From: Eduard Zingerman <eddyz87@...il.com>
To: Luis Gerhorst <luis.gerhorst@....de>, Alexei Starovoitov
 <ast@...nel.org>,  Daniel Borkmann <daniel@...earbox.net>, Andrii Nakryiko
 <andrii@...nel.org>, Martin KaFai Lau <martin.lau@...ux.dev>,  Song Liu
 <song@...nel.org>, Yonghong Song <yonghong.song@...ux.dev>, John Fastabend	
 <john.fastabend@...il.com>, KP Singh <kpsingh@...nel.org>, Stanislav
 Fomichev	 <sdf@...ichev.me>, Hao Luo <haoluo@...gle.com>, Jiri Olsa
 <jolsa@...nel.org>,  Puranjay Mohan <puranjay@...nel.org>, Xu Kuohai
 <xukuohai@...weicloud.com>, Catalin Marinas	 <catalin.marinas@....com>,
 Will Deacon <will@...nel.org>, Hari Bathini	 <hbathini@...ux.ibm.com>,
 Christophe Leroy <christophe.leroy@...roup.eu>,  Naveen N Rao
 <naveen@...nel.org>, Madhavan Srinivasan <maddy@...ux.ibm.com>, Michael
 Ellerman	 <mpe@...erman.id.au>, Nicholas Piggin <npiggin@...il.com>, Mykola
 Lysenko	 <mykolal@...com>, Shuah Khan <shuah@...nel.org>, Henriette Herzog	
 <henriette.herzog@....de>, Cupertino Miranda
 <cupertino.miranda@...cle.com>,  Matan Shachnai <m.shachnai@...il.com>,
 Dimitar Kanaliev <dimitar.kanaliev@...eground.com>, Shung-Hsi Yu	
 <shung-hsi.yu@...e.com>, Daniel Xu <dxu@...uu.xyz>, bpf@...r.kernel.org, 
	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org, 
	linuxppc-dev@...ts.ozlabs.org, linux-kselftest@...r.kernel.org, George Guo	
 <guodongtai@...inos.cn>, WANG Xuerui <git@...0n.name>, Tiezhu Yang	
 <yangtiezhu@...ngson.cn>
Subject: Re: [PATCH bpf-next 00/11] bpf: Mitigate Spectre v1 using barriers

On Thu, 2025-03-13 at 18:21 +0100, Luis Gerhorst wrote:
> This improves the expressiveness of unprivileged BPF by inserting
> speculation barriers instead of rejecting the programs.
> 
> The approach was previously presented at LPC'24 [1] and RAID'24 [2].
> 
> To mitigate the Spectre v1 (PHT) vulnerability, the kernel rejects
> potentially-dangerous unprivileged BPF programs as of
> commit 9183671af6db ("bpf: Fix leakage under speculation on mispredicted
> branches"). In [2], we have analyzed 364 object files from open source
> projects (Linux Samples and Selftests, BCC, Loxilb, Cilium, libbpf
> Examples, Parca, and Prevail) and found that this affects 31% to 54% of
> programs.
> 
> To resolve this in the majority of cases this patchset adds a fall-back
> for mitigating Spectre v1 using speculation barriers. The kernel still
> optimistically attempts to verify all speculative paths but uses
> speculation barriers against v1 when unsafe behavior is detected. This
> allows for more programs to be accepted without disabling the BPF
> Spectre mitigations (e.g., by setting cpu_mitigations_off()).
> 
> In [1] we have measured the overhead of this approach relative to having
> mitigations off and including the upstream Spectre v4 mitigations. For
> event tracing and stack-sampling profilers, we found that mitigations
> increase BPF program execution time by 0% to 62%. For the Loxilb network
> load balancer, we have measured a 14% slowdown in SCTP performance but
> no significant slowdown for TCP. This overhead only applies to programs
> that were previously rejected.
> 
> I reran the expressiveness-evaluation with v6.14 and made sure the main
> results still match those from [1] and [2] (which used v6.5).
> 
> Main design decisions are:
> 
> * Do not use separate bytecode insns for v1 and v4 barriers. This
>   simplifies the verifier significantly and has the only downside that
>   performance on PowerPC is not as high as it could be.
> 
> * Allow archs to still disable v1/v4 mitigations separately by setting
>   bpf_jit_bypass_spec_v1/v4(). This has the benefit that archs can
>   benefit from improved BPF expressiveness / performance if they are not
>   vulnerable (e.g., ARM64 for v4 in the kernel).
> 
> * Do not remove the empty BPF_NOSPEC implementation for backends for
>   which it is unknown whether they are vulnerable to Spectre v1.

[...]

I think it would be good to have some tests checking that nospec
instructions are inserted in expected locations.
Could you please take look at use of __xlated tag in e.g.
tools/testing/selftests/bpf/progs/verifier_sdiv.c ?

[...]