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