All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Feng Jiang" <jiangfeng@kylinos.cn>
Cc: bpf@vger.kernel.org
Subject: Re: [PATCH 1/2] bpf, riscv: add support for timed may_goto
Date: Tue, 14 Jul 2026 03:07:14 +0000	[thread overview]
Message-ID: <20260714030715.3DDED1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260714-riscv-bpf-timed-may-goto-v1-1-3988601fe6ac@kylinos.cn>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Critical] The RISC-V BPF JIT unconditionally moves the native return value (a0) into BPF_REG_0 (a5) after calling arch_bpf_timed_may_goto, silently corrupting BPF_REG_0.
--

--- Patch [1]: [PATCH 1/2] bpf, riscv: add support for timed may_goto ---
commit ed55df1d87b981cbd59d17bd2c3b607f3fa418d9
Author: Feng Jiang <jiangfeng@kylinos.cn>

bpf, riscv: add support for timed may_goto

This patch implements arch_bpf_timed_may_goto() for the RV64 JIT. It also
enables bpf_jit_supports_timed_may_goto() to allow the verifier to use the
timed expansion path. The assembly trampoline is designed to preserve BPF
registers R0-R5 across the call to the generic bpf_check_timed_may_goto().

> diff --git a/arch/riscv/net/bpf_jit_comp64.c b/arch/riscv/net/bpf_jit_comp64.c
> index c03c1de16b79a..9832a19200c75 100644
> --- a/arch/riscv/net/bpf_jit_comp64.c
> +++ b/arch/riscv/net/bpf_jit_comp64.c
[ ... ]
> @@ -2157,3 +2157,8 @@ bool bpf_jit_supports_fsession(void)
>  {
>  	return true;
>  }
> +
> +bool bpf_jit_supports_timed_may_goto(void)
> +{
> +	return true;
> +}

[Severity: Critical]
Will enabling this feature cause the JIT to silently corrupt BPF_REG_0?

When the verifier emits a call to arch_bpf_timed_may_goto with src_reg == 0,
the RISC-V JIT's BPF_JMP | BPF_CALL case handles it. Because src_reg !=
BPF_PSEUDO_CALL, it appears the JIT will unconditionally emit:

arch/riscv/net/bpf_jit_comp64.c:bpf_jit_emit_insn() {
	...
		if (insn->src_reg != BPF_PSEUDO_CALL)
			emit_mv(bpf_to_rv_reg(BPF_REG_0, ctx), RV_REG_A0, ctx);
	...
}

Even though the new assembly trampoline properly restores BPF_REG_0 (a5) and
BPF_REG_1 (a0) before returning, won't this newly emitted mv a5, a0
instruction overwrite BPF_REG_0 with BPF_REG_1 immediately after the call
returns?

Since the verifier assumes BPF_REG_0 is untouched by may_goto, could this
allow unverified pointers in BPF_REG_1 to bypass the verifier and lead to
memory corruption?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260714-riscv-bpf-timed-may-goto-v1-0-3988601fe6ac@kylinos.cn?part=1

  reply	other threads:[~2026-07-14  3:07 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-14  2:58 [PATCH 0/2] bpf, riscv: add timed may_goto support Feng Jiang
2026-07-14  2:58 ` Feng Jiang
2026-07-14  2:58 ` [PATCH 1/2] bpf, riscv: add support for timed may_goto Feng Jiang
2026-07-14  2:58   ` Feng Jiang
2026-07-14  3:07   ` sashiko-bot [this message]
2026-07-14  2:58 ` [PATCH 2/2] selftests/bpf: enable timed may_goto tests for riscv64 Feng Jiang
2026-07-14  2:58   ` Feng Jiang
2026-07-14  3:08   ` sashiko-bot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260714030715.3DDED1F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=jiangfeng@kylinos.cn \
    --cc=sashiko-reviews@lists.linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.