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

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

Hi Alexei, thanks for the feedback,

On Sat Feb 7, 2026 at 4:02 AM CET, Alexei Starovoitov wrote:
> On Fri, Feb 6, 2026 at 3:31 AM Alexis Lothoré
> <alexis.lothore@bootlin.com> wrote:

[...]

>> - similarly to what ASAN is doing ([2]), possibly implement a fast path/slow
>>   path, mechanism:
>>   - fast path: emit instructions to first check the whole corresponding
>>     shadow byte, it it's 0, access is legitimate, jump back to the
>>     actual memory access
>>   - slow path: if the shadow byte is not 0, emit a call to the relevant
>>     __asan_load/storeXXX to validate or report the access.
>
> Are you sure compilers do this optimization for KASAN?
> I don't remember ever seeing it in assembly.
> It sounds interesting, but let's do it in phase 2 when the whole
> thing is working and we start optimizing speed.

I've seen it described in ASAN documentation, but now that you mention
it, I did not see it in generated machine code... Anyway, that's indeed
likely some premature optimization, I'll keep this aside for now.

[...]

>> - bpf global variables: global variables in bpf programs are turned into
>>   maps. Those maps, when created by the kernel, are then already
>>   monitored (ie: poisoned/unpoisoned) when the corresponding memory is
>>   allocated/deallocated. I did not check all maps, but looking at a few
>>   of those, they are vmalloc'ed, so the proper monitoring will depend
>>   directly on CONFIG_KASAN_VMALLOC
>
> bpf global vars are in bpf array. So there is a shadow memory for it.
>
> As far as other map types. There is arena and it's special.
> load/store to arena are JITed differently already.
> They cannot be instrumented for kasan.

ACK, thanks for the clarification.

>> - 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 ?

> It shouldn't be hard to do though.
> The verifier knows all stack accesses.
> It can mark such LDX/STX insns in insn_aux_data with some flag.
> Currently JITs don't have access to verifier info,
> but that's the direction we're going to:
> See proposal:
> https://lore.kernel.org/all/CAADnVQLha64x_LQ1Ph+0dEdP2sNms71k41pwEVMwxrbBG78M5Q@mail.gmail.com/
> It was couple weeks ago. If Xu Kuohai isn't going to follow up
> then this can be a prerequisite.

ACK. I'll follow Xu's work (and collaborate with him if
relevant/helpful), so that JIT comp can use verifier info to properly
monitor stack memory accesses.

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.

[...]

>> - I am also thinking about adding a sysctl (present and enabled by
>>   default if CONFIG_KASAN_EBPF=1), to allow temporarily disabling KASAN
>>   for ebpf programs. When set to 0, JIT compiler would stop inserting
>>   checking instructions in new programs being loaded.
>
> I'm not sure that sysctl is necessary. If the kernel is compiled
> with kasan and JIT supports it, it should go and instrument all progs.
> We can add sysctl later if necessary.

ACK.

Thanks,

Alexis


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