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?
