Re: [PATCH v4 13/18] kasan: arm64: x86: Handle int3 for inline KASAN reports

[Maciej Wieczor-Retman <maciej.wieczor-retman@intel.com>]

On 2025-09-08 at 17:40:52 +0200, Peter Zijlstra wrote:
>On Mon, Aug 18, 2025 at 08:26:11AM +0200, Maciej Wieczor-Retman wrote:
>> On 2025-08-13 at 17:17:02 +0200, Peter Zijlstra wrote:
>> >On Tue, Aug 12, 2025 at 03:23:49PM +0200, Maciej Wieczor-Retman wrote:
>> >> Inline KASAN on x86 does tag mismatch reports by passing the faulty
>> >> address and metadata through the INT3 instruction - scheme that's setup
>> >> in the LLVM's compiler code (specifically HWAddressSanitizer.cpp).
>> >> 
>> >> Add a kasan hook to the INT3 handling function.
>> >> 
>> >> Disable KASAN in an INT3 core kernel selftest function since it can raise
>> >> a false tag mismatch report and potentially panic the kernel.
>> >> 
>> >> Make part of that hook - which decides whether to die or recover from a
>> >> tag mismatch - arch independent to avoid duplicating a long comment on
>> >> both x86 and arm64 architectures.
>> >> 
>> >> Signed-off-by: Maciej Wieczor-Retman <maciej.wieczor-retman@intel.com>
>> >
>> >Can we please split this into an arm64 and x86 patch. Also, why use int3
>> >here rather than a #UD trap, which we use for all other such cases?
>> 
>> Sure, two patches seem okay. I'll first add all the new functions and modify the
>> x86 code, then add the arm64 patch which will replace its die() + comment with
>> kasan_inline_recover().
>> 
>> About INT3 I'm not sure, it's just how it's written in the LLVM code. I didn't
>> see any justification why it's not #UD. My guess is SMD describes INT3 as an
>> interrupt for debugger purposes while #UD is described as "for software
>> testing". So from the documentation point INT3 seems to have a stronger case.
>> 
>> Does INT3 interfere with something? Or is #UD better just because of
>> consistency?
>
>INT3 from kernel space is already really tricky, since it is used for
>self-modifying code.
>
>I suppose we *can* do this, but #UD is already set up to effectively
>forward to WARN and friends, and has UBSAN integration. Its just really
>weird to have KASAN do something else again.

Ah, I see, the handle_bug(). Then perhaps it's better to move the kasan
handler there and then patch LLVM to use #UD instead. Thanks!

-- 
Kind regards
Maciej Wieczór-Retman