Re: [RFC] adding KASAN support to JIT compiler(s)

["Alexis Lothoré" <alexis.lothore@bootlin.com>]

On Tue Feb 10, 2026 at 10:43 PM CET, Alexei Starovoitov wrote:
> On Mon, Feb 9, 2026 at 1:03 PM Alexis Lothoré
> <alexis.lothore@bootlin.com> wrote:
>>
>> >> - bpf stack: when a program allocate some memory on its own stack, it is
>> >>   not tracked by KASAN. To be able to track stack memory misusage, JIT
>> >>   compiler must insert some red zones around the variables on the stack.
>> >>   This point looks more complex than the previous ones, as we need to:
>> >>   - identify variables that live on bpf program stack instead of
>> >>     registers
>> >>   - insert asan left/right red zones, and possibly inter-variables red zones
>> >>   - and so account for this "stack overhead", eg in the verifier
>> >>   I then propose to put this "stack monitoring" as a next step, to be
>> >>   implemented once we have a basic kasan monitoring integrated in x86
>> >>   JIT compiler.
>> >
>> > I'm not sure it can be deferred. Pretty much all bpf programs
>> > access stack with load/stores.
>> > So all of such instructions should not be instrumented.
>>
>> I am not sure to get your point here. If the matter can not be deferred
>> (because pretty much all bpf programs access stack with load/stores),
>> then all of such instructions _should_ be instrumented (so that we
>> detect invalid stack accesses), right ? Or am I getting it wrong ?
>
> As far as I understand compilers don't sanitize stack access
> because there is no shadow memory behind it.

Is that so ? Because if I take a look at kasan tests in the kernel, I
find for example this kasan_stack_oob in mm/kasan/kasan_test_c.c:

static void kasan_stack_oob(struct kunit *test)
{
        char stack_array[10];
        /* See comment in kasan_global_oob_right. */
        char *volatile array = stack_array;
        char *p = &array[ARRAY_SIZE(stack_array) + OOB_TAG_OFF];

        KASAN_TEST_NEEDS_CONFIG_ON(test, CONFIG_KASAN_STACK);

        KUNIT_EXPECT_KASAN_FAIL(test, *(volatile char *)p);
}

which gives me, for x86:

0000000000000340 <kasan_stack_oob>:
     340:       f3 0f 1e fa             endbr64
     344:       e8 00 00 00 00          call   349 <kasan_stack_oob+0x9>
     349:       48 ba 00 00 00 00 00    movabs $0xdffffc0000000000,%rdx
     350:       fc ff df
     353:       41 56                   push   %r14
     355:       31 c9                   xor    %ecx,%ecx
     357:       4c 8d b7 e0 01 00 00    lea    0x1e0(%rdi),%r14
     35e:       41 55                   push   %r13
     360:       41 54                   push   %r12
     362:       55                      push   %rbp
     363:       48 89 fd                mov    %rdi,%rbp
     366:       53                      push   %rbx
     367:       48 81 ec c0 00 00 00    sub    $0xc0,%rsp
     36e:       48 89 e0                mov    %rsp,%rax
     371:       48 c7 04 24 b3 8a b5    movq   $0x41b58ab3,(%rsp)
     378:       41
     379:       48 c7 44 24 08 00 00    movq   $0x0,0x8(%rsp)
     380:       00 00
     382:       48 c1 e8 03             shr    $0x3,%rax
     386:       48 c7 44 24 10 00 00    movq   $0x0,0x10(%rsp)
     38d:       00 00
     38f:       48 89 c3                mov    %rax,%rbx
     392:       48 01 d0                add    %rdx,%rax 		<= %rax = (%rsp >> 3) + SHADOW_OFFSET
     395:       c7 00 f1 f1 f1 f1       movl   $0xf1f1f1f1,(%rax) 	<= left red zone
     39b:       c7 40 04 f1 f1 01 f2    movl   $0xf201f1f1,0x4(%rax) 	<= left red zone, ??? (1 byte unpoisoned), mid red zone
     3a2:       c7 40 08 00 f2 f2 f2    movl   $0xf2f2f200,0x8(%rax)	<= mid red zone, array unpoisoned ?
     3a9:       c7 40 0c 00 00 f2 f2    movl   $0xf2f20000,0xc(%rax) 	<= ??? (16 bytes unpoisoned), mid red zone
     3b0:       c7 40 10 00 02 f3 f3    movl   $0xf3f30200,0x10(%rax)	<= stack_array unpoisoned ? right red zone
     [...]

Am I misinterpreting something here ?

For the record, my kernel is compiled with GCC, for x86, with generic,
inlined kasan. Digging a bit more in the corresponding commits and
Kconfig file, I see that this stack monitoring is not enabled for all
architectures and compilers, though.  For example, I see that it is
deemed "unsafe" when using clang.

> There is no "allocation of stack" or "deallocation", so no UAF
> or things like that.
> The kernel already has guard pages for stack overflow and that's
> about it.
>
>> I am not familiar yet with the verifier code, but I then expect this
>> work to potentially bring some changes into it as well (aside from the
>> info to pass to JIT comp. mentioned above). Eg, if adding red zones
>> around stack variables is indeed required, it will increase stack usage,
>> and so the verifier may have to account for those (eg when validating
>> max stack depth ?). I'll have to clarify this kind of point.
>
> Redzones? Around what? There is no way to tell where variables
> are and that one access aliases into another.
> imo existing stack guard pages are enough here.
> So no instrumentation of stack ldx/stx.

Aside from the point above, if guard pages are considered enough, ok
then, I can make sure to make JIT comp ignore stack accesses when
instrumenting load/store insns (with the data passing from the verifier
to be implemented, related to Xu's work).

Thanks,

Alexis

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