linux-kernel - Re: [PATCH bpf-next] LoongArch, bpf: Set bpf_jit_bypass_spec

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <87a5665eyv.fsf@fau.de>
Date: Tue, 17 Jun 2025 21:46:00 +0200
From: Luis Gerhorst <luis.gerhorst@....de>
To: Tiezhu Yang <yangtiezhu@...ngson.cn>
Cc: Alexei Starovoitov <ast@...nel.org>,  Daniel Borkmann
 <daniel@...earbox.net>,  Andrii Nakryiko <andrii@...nel.org>,  Hengqi Chen
 <hengqi.chen@...il.com>,  bpf@...r.kernel.org,  loongarch@...ts.linux.dev,
  linux-kernel@...r.kernel.org
Subject: Re: [PATCH bpf-next] LoongArch, bpf: Set bpf_jit_bypass_spec_v1/v4()

Tiezhu Yang <yangtiezhu@...ngson.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@....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@....de>