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