Re: [PATCH bpf-next] LoongArch, bpf: Set bpf_jit_bypass_spec_v1/v4()

[Luis Gerhorst <luis.gerhorst@fau.de>]

Tiezhu Yang <yangtiezhu@loongson.cn> writes:

> JITs can set bpf_jit_bypass_spec_v1/v4() if they want the verifier
> to skip analysis/patching for the respective vulnerability, it is
> safe to set both bpf_jit_bypass_spec_v1/v4(), because there is no
> speculation barrier instruction for LoongArch.

Thank you for addressing this.

Do you think it would be possible to give a more detailed reason for why
Spectre v1/v4 do not affect LoongArch?

Which exploits were tried (and failed) in [3]?

At least from [1] it appears as if there is branch prediction (Figure 5.
LA464 structure, Page 52) and thus also the potential for Spectre v1 (if
there is no hardware countermeasure). For Spectre v4, [1] states
"Supports access optimization techniques such as Non-blocking access and
Load-Speculation" (Chapter 8. LA464 Processor Core). Based on that I
would assume v4 mitigation might also be required.

If there is no countermeasure (and no dedicated speculation barrier), it
would probably be best to lower BPF_NOSPEC to ibar+dbar (leaving
bpf_jit_bypass_spec_v1/v4=false) which might be good enough to make
exploits much harder/impossible.

[1] https://loongson.github.io/LoongArch-Documentation/Loongson-3A5000-usermanual-EN.pdf

> Suggested-by: Luis Gerhorst <luis.gerhorst@fau.de>

Just to clarify, I only suggested it assuming that LoongArch CPUs are
not vulnerable (which I only assumed because of [2]).

[2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=a6f6a95f2580

> diff --git a/arch/loongarch/net/bpf_jit.c b/arch/loongarch/net/bpf_jit.c
> index fa1500d4aa3e..5de8f4c44700 100644
> --- a/arch/loongarch/net/bpf_jit.c
> +++ b/arch/loongarch/net/bpf_jit.c
> @@ -1359,3 +1359,13 @@ bool bpf_jit_supports_subprog_tailcalls(void)
>  {
>  	return true;
>  }
> +
> +bool bpf_jit_bypass_spec_v1(void)
> +{
> +	return true;
> +}
> +
> +bool bpf_jit_bypass_spec_v4(void)
> +{
> +	return true;
> +}

Looks as expected besides the unclarity regarding the countermeasure. In
any case having these set to false (default) does not help if BPF_NOSPEC
is not implemented, thus this is an improvement.

Except for the stated reason:

Acked-by: Luis Gerhorst <luis.gerhorst@fau.de>