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.

Suggested-by: Luis Gerhorst <luis.gerhorst@fau.de>
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
---

This is based on the latest bpf-next tree which contains the
prototype and caller for bpf_jit_bypass_spec_v1/v4().

By the way, it needs to update bpf-next tree before building
on LoongArch:

[Build Error Report] Implicit Function declaration for bpf-next tree
https://lore.kernel.org/bpf/d602ae87-8bed-1633-d5b6-41c5bd8bbcdc@loongson.cn/

 arch/loongarch/net/bpf_jit.c | 10 ++++++++++
 1 file changed, 10 insertions(+)

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;
+}
-- 
2.42.0

Queued for loongarch-next, thanks.


Huacai

On Tue, Jun 17, 2025 at 2:32 PM Tiezhu Yang <yangtiezhu@loongson.cn> wrote:
>
> 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.
>
> Suggested-by: Luis Gerhorst <luis.gerhorst@fau.de>
> Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
> ---
>
> This is based on the latest bpf-next tree which contains the
> prototype and caller for bpf_jit_bypass_spec_v1/v4().
>
> By the way, it needs to update bpf-next tree before building
> on LoongArch:
>
> [Build Error Report] Implicit Function declaration for bpf-next tree
> https://lore.kernel.org/bpf/d602ae87-8bed-1633-d5b6-41c5bd8bbcdc@loongson.cn/
>
>  arch/loongarch/net/bpf_jit.c | 10 ++++++++++
>  1 file changed, 10 insertions(+)
>
> 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;
> +}
> --
> 2.42.0
>
>

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>