On Fri, Oct 24, 2025 at 10:35 AM Harry Yoo harry.yoo@oracle.com wrote:
An alternative to unpoisoning or disabling KASAN could be to add helper functions annotated with __no_sanitize_address that do the required accesses. And make them inlined when KASAN is disabled to avoid the performance hit.
This sounds reasonable, let me try this instead of unpoisoning metadata. Thanks.
But note that you still need kasan_reset_tag() for HW_TAGS KASAN: this mode is not based on compiler instrumentation and thus __no_sanitize_address has no effect on it.
(There's been some discussion on making __no_sanitize_address work for HW_TAGS: https://bugzilla.kernel.org/show_bug.cgi?id=212513#c2, but this was never attempted.)
On a side note, you might also need to check whether SW_TAGS KASAN and KMSAN would be unhappy with your changes:
- When we do kasan_disable_current() or metadata_access_enable(), we
also do kasan_reset_tag();
- In metadata_access_enable(), we disable KMSAN as well.
Thanks for pointing this out!
Just to clarify, by calling kasan_reset_tag() we clear tag from the address so that SW or HW tag based KASAN won't report access violation? (because there is no valid tag in the address?)
Yeah, kind of: kasan_reset_tag() sets the pointer tag (the top byte) to 0xFF. With SW_TAGS KASAN, the compiler knows not to embed validity checks for accesses through pointers with 0xFF in the top byte. With HW_TAGS KASAN, the CPU is instructed to behave the same.
(This is slightly different than kasan_disable_current(): with kasan_reset_tag(), validity checks do not happen at all. With kasan_disable_current(), the checks happen but the bug reports are ignored.)
Thank you!