Re: [PATCH v10 13/13] x86/kasan: Make software tag-based kasan available

Maciej Wieczor-Retman
2026-02-24T09:10:32Z

On 2026-02-23 at 12:52:03 -0800, Dave Hansen wrote:
>...
>> diff --git a/Documentation/arch/x86/x86_64/mm.rst b/Documentation/arch/x86/x86_64/mm.rst
>> index a6cf05d51bd8..7e2e4c5fa661 100644
>> --- a/Documentation/arch/x86/x86_64/mm.rst
>> +++ b/Documentation/arch/x86/x86_64/mm.rst
>> @@ -60,7 +60,8 @@ Complete virtual memory map with 4-level page tables
>> ffffe90000000000 | -23 TB | ffffe9ffffffffff | 1 TB | ... unused hole
>> ffffea0000000000 | -22 TB | ffffeaffffffffff | 1 TB | virtual memory map (vmemmap_base)
>> ffffeb0000000000 | -21 TB | ffffebffffffffff | 1 TB | ... unused hole
>> - ffffec0000000000 | -20 TB | fffffbffffffffff | 16 TB | KASAN shadow memory
>> + ffffec0000000000 | -20 TB | fffffbffffffffff | 16 TB | KASAN shadow memory (generic mode)
>> + fffff40000000000 | -8 TB | fffffbffffffffff | 8 TB | KASAN shadow memory (software tag-based mode)
>> __________________|____________|__________________|_________|____________________________________________________________
>> |
>> | Identical layout to the 56-bit one from here on:
>> @@ -130,7 +131,8 @@ Complete virtual memory map with 5-level page tables
>> ffd2000000000000 | -11.5 PB | ffd3ffffffffffff | 0.5 PB | ... unused hole
>> ffd4000000000000 | -11 PB | ffd5ffffffffffff | 0.5 PB | virtual memory map (vmemmap_base)
>> ffd6000000000000 | -10.5 PB | ffdeffffffffffff | 2.25 PB | ... unused hole
>> - ffdf000000000000 | -8.25 PB | fffffbffffffffff | ~8 PB | KASAN shadow memory
>> + ffdf000000000000 | -8.25 PB | fffffbffffffffff | ~8 PB | KASAN shadow memory (generic mode)
>> + ffeffc0000000000 | -6 PB | fffffbffffffffff | 4 PB | KASAN shadow memory (software tag-based mode)
>> __________________|____________|__________________|_________|____________________________________________________________
>
>I think the idea of these is that you can run through, find *one* range
>and know what a given address maps to. This adds overlapping ranges.
>Could you make it clear that part of the area is "generic mode" only and
>the other part is for generic mode and for "software tag-based mode"?

Boris suggested adding a footnote to clarify these are alternative ranges [1].
Perhaps I can add a star '*' next to these two so it can notify someone to look for
the footnote?

[1] https://lore.kernel.org/all/20260113161047.GNaWZuh21aoxqtTNXS@fat_crate.local/

