[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aWZh-4FlO5VVvkpQ@wieczorr-mobl1.localdomain>
Date: Tue, 13 Jan 2026 15:31:38 +0000
From: Maciej Wieczor-Retman <m.wieczorretman@...me>
To: Andrey Konovalov <andreyknvl@...il.com>
Cc: Thomas Gleixner <tglx@...nel.org>, Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>, Dave Hansen <dave.hansen@...ux.intel.com>, x86@...nel.org, "H. Peter Anvin" <hpa@...or.com>, Jonathan Corbet <corbet@....net>, Andrey Ryabinin <ryabinin.a.a@...il.com>, Alexander Potapenko <glider@...gle.com>, Dmitry Vyukov <dvyukov@...gle.com>, Vincenzo Frascino <vincenzo.frascino@....com>, Andy Lutomirski <luto@...nel.org>, Peter Zijlstra <peterz@...radead.org>, Andrew Morton <akpm@...ux-foundation.org>, Maciej Wieczor-Retman <maciej.wieczor-retman@...el.com>, linux-kernel@...r.kernel.org, linux-doc@...r.kernel.org, kasan-dev@...glegroups.com
Subject: Re: [PATCH v8 14/14] x86/kasan: Make software tag-based kasan available
On 2026-01-13 at 02:21:47 +0100, Andrey Konovalov wrote:
>On Mon, Jan 12, 2026 at 6:28 PM Maciej Wieczor-Retman
><m.wieczorretman@...me> wrote:
>>
>> From: Maciej Wieczor-Retman <maciej.wieczor-retman@...el.com>
...
>> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
>> index 80527299f859..21c71d9e0698 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
>> + select ARCH_NEEDS_DEFER_KASAN if ADDRESS_MASKING
>
>Do we need this?
I added this to solve the problem "what should happen when there is no hardware
support (discovered at runtime) but someone requested/compiled the kernel with
LAM and KASAN sw_tags?". I think Samuel suggested the static keys approach
during v6 to solve this issue.
As I recall without it the kernel would just freeze since it would try doing a
bunch of LAM+KASAN related things without LAM working. So that'd end with
various faults and violations.
Technically kasan_init_sw_tags() is locked behind:
if (boot_cpu_has(X86_FEATURE_LAM))
but not running kasan_init_sw_tags() normally doesn't actually disable software
KASAN if we don't have LAM available. Without ARCH_NEEDS_DEFER_KASAN it just
checks whether CONFIG_KASAN is enabled which it would in this scenario.
>
>> 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
>>
>> 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 9b7951a79753..b38a1a83af96 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..3a5577341805 100644
>> --- a/arch/x86/mm/kasan_init_64.c
>> +++ b/arch/x86/mm/kasan_init_64.c
>> @@ -465,4 +465,10 @@ void __init kasan_init(void)
>>
>> init_task.kasan_depth = 0;
>> kasan_init_generic();
>> + pr_info("KernelAddressSanitizer initialized\n");
>
>This pr_info is not needed, kasan_init_generic already prints the message.
Thanks! I'll get rid of it.
>
>> +
>> + if (boot_cpu_has(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.
>>
>> Consumes about 1/16th of available memory at kernel start and
>> add an overhead of ~20% for dynamic allocations.
>> --
>> 2.52.0
>>
>>
--
Kind regards
Maciej Wieczór-Retman
Powered by blists - more mailing lists