All of lore.kernel.org
 help / color / mirror / Atom feed
From: Leon Hwang <leon.hwang@linux.dev>
To: sashiko-reviews@lists.linux.dev
Cc: bpf@vger.kernel.org
Subject: Re: [PATCH bpf-next v7 02/11] bpf: Disallow interpreter fallback for user BPF_ADDR_SPACE_CAST insn
Date: Tue, 23 Jun 2026 12:00:52 +0800	[thread overview]
Message-ID: <f8abb228-f46a-4574-98e7-e7af75680537@linux.dev> (raw)
In-Reply-To: <20260622150759.EC9071F000E9@smtp.kernel.org>

On 22/6/26 23:07, sashiko-bot@kernel.org wrote:
[...]
>> diff --git a/kernel/bpf/core.c b/kernel/bpf/core.c
>> index 649cce41e13f3..49398b5bd172d 100644
>> --- a/kernel/bpf/core.c
>> +++ b/kernel/bpf/core.c
>> @@ -2620,6 +2620,7 @@ struct bpf_prog *__bpf_prog_select_runtime(struct bpf_verifier_env *env, struct
>>  		goto finalize;
>>  
>>  	if (IS_ENABLED(CONFIG_BPF_JIT_ALWAYS_ON) ||
>> +	    fp->aux->has_addr_space_cast_insn ||
>>  	    bpf_prog_has_kfunc_call(fp))
>>  		jit_needed = true;
> 
> [Severity: Medium]
> If JIT is disabled or fails, returning -ENOTSUPP here will reject the
> program load silently without a verifier log message. Unlike
> bpf_prog_has_kfunc_call() which provides a helpful verbose() log in
> bpf_fixup_call_args():
> 
> 	if (has_kfunc_call) {
> 		verbose(env, "calling kernel functions are not allowed in non-JITed programs\n");
> 		return -EINVAL;
> 	}
> 
> Users encountering this for has_addr_space_cast_insn will not see an
> explanation for the EOPNOTSUPP error. Could we add a verifier log message
> explaining why JIT is required here?
> 

No verifier log support here.

The verifier log has been finalized before calling
__bpf_prog_select_runtime() in bpf_check().

>> diff --git a/kernel/bpf/fixups.c b/kernel/bpf/fixups.c
>> index 3cf2cc6e3ab66..2d5958774b61b 100644
>> --- a/kernel/bpf/fixups.c
>> +++ b/kernel/bpf/fixups.c
>> @@ -1523,6 +1523,8 @@ int bpf_do_misc_fixups(struct bpf_verifier_env *env)
>>  				insn->off = 0;
>>  				insn->imm = 0;
>>  			} /* cast from as(0) to as(1) should be handled by JIT */
>> +			if (insn_is_cast_user(insn))
>> +				prog->aux->has_addr_space_cast_insn = true;
> 
> [Severity: Critical]
> This is a pre-existing issue, but the patch attempts to fix interpreter
> fallback for BPF_ADDR_SPACE_CAST and fails to address the underlying panic
> with arena programs.
> 
> If a program uses an arena and obtains a PTR_TO_ARENA without a cast_user
> instruction (for instance, using cast_kern), or if the arena map has
> BPF_F_NO_USER_CONV set, has_addr_space_cast_insn will not be set.
> 
> In the case of BPF_F_NO_USER_CONV, the instruction is rewritten to
> BPF_ALU | BPF_MOV | BPF_X right before the insn_is_cast_user() check.
> 
> Memory accesses using PTR_TO_ARENA are rewritten by bpf_do_misc_fixups()
> to use BPF_PROBE_MEM32 or BPF_PROBE_MEM32SX. If these arena programs fall
> back to the interpreter, wouldn't they hit the BUG_ON(1) in ___bpf_prog_run()
> because it lacks handlers for these opcodes?
> 
> kernel/bpf/core.c:___bpf_prog_run() {
>     ...
> 	default_label:
> 		pr_warn("BPF interpreter: unknown opcode %02x (imm: 0x%x)\n",
> 			insn->code, insn->imm);
> 		BUG_ON(1);
>     ...
> }
> 
> Should jit_needed be enforced in __bpf_prog_select_runtime() for all
> programs using fp->aux->arena instead?
> 

Sounds reasonable.

However, I think such similar issues should be fixed using separate
patches: all interpreter-unsupported insns should be marked as JIT-needed.

Like the way of "bpf: Fix unaligned interpreter panic on JIT fallback
path" [1], we can verify whether there are the following insns in the
prog by scanning prog->insnsi:

* user ADDR_SPACE_CAST
* PROBE_MEM32, PROBE_MEM32SX
* ADDR_PERCPU
* PROBE_ATOMIC
* indirect jump using insn_array map

I think these insns are not supported by interpreter.

Link:
[1]
https://lore.kernel.org/bpf/20260615025316.24429-1-yangtiezhu@loongson.cn/

Thanks,
Leon


  reply	other threads:[~2026-06-23  4:01 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-22 14:35 [PATCH bpf-next v7 00/11] bpf: Introduce global percpu data Leon Hwang
2026-06-22 14:35 ` [PATCH bpf-next v7 01/11] bpf: Drop duplicate blank lines in verifier Leon Hwang
2026-06-22 14:35 ` [PATCH bpf-next v7 02/11] bpf: Disallow interpreter fallback for user BPF_ADDR_SPACE_CAST insn Leon Hwang
2026-06-22 15:07   ` sashiko-bot
2026-06-23  4:00     ` Leon Hwang [this message]
2026-06-22 14:35 ` [PATCH bpf-next v7 03/11] bpf: Disallow interpreter fallback for BPF_ADDR_PERCPU insn Leon Hwang
2026-06-22 14:35 ` [PATCH bpf-next v7 04/11] bpf: Introduce global percpu data Leon Hwang
2026-06-22 14:35 ` [PATCH bpf-next v7 05/11] libbpf: Probe percpu data feature Leon Hwang
2026-06-22 14:35 ` [PATCH bpf-next v7 06/11] libbpf: Add support for global percpu data Leon Hwang
2026-06-22 14:35 ` [PATCH bpf-next v7 07/11] bpftool: Generate skeleton " Leon Hwang
2026-06-22 14:35 ` [PATCH bpf-next v7 08/11] selftests/bpf: Add tests to verify " Leon Hwang
2026-06-22 14:57   ` sashiko-bot
2026-06-23  4:04     ` Leon Hwang
2026-06-22 15:24   ` bot+bpf-ci
2026-06-23  4:02     ` Leon Hwang
2026-06-22 14:35 ` [PATCH bpf-next v7 09/11] selftests/bpf: Add test to verify accessing rdonly percpu_array Leon Hwang
2026-06-22 14:35 ` [PATCH bpf-next v7 10/11] selftests/bpf: Add tests to verify verifier log for global percpu data Leon Hwang
2026-06-22 14:35 ` [PATCH bpf-next v7 11/11] selftests/bpf: Add test to verify bpf_iter " Leon Hwang
2026-06-22 15:08   ` sashiko-bot
2026-06-23  4:05     ` Leon Hwang
2026-06-22 15:24   ` bot+bpf-ci
2026-06-23  4:04     ` Leon Hwang

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=f8abb228-f46a-4574-98e7-e7af75680537@linux.dev \
    --to=leon.hwang@linux.dev \
    --cc=bpf@vger.kernel.org \
    --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.