>
>> @@ -176,5 +178,9 @@ Be very careful vs. KASLR when changing anything here. The KASLR address
>> range must not overlap with anything except the KASAN shadow area, which is
>> correct as KASAN disables KASLR.
>>
>> +The 'KASAN shadow memory (generic mode)/(software tag-based mode)' ranges are
>> +mutually exclusive and depend on which KASAN setting is chosen:
>> +CONFIG_KASAN_GENERIC or CONFIG_KASAN_SW_TAGS.
>> +
>> For both 4- and 5-level layouts, the KSTACK_ERASE_POISON value in the last 2MB
>> hole: ffffffffffff4111
>> diff --git a/Documentation/dev-tools/kasan.rst b/Documentation/dev-tools/kasan.rst
>> index 64dbf8b308bd..03b508ebe673 100644
>> --- a/Documentation/dev-tools/kasan.rst
>> +++ b/Documentation/dev-tools/kasan.rst
>> @@ -22,8 +22,8 @@ architectures, but it has significant performance and memory overheads.
>>
>> Software Tag-Based KASAN or SW_TAGS KASAN, enabled with CONFIG_KASAN_SW_TAGS,
>> can be used for both debugging and dogfood testing, similar to userspace HWASan.
>> -This mode is only supported for arm64, but its moderate memory overhead allows
>> -using it for testing on memory-restricted devices with real workloads.
>> +This mode is only supported for arm64 and x86, but its moderate memory overhead
>> +allows using it for testing on memory-restricted devices with real workloads.
>>
>> Hardware Tag-Based KASAN or HW_TAGS KASAN, enabled with CONFIG_KASAN_HW_TAGS,
>> is the mode intended to be used as an in-field memory bug detector or as a
>> @@ -351,10 +351,12 @@ Software Tag-Based KASAN
>> Software Tag-Based KASAN uses a software memory tagging approach to checking
>> access validity. It is currently only implemented for the arm64 architecture.
>>
>> -Software Tag-Based KASAN uses the Top Byte Ignore (TBI) feature of arm64 CPUs
>> -to store a pointer tag in the top byte of kernel pointers. It uses shadow memory
>> -to store memory tags associated with each 16-byte memory cell (therefore, it
>> -dedicates 1/16th of the kernel memory for shadow memory).
>> +Software Tag-Based KASAN uses the Top Byte Ignore (TBI) feature of arm64 CPUs to
>> +store a pointer tag in the top byte of kernel pointers. Analogously to TBI on
>> +x86 CPUs Linear Address Masking (LAM) feature is used and the pointer tag is
>> +stored in four bits of the kernel pointer's top byte. Software Tag-Based mode
>> +uses shadow memory to store memory tags associated with each 16-byte memory cell
>> +(therefore, it dedicates 1/16th of the kernel memory for shadow memory).
>
>This is going to get really cumbersome really fast if all the
>architectures doing this add their marketing terms in here.
>
> Software Tag-Based KASAN uses the hardware CPU features* to
> repurpose space inside kernel pointers to store pointer tags.
> ...
>
>and then _elsewhere_ you can describe the two implementations.

Okay, I'll rewrite that.

>
>> On each memory allocation, Software Tag-Based KASAN generates a random tag, tags
>> the allocated memory with this tag, and embeds the same tag into the returned
>> @@ -370,12 +372,14 @@ Software Tag-Based KASAN also has two instrumentation modes (outline, which
>> emits callbacks to check memory accesses; and inline, which performs the shadow
>> memory checks inline). With outline instrumentation mode, a bug report is
>> printed from the function that performs the access check. With inline
>> -instrumentation, a ``brk`` instruction is emitted by the compiler, and a
>> -dedicated ``brk`` handler is used to print bug reports.
>> -
>> -Software Tag-Based KASAN uses 0xFF as a match-all pointer tag (accesses through
>> -pointers with the 0xFF pointer tag are not checked). The value 0xFE is currently
>> -reserved to tag freed memory regions.
>> +instrumentation, arm64's implementation uses the ``brk`` instruction emitted by
>> +the compiler, and a dedicated ``brk`` handler is used to print bug reports. On
>> +x86 inline mode doesn't work yet due to missing compiler support.
>> +
>> +For arm64 Software Tag-Based KASAN uses 0xFF as a match-all pointer tag
>> +(accesses through pointers with the 0xFF pointer tag are not checked). The value
>> +0xFE is currently reserved to tag freed memory regions. On x86 the same tags
>> +take on 0xF and 0xE respectively.
>
>I think this would be more clear with a table or list of features and
>supported architectures.

That is a good idea, I'll work on that

>
>> Hardware Tag-Based KASAN
>> ~~~~~~~~~~~~~~~~~~~~~~~~
>> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
>> index 80527299f859..877668cd5deb 100644
>> --- a/arch/x86/Kconfig
>> +++ b/arch/x86/Kconfig
>> @@ -67,6 +67,7 @@ config X86
>> select ARCH_CLOCKSOURCE_INIT
>> select ARCH_CONFIGURES_CPU_MITIGATIONS
>> select ARCH_CORRECT_STACKTRACE_ON_KRETPROBE
>> + select ARCH_DISABLE_KASAN_INLINE if X86_64 && KASAN_SW_TAGS
>> select ARCH_ENABLE_HUGEPAGE_MIGRATION if X86_64 && HUGETLB_PAGE && MIGRATION
>> select ARCH_ENABLE_MEMORY_HOTPLUG if X86_64
>> select ARCH_ENABLE_MEMORY_HOTREMOVE if MEMORY_HOTPLUG
>> @@ -196,6 +197,8 @@ config X86
>> select HAVE_ARCH_JUMP_LABEL_RELATIVE
>> select HAVE_ARCH_KASAN if X86_64
>> select HAVE_ARCH_KASAN_VMALLOC if X86_64
>> + select HAVE_ARCH_KASAN_SW_TAGS if ADDRESS_MASKING && CC_IS_CLANG
>> + select ARCH_NEEDS_DEFER_KASAN if ADDRESS_MASKING
>> select HAVE_ARCH_KFENCE
>> select HAVE_ARCH_KMSAN if X86_64
>> select HAVE_ARCH_KGDB
>> @@ -410,6 +413,7 @@ config AUDIT_ARCH
>> config KASAN_SHADOW_OFFSET
>> hex
>> depends on KASAN
>> + default 0xeffffc0000000000 if KASAN_SW_TAGS
>> default 0xdffffc0000000000
>
>Please separate this from the documentation.

Okay, I'll split the documentation part into a separate patch.

>
>> config HAVE_INTEL_TXT
>> diff --git a/arch/x86/boot/compressed/misc.h b/arch/x86/boot/compressed/misc.h
>> index fd855e32c9b9..ba70036c2abd 100644
>> --- a/arch/x86/boot/compressed/misc.h
>> +++ b/arch/x86/boot/compressed/misc.h
>> @@ -13,6 +13,7 @@
>> #undef CONFIG_PARAVIRT_SPINLOCKS
>> #undef CONFIG_KASAN
>> #undef CONFIG_KASAN_GENERIC
>> +#undef CONFIG_KASAN_SW_TAGS
>>
>> #define __NO_FORTIFY
>>
>> diff --git a/arch/x86/include/asm/kasan.h b/arch/x86/include/asm/kasan.h
>> index 90c18e30848f..53ab7de16517 100644
>> --- a/arch/x86/include/asm/kasan.h
>> +++ b/arch/x86/include/asm/kasan.h
>> @@ -6,7 +6,12 @@
>> #include <linux/kasan-tags.h>
>> #include <linux/types.h>
>> #define KASAN_SHADOW_OFFSET _AC(CONFIG_KASAN_SHADOW_OFFSET, UL)
>> +
>> +#ifdef CONFIG_KASAN_SW_TAGS
>> +#define KASAN_SHADOW_SCALE_SHIFT 4
>> +#else
>> #define KASAN_SHADOW_SCALE_SHIFT 3
>> +#endif
>>
>> /*
>> * Compiler uses shadow offset assuming that addresses start
>> diff --git a/arch/x86/mm/kasan_init_64.c b/arch/x86/mm/kasan_init_64.c
>> index 7f5c11328ec1..8cbb8ec32061 100644
>> --- a/arch/x86/mm/kasan_init_64.c
>> +++ b/arch/x86/mm/kasan_init_64.c
>> @@ -465,4 +465,9 @@ void __init kasan_init(void)
>>
>> init_task.kasan_depth = 0;
>> kasan_init_generic();
>> +
>> + if (cpu_feature_enabled(X86_FEATURE_LAM))
>> + kasan_init_sw_tags();
>> + else
>> + pr_info("KernelAddressSanitizer not initialized (sw-tags): hardware doesn't support LAM\n");
>> }
>> diff --git a/lib/Kconfig.kasan b/lib/Kconfig.kasan
>> index a4bb610a7a6f..d13ea8da7bfd 100644
>> --- a/lib/Kconfig.kasan
>> +++ b/lib/Kconfig.kasan
>> @@ -112,7 +112,8 @@ config KASAN_SW_TAGS
>>
>> Requires GCC 11+ or Clang.
>>
>> - Supported only on arm64 CPUs and relies on Top Byte Ignore.
>> + Supported on arm64 CPUs that support Top Byte Ignore and on x86 CPUs
>> + that support Linear Address Masking.
>
>Can this read more like:
>
> Supported on:
> arm64: CPUs with Top Byte Ignore
> x86: CPUs with Linear Address Masking.
>
>please?

Sure, I'll change it.

--
Kind regards
Maciej Wieczór-Retman