Re: [PATCH RFC bpf-next 2/8] bpf: mark instructions accessing program stack

Re: [PATCH RFC bpf-next 2/8] bpf: mark instructions accessing program stack

[Alexis Lothoré]

On Sat Apr 25, 2026 at 7:05 AM CEST, sashiko-bot wrote:

[...]

>>  #define LR_FRAMENO_BITS	3
>>  #define LR_SPI_BITS	6
> [ ... ]
>> @@ -6493,6 +6498,8 @@ static int check_mem_access(struct bpf_verifier_env *env, int insn_idx, u32 regn
>>  		else
>>  			err = check_stack_write(env, regno, off, size,
>>  						value_regno, insn_idx);
>> +
>> +		mark_insn_accesses_stack(env, insn_idx);
>
> Global subprograms are verified independently of their call sites, and pointer
> arguments are tracked as PTR_TO_MEM rather than PTR_TO_STACK. Inside the
> subprogram, check_mem_access() evaluates loads and stores under the
> PTR_TO_MEM branch, which does not invoke mark_insn_accesses_stack().
>
> If a BPF caller dynamically passes a pointer to its stack as an argument to
> the global subprogram, will the JIT-compiled global subprogram execute with
> KASAN checks enabled for those accesses? 
>
> Does this erroneously monitor the BPF stack, bypassing the intended
> suppression mechanism?

After having thought about this one for quite some time, I see no
simple way to correctly distinguish stack accesses hidden behing a
PTR_TO_MEM passed to a global subprog, as those are verified separately.

I can either:
1. skip PTR_TO_MEM memory instrumentation when we are in global
subprograms, at the risk of missing instrumentation on passed memory
accesses that _need_ to be instrumented
2. systematically instrument passed PTR_TO_MEM memory accesses in global
subprog, at the risk of inserting unneeded instrumentation when the
passed memory comes in fact from caller memory.

I then propose to be conservative and apply 2:  the only downside I can
think of is that a few alwasy-passing kasan checks will be inserted, but
we are at least sure not to miss any instrumentation.

-- 
Alexis Lothoré, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Re: [PATCH RFC bpf-next 2/8] bpf: mark instructions accessing program stack

[Alexei Starovoitov]

On Thu, Jun 4, 2026 at 5:23 AM Alexis Lothoré
<alexis.lothore@bootlin.com> wrote:
>
> On Sat Apr 25, 2026 at 7:05 AM CEST, sashiko-bot wrote:
>
> [...]
>
> >>  #define LR_FRAMENO_BITS     3
> >>  #define LR_SPI_BITS 6
> > [ ... ]
> >> @@ -6493,6 +6498,8 @@ static int check_mem_access(struct bpf_verifier_env *env, int insn_idx, u32 regn
> >>              else
> >>                      err = check_stack_write(env, regno, off, size,
> >>                                              value_regno, insn_idx);
> >> +
> >> +            mark_insn_accesses_stack(env, insn_idx);
> >
> > Global subprograms are verified independently of their call sites, and pointer
> > arguments are tracked as PTR_TO_MEM rather than PTR_TO_STACK. Inside the
> > subprogram, check_mem_access() evaluates loads and stores under the
> > PTR_TO_MEM branch, which does not invoke mark_insn_accesses_stack().
> >
> > If a BPF caller dynamically passes a pointer to its stack as an argument to
> > the global subprogram, will the JIT-compiled global subprogram execute with
> > KASAN checks enabled for those accesses?
> >
> > Does this erroneously monitor the BPF stack, bypassing the intended
> > suppression mechanism?
>
> After having thought about this one for quite some time, I see no
> simple way to correctly distinguish stack accesses hidden behing a
> PTR_TO_MEM passed to a global subprog, as those are verified separately.
>
> I can either:
> 1. skip PTR_TO_MEM memory instrumentation when we are in global
> subprograms, at the risk of missing instrumentation on passed memory
> accesses that _need_ to be instrumented
> 2. systematically instrument passed PTR_TO_MEM memory accesses in global
> subprog, at the risk of inserting unneeded instrumentation when the
> passed memory comes in fact from caller memory.
>
> I then propose to be conservative and apply 2:  the only downside I can
> think of is that a few alwasy-passing kasan checks will be inserted, but
> we are at least sure not to miss any instrumentation.

Isn't it the other way around? Replacing LDX with asan_load() will
check stack access, but it doesn't have shadow memory behind it?
Or you mean to assume kasan_vmalloc and vmalloced_stack kconfig?

Re: [PATCH RFC bpf-next 2/8] bpf: mark instructions accessing program stack

[Alexis Lothoré]

On Thu Jun 4, 2026 at 6:24 PM CEST, Alexei Starovoitov wrote:
> On Thu, Jun 4, 2026 at 5:23 AM Alexis Lothoré
> <alexis.lothore@bootlin.com> wrote:
>>
>> On Sat Apr 25, 2026 at 7:05 AM CEST, sashiko-bot wrote:
>>
>> [...]
>>
>> >>  #define LR_FRAMENO_BITS     3
>> >>  #define LR_SPI_BITS 6
>> > [ ... ]
>> >> @@ -6493,6 +6498,8 @@ static int check_mem_access(struct bpf_verifier_env *env, int insn_idx, u32 regn
>> >>              else
>> >>                      err = check_stack_write(env, regno, off, size,
>> >>                                              value_regno, insn_idx);
>> >> +
>> >> +            mark_insn_accesses_stack(env, insn_idx);
>> >
>> > Global subprograms are verified independently of their call sites, and pointer
>> > arguments are tracked as PTR_TO_MEM rather than PTR_TO_STACK. Inside the
>> > subprogram, check_mem_access() evaluates loads and stores under the
>> > PTR_TO_MEM branch, which does not invoke mark_insn_accesses_stack().
>> >
>> > If a BPF caller dynamically passes a pointer to its stack as an argument to
>> > the global subprogram, will the JIT-compiled global subprogram execute with
>> > KASAN checks enabled for those accesses?
>> >
>> > Does this erroneously monitor the BPF stack, bypassing the intended
>> > suppression mechanism?
>>
>> After having thought about this one for quite some time, I see no
>> simple way to correctly distinguish stack accesses hidden behing a
>> PTR_TO_MEM passed to a global subprog, as those are verified separately.
>>
>> I can either:
>> 1. skip PTR_TO_MEM memory instrumentation when we are in global
>> subprograms, at the risk of missing instrumentation on passed memory
>> accesses that _need_ to be instrumented
>> 2. systematically instrument passed PTR_TO_MEM memory accesses in global
>> subprog, at the risk of inserting unneeded instrumentation when the
>> passed memory comes in fact from caller memory.
>>
>> I then propose to be conservative and apply 2:  the only downside I can
>> think of is that a few alwasy-passing kasan checks will be inserted, but
>> we are at least sure not to miss any instrumentation.
>
> Isn't it the other way around? Replacing LDX with asan_load() will
> check stack access, but it doesn't have shadow memory behind it?
> Or you mean to assume kasan_vmalloc and vmalloced_stack kconfig?

Ah yes, my bad, I did not state it explicitely, but my point above
indeed assumes that we are with CONFIG_KASAN_VMALLOC and
CONFIG_VMAP_STACK




-- 
Alexis Lothoré, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Re: [PATCH RFC bpf-next 2/8] bpf: mark instructions accessing program stack

[Alexei Starovoitov]

On Thu, Jun 4, 2026 at 10:14 AM Alexis Lothoré
<alexis.lothore@bootlin.com> wrote:
>
> On Thu Jun 4, 2026 at 6:24 PM CEST, Alexei Starovoitov wrote:
> > On Thu, Jun 4, 2026 at 5:23 AM Alexis Lothoré
> > <alexis.lothore@bootlin.com> wrote:
> >>
> >> On Sat Apr 25, 2026 at 7:05 AM CEST, sashiko-bot wrote:
> >>
> >> [...]
> >>
> >> >>  #define LR_FRAMENO_BITS     3
> >> >>  #define LR_SPI_BITS 6
> >> > [ ... ]
> >> >> @@ -6493,6 +6498,8 @@ static int check_mem_access(struct bpf_verifier_env *env, int insn_idx, u32 regn
> >> >>              else
> >> >>                      err = check_stack_write(env, regno, off, size,
> >> >>                                              value_regno, insn_idx);
> >> >> +
> >> >> +            mark_insn_accesses_stack(env, insn_idx);
> >> >
> >> > Global subprograms are verified independently of their call sites, and pointer
> >> > arguments are tracked as PTR_TO_MEM rather than PTR_TO_STACK. Inside the
> >> > subprogram, check_mem_access() evaluates loads and stores under the
> >> > PTR_TO_MEM branch, which does not invoke mark_insn_accesses_stack().
> >> >
> >> > If a BPF caller dynamically passes a pointer to its stack as an argument to
> >> > the global subprogram, will the JIT-compiled global subprogram execute with
> >> > KASAN checks enabled for those accesses?
> >> >
> >> > Does this erroneously monitor the BPF stack, bypassing the intended
> >> > suppression mechanism?
> >>
> >> After having thought about this one for quite some time, I see no
> >> simple way to correctly distinguish stack accesses hidden behing a
> >> PTR_TO_MEM passed to a global subprog, as those are verified separately.
> >>
> >> I can either:
> >> 1. skip PTR_TO_MEM memory instrumentation when we are in global
> >> subprograms, at the risk of missing instrumentation on passed memory
> >> accesses that _need_ to be instrumented
> >> 2. systematically instrument passed PTR_TO_MEM memory accesses in global
> >> subprog, at the risk of inserting unneeded instrumentation when the
> >> passed memory comes in fact from caller memory.
> >>
> >> I then propose to be conservative and apply 2:  the only downside I can
> >> think of is that a few alwasy-passing kasan checks will be inserted, but
> >> we are at least sure not to miss any instrumentation.
> >
> > Isn't it the other way around? Replacing LDX with asan_load() will
> > check stack access, but it doesn't have shadow memory behind it?
> > Or you mean to assume kasan_vmalloc and vmalloced_stack kconfig?
>
> Ah yes, my bad, I did not state it explicitely, but my point above
> indeed assumes that we are with CONFIG_KASAN_VMALLOC and
> CONFIG_VMAP_STACK

ok, then it's an ok path forward. Better than option 1,
since skipping all of PTR_TO_MEM in global subprogs would leave a big gap.