On Thu, 1 May 2025 at 09:51, Luis Gerhorst <luis.gerho...@fau.de> wrote: > > JITs can set bpf_jit_bypass_spec_v1/v4() if they want the verifier to > skip analysis/patching for the respective vulnerability. For v4, this > will reduce the number of barriers the verifier inserts. For v1, it > allows more programs to be accepted. > > The primary motivation for this is to not regress unpriv BPF's > performance on ARM64 in a future commit where BPF_NOSPEC is also used > against Spectre v1. > > This has the user-visible change that v1-induced rejections on > non-vulnerable PowerPC CPUs are avoided. > > For now, this does not change the semantics of BPF_NOSPEC. It is still a > v4-only barrier and must not be implemented if bypass_spec_v4 is always > true for the arch. Changing it to a v1 AND v4-barrier is done in a > future commit. > > As an alternative to bypass_spec_v1/v4, one could introduce NOSPEC_V1 > AND NOSPEC_V4 instructions and allow backends to skip their lowering as > suggested by commit f5e81d111750 ("bpf: Introduce BPF nospec instruction > for mitigating Spectre v4"). Adding bpf_jit_bypass_spec_v1/v4() was > found to be preferable for the following reason: > > * bypass_spec_v1/v4 benefits non-vulnerable CPUs: Always performing the > same analysis (not taking into account whether the current CPU is > vulnerable), needlessly restricts users of CPUs that are not > vulnerable. The only use case for this would be portability-testing, > but this can later be added easily when needed by allowing users to > force bypass_spec_v1/v4 to false. > > * Portability is still acceptable: Directly disabling the analysis > instead of skipping the lowering of BPF_NOSPEC(_V1/V4) might allow > programs on non-vulnerable CPUs to be accepted while the program will > be rejected on vulnerable CPUs. With the fallback to speculation > barriers for Spectre v1 implemented in a future commit, this will only > affect programs that do variable stack-accesses or are very complex. > > For PowerPC, the SEC_FTR checking in bpf_jit_bypass_spec_v4() is based > on the check that was previously located in the BPF_NOSPEC case. > > For LoongArch, it would likely be safe to set both > bpf_jit_bypass_spec_v1() and _v4() according to > commit a6f6a95f2580 ("LoongArch, bpf: Fix jit to skip speculation > barrier opcode"). This is omitted here as I am unable to do any testing > for LoongArch. > > Signed-off-by: Luis Gerhorst <luis.gerho...@fau.de> > Cc: Henriette Herzog <henriette.her...@rub.de> > Cc: Maximilian Ott <o...@cs.fau.de> > Cc: Milan Stephan <milan.step...@fau.de> > ---
I think this and the next patch should have acks from arm and powerpc experts.