linux-kernel - Re: [RFC PATCH 5/9] bpf: Fall back to nospec if v1 verification fails

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] [day] [month] [year] [list]

Message-ID: <e8041b56-396b-427f-b9cb-d51004a40f57@fau.de>
Date: Thu, 27 Feb 2025 17:07:43 +0100
From: Luis Gerhorst <luis.gerhorst@....de>
To: Alexei Starovoitov <ast@...nel.org>,
 Daniel Borkmann <daniel@...earbox.net>, Andrii Nakryiko <andrii@...nel.org>,
 Martin KaFai Lau <martin.lau@...ux.dev>, Eduard Zingerman
 <eddyz87@...il.com>, 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>,
 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, linux-kselftest@...r.kernel.org
Cc: Maximilian Ott <ott@...fau.de>, Milan Stephan <milan.stephan@....de>
Subject: Re: [RFC PATCH 5/9] bpf: Fall back to nospec if v1 verification fails

On 24/02/2025 21:47, Luis Gerhorst wrote:
> +		} else if (error_recoverable_with_nospec(err) && state->speculative) 
> {
> +			WARN_ON_ONCE(env->bypass_spec_v1);
> +			WARN_ON_ONCE(env->cur_state != state);
> +
> +			/* Prevent this speculative path from ever reaching the
> +			 * insn that would have been unsafe to execute.
> +			 */
> +			cur_aux(env)->nospec = true;

This allows us to accept more programs, but it has the downside that 
Spectre v1 mitigation now requires BPF_NOSPEC to be emitted by every JIT 
for archs vulnerable to Spectre v1. This currently is not the case, and 
this patch therefore may regress BPF's security.

The regression is limited to systems vulnerable to Spectre v1, have 
unprivileged BPF enabled, and do NOT emit insns for BPF_NOSPEC. The 
latter is not the case for x86 64- and 32-bit, arm64, and powerpc 64-bit 
and they are therefore not affected by the regression. According to [1], 
LoongArch and mips are not vulnerable to Spectre v1 and therefore also 
not affected by the regression.

Also, if any of those regressed systems is also vulnerable to Spectre 
v4, the system was already vulnerable to Spectre v4 attacks based on 
unpriv BPF before this patch and the impact is therefore further 
limited.

As far as I am aware, it is unclear which other architectures (besides 
x86 64- and 32-bit, arm64, powerpc 64-bit, LoongArch, and mips) 
supported by the kernel are vulnerable to Spectre v1 but not to Spectre 
v4. Also, I am not sure if barriers are available on these 
architectures. Implementing BPF_NOSPEC on these architectures therefore 
appears non-trivial (probably impossible) to me. Searching gcc / the 
kernel for speculation barrier implementations for these architectures 
yielded no result. Any input is very welcome.

As an alternative, one could still reject programs if the architecture 
does not emit BPF_NOSPEC (e.g., by removing the empty BPF_NOSPEC-case 
from all JITs except for LoongArch and mips where they appear 
justified). However, this will cause rejections on these archs and some 
may have to re-add the empty case. Even if this happens, some may not do 
it and only rejecting the programs on some archs might complicate BPF 
selftests.

Do you think the potential regression is acceptable or should we err on 
the side of caution?

[1] a6f6a95f25803500079513780d11a911ce551d76 ("LoongArch, bpf: Fix jit 
to skip speculation barrier opcode")