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