Re: [PATCH v5 13/19] kasan: x86: Handle int3 for inline KASAN reports

[Maciej Wieczor-Retman]

On 2025-09-09 at 10:40:29 +0200, Peter Zijlstra wrote:
>On Tue, Sep 09, 2025 at 10:34:25AM +0200, Peter Zijlstra wrote:
>> On Tue, Sep 09, 2025 at 10:24:22AM +0200, Maciej Wieczor-Retman wrote:
>> > On 2025-09-08 at 22:19:05 +0200, Andrey Konovalov wrote:
>> > >On Mon, Sep 8, 2025 at 3:09 PM Maciej Wieczor-Retman
>> > ><maciej.wieczor-retman@xxxxxxxxx> wrote:
>> > >>
>> > >> >>I recall there were some corner cases where this code path got called in outline
>> > >> >>mode, didn't have a mismatch but still died due to the die() below. But I'll
>> > >> >>recheck and either apply what you wrote above or get add a better explanation
>> > >> >>to the patch message.
>> > >> >
>> > >> >Okay, so the int3_selftest_ip() is causing a problem in outline mode.
>> > >> >
>> > >> >I tried disabling kasan with kasan_disable_current() but thinking of it now it
>> > >> >won't work because int3 handler will still be called and die() will happen.
>> > >>
>> > >> Sorry, I meant to write that kasan_disable_current() works together with
>> > >> if(!kasan_report()). Because without checking kasan_report()' return
>> > >> value, if kasan is disabled through kasan_disable_current() it will have no
>> > >> effect in both inline mode, and if int3 is called in outline mode - the
>> > >> kasan_inline_handler will lead to die().
>> > >
>> > >So do I understand correctly, that we have no way to distinguish
>> > >whether the int3 was inserted by the KASAN instrumentation or natively
>> > >called (like in int3_selftest_ip())?
>> > >
>> > >If so, I think that we need to fix/change the compiler first so that
>> > >we can distinguish these cases. And only then introduce
>> > >kasan_inline_handler(). (Without kasan_inline_handler(), the outline
>> > >instrumentation would then just work, right?)
>> > >
>> > >If we can distinguish them, then we should only call
>> > >kasan_inline_handler() for the KASAN-inserted int3's. This is what we
>> > >do on arm64 (via brk and KASAN_BRK_IMM). And then int3_selftest_ip()
>> > >should not be affected.
>> > 
>> > Looking at it again I suppose LLVM does pass a number along metadata to the
>> > int3. I didn't notice because no other function checks anything in the x86 int3
>> > handler, compared to how it's done on arm64 with brk.
>> > 
>> > So right, thanks, after fixing it up it shouldn't affect the int3_selftest_ip().
>> 
>> Seriously guys, stop using int3 for this. UBSAN uses UD1, why the heck
>> would KASAN not do the same?
>
>Specifically, look at arch/x86/kernel/traps.h:decode_bug(), UBSan uses
>UD1 /0, I would suggest KASAN to use UD1 /1.

Okay, that sounds great, I'll change it in this patchset and write the LLVM
patch later.

-- 
Kind regards
Maciej Wieczór-Retman