Re: [PATCH bpf-next v3 00/11] bpf: Mitigate Spectre v1 using barriers
On Fri, May 9, 2025 at 11:39 AM wrote:
>
> Hello:
>
> This series was applied to bpf/bpf-next.git (master)
> by Alexei Starovoitov :
>
> On Thu, 1 May 2025 09:35:51 +0200 you 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.
> >
> > [...]
>
> Here is the summary with links:
> - [bpf-next,v3,01/11] selftests/bpf: Fix caps for __xlated/jited_unpriv
> https://git.kernel.org/bpf/bpf-next/c/cf15cdc0f0f3
> - [bpf-next,v3,02/11] bpf: Move insn if/else into do_check_insn()
> (no matching commit)
Applied the first patch only.
Waiting for respin of the rest.
Re: [PATCH bpf-next v3 00/11] bpf: Mitigate Spectre v1 using barriers
Hello:
This series was applied to bpf/bpf-next.git (master)
by Alexei Starovoitov :
On Thu, 1 May 2025 09:35:51 +0200 you 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.
>
> [...]
Here is the summary with links:
- [bpf-next,v3,01/11] selftests/bpf: Fix caps for __xlated/jited_unpriv
https://git.kernel.org/bpf/bpf-next/c/cf15cdc0f0f3
- [bpf-next,v3,02/11] bpf: Move insn if/else into do_check_insn()
(no matching commit)
- [bpf-next,v3,03/11] bpf: Return -EFAULT on misconfigurations
(no matching commit)
- [bpf-next,v3,04/11] bpf: Return -EFAULT on internal errors
(no matching commit)
- [bpf-next,v3,05/11] bpf, arm64, powerpc: Add bpf_jit_bypass_spec_v1/v4()
(no matching commit)
- [bpf-next,v3,06/11] bpf, arm64, powerpc: Change nospec to include v1 barrier
(no matching commit)
- [bpf-next,v3,07/11] bpf: Rename sanitize_stack_spill to nospec_result
(no matching commit)
- [bpf-next,v3,08/11] bpf: Fall back to nospec for Spectre v1
(no matching commit)
- [bpf-next,v3,09/11] selftests/bpf: Add test for Spectre v1 mitigation
(no matching commit)
- [bpf-next,v3,10/11] bpf: Allow nospec-protected var-offset stack access
(no matching commit)
- [bpf-next,v3,11/11] bpf: Fall back to nospec for sanitization-failures
(no matching commit)
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
[PATCH bpf-next v3 00/11] bpf: Mitigate Spectre v1 using barriers
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()).
For this, it relies on the fact that speculation barriers prevent all
later instructions if the speculation was not correct:
* On x86_64, lfence acts as full speculation barrier, not only as a
load fence [3]:
An LFENCE instruction or a serializing instruction will ensure that
no later instructions execute, even speculatively, until all prior
instructions complete locally. [...] Inserting an LFENCE instruction
after a bounds check prevents later operations from executing before
the bound check completes.
This was experimentally confirmed in [4].
* ARM's SB speculation barrier instruction also affects "any instruction
that appears later in the program order than the barrier" [5].
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 (inspired by
Daniel Borkmann's question at LPC). 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.
[1] https://lpc.events/event/18/contributions/1954/ ("Mitigating
Spectre-PHT using Speculation Barriers in Linux eBPF")
[2] https://arxiv.org/pdf/2405.00078 ("VeriFence: Lightweight and
Precise Spectre Defenses for Untrusted Linux Kernel Extensions")
[3]
https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/technical-documentation/runtime-speculative-side-channel-mitigations.html
("Managed Runtime Speculative Execution Side Channel Mitigations")
[4] https://dl.acm.org/doi/pdf/10.1145/3359789.3359837 ("Speculator: a
tool to analyze speculative execution attacks and mitigations" -
Section 4.6 "Stopping Speculative Execution")
[5]
https://developer.arm.com/documentation/ddi0597/2020-12/Base-Instructions/SB--Speculation-Barrier-
("SB - Speculation Barrier - Arm Armv8-A A32/T32 Instruction Set
Architecture (2020-12)")
Changes:
* v2 -> v3:
- Fix
https://lore.kernel.org/oe-kbuild-all/[email protected]/
and similar by moving the bpf_jit_bypass_spec_v1/v4() prototypes out
of the #ifdef CONFIG_BPF_SYSCALL. Decided not to move them to
filter.h (where similar bpf_jit_*() prototypes live) as they would
still have to be duplicated in bpf.h to be usable to
bpf_bypass_spec_v1/v4() (unless including filter.h in bpf.h is an
option).
- Fix
https://lore.kernel.org/oe-kbuild-all/[email protected]/
by moving the variable declarations out of the switch-case.
- Build touched C files with W=2 and bpf config on x86 to check that
there are no other warnings introduced.
- Found 3 more checkpatch warnings that can be fixed without degrading
readability.
- Rebase to bpf-next 2025-05-01
- Link to v2:
https://lore.kernel.org/bpf/[email protected]/
* v1 -> v2:
- Drop former commits 9 ("bpf: Return PTR_ERR from push_stack()") and 11
("bpf: Fall back to nospec for spec path verification") as suggested
