* Re: [PATCH RFC bpf-next 2/8] bpf: mark instructions accessing program stack [not found] ` <20260425050557.827F3C2BCB2@smtp.kernel.org> @ 2026-06-04 12:08 ` Alexis Lothoré 2026-06-04 16:24 ` Alexei Starovoitov 0 siblings, 1 reply; 4+ messages in thread From: Alexis Lothoré @ 2026-06-04 12:08 UTC (permalink / raw) To: sashiko, Alexis Lothoré (eBPF Foundation); +Cc: bpf 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH RFC bpf-next 2/8] bpf: mark instructions accessing program stack 2026-06-04 12:08 ` [PATCH RFC bpf-next 2/8] bpf: mark instructions accessing program stack Alexis Lothoré @ 2026-06-04 16:24 ` Alexei Starovoitov 2026-06-04 17:14 ` Alexis Lothoré 0 siblings, 1 reply; 4+ messages in thread From: Alexei Starovoitov @ 2026-06-04 16:24 UTC (permalink / raw) To: Alexis Lothoré; +Cc: sashiko, bpf 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? ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH RFC bpf-next 2/8] bpf: mark instructions accessing program stack 2026-06-04 16:24 ` Alexei Starovoitov @ 2026-06-04 17:14 ` Alexis Lothoré 2026-06-04 17:29 ` Alexei Starovoitov 0 siblings, 1 reply; 4+ messages in thread From: Alexis Lothoré @ 2026-06-04 17:14 UTC (permalink / raw) To: Alexei Starovoitov, Alexis Lothoré; +Cc: sashiko, bpf 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH RFC bpf-next 2/8] bpf: mark instructions accessing program stack 2026-06-04 17:14 ` Alexis Lothoré @ 2026-06-04 17:29 ` Alexei Starovoitov 0 siblings, 0 replies; 4+ messages in thread From: Alexei Starovoitov @ 2026-06-04 17:29 UTC (permalink / raw) To: Alexis Lothoré; +Cc: sashiko, bpf 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. ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2026-06-04 17:30 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <20260413-kasan-v1-2-1a5831230821@bootlin.com>
[not found] ` <20260425050557.827F3C2BCB2@smtp.kernel.org>
2026-06-04 12:08 ` [PATCH RFC bpf-next 2/8] bpf: mark instructions accessing program stack Alexis Lothoré
2026-06-04 16:24 ` Alexei Starovoitov
2026-06-04 17:14 ` Alexis Lothoré
2026-06-04 17:29 ` Alexei Starovoitov
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox