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
