linux-kernel - Re: [PATCH v8 14/14] x86/kasan: Make software tag-based kasan available

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aWZlpjwMXgdtZGMQ@wieczorr-mobl1.localdomain>
Date: Tue, 13 Jan 2026 16:00:47 +0000
From: Maciej Wieczor-Retman <m.wieczorretman@...me>
To: Borislav Petkov <bp@...en8.de>
Cc: Thomas Gleixner <tglx@...nel.org>, Ingo Molnar <mingo@...hat.com>, 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>, Andrey Konovalov <andreyknvl@...il.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 12:45:39 +0100, Borislav Petkov wrote:
>For all your $Subjects: make sure they have a verb in the name.
>
>For that consult:
>
>https://kernel.org/doc/html/latest/process/maintainer-tip.html#patch-subject
>
>and the following "Changelog" section.

Sure, I'll revise these.

>
>On Mon, Jan 12, 2026 at 05:28:35PM +0000, Maciej Wieczor-Retman wrote:
>> From: Maciej Wieczor-Retman <maciej.wieczor-retman@...el.com>
>
>...
>
>>  Documentation/arch/x86/x86_64/mm.rst | 6 ++++--
>>  arch/x86/Kconfig                     | 4 ++++
>>  arch/x86/boot/compressed/misc.h      | 1 +
>>  arch/x86/include/asm/kasan.h         | 5 +++++
>>  arch/x86/mm/kasan_init_64.c          | 6 ++++++
>>  lib/Kconfig.kasan                    | 3 ++-
>>  6 files changed, 22 insertions(+), 3 deletions(-)
>>
>> diff --git a/Documentation/arch/x86/x86_64/mm.rst b/Documentation/arch/x86/x86_64/mm.rst
>> index a6cf05d51bd8..ccbdbb4cda36 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)
>
>These here are non-overlapping ranges. Yours are overlapping. Why?

The two added lines are two alternative ranges based on which mode is chosen
during compile time. Is there some neater way to note this down here?

>> +   ffffec0000000000 |  -20    TB | fffffbffffffffff |   16 TB | KASAN shadow memory (generic mode)
>> +   or
>> +   fffff40000000000 |   -8    TB | fffffbffffffffff |    8 TB | KASAN shadow memory (software tag-based mode)

Something like this maybe ^ ? Or is the first take okay?

>
>>    __________________|____________|__________________|_________|____________________________________________________________
>>                                                                |
>>                                                                | 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)
>>    __________________|____________|__________________|_________|____________________________________________________________
>>                                                                |
>
>...
>
>> 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");
>
>Why?

My mistake, that string is already printed by kasan_init_generic(), I'll remove
it.

>
>> +
>> +	if (boot_cpu_has(X86_FEATURE_LAM))
>
>cpu_feature_enabled()

Sure, thanks!

>
>> +		kasan_init_sw_tags();
>> +	else
>> +		pr_info("KernelAddressSanitizer not initialized (sw-tags): hardware doesn't support LAM\n");
>
>You just said "initialized". Now it is not? How about we make up our minds
>first and then issue one single true statement?

Yes, I'll keep this one since the "initialized" pr_info() are called from inside
kasan_init_generic() and kasan_init_sw_tags().

>
>--
>Regards/Gruss,
>    Boris.
>
>https://people.kernel.org/tglx/notes-about-netiquette

-- 
Kind regards
Maciej Wieczór-Retman