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(). > >> > >> >What did you mean by "return the same value regardless of kasan_report()"? Then >> >it will never reach the kasan_inline_recover() which I assume is needed for >> >inline mode (once recover will work). > >I meant that with the recovery always enabled, it should not matter >whether the report is suppressed (kasan_report() returns false) or >printed (returns true). We should always skip over the int3 >instruction and continue the execution. -- Kind regards Maciej Wieczór-Retman
