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")