From: Dave Hansen <dave.hansen@intel.com>
To: Maciej Wieczor-Retman <m.wieczorretman@pm.me>,
Thomas Gleixner <tglx@kernel.org>, Ingo Molnar <mingo@redhat.com>,
Borislav Petkov <bp@alien8.de>,
Dave Hansen <dave.hansen@linux.intel.com>,
x86@kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
Andy Lutomirski <luto@kernel.org>,
Peter Zijlstra <peterz@infradead.org>
Cc: Maciej Wieczor-Retman <maciej.wieczor-retman@intel.com>,
Alexander Potapenko <glider@google.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v10 10/13] x86/mm: Initialize LAM_SUP
Date: Mon, 23 Feb 2026 12:43:06 -0800 [thread overview]
Message-ID: <5a25c22b-1ed8-491a-839a-a2374242b575@intel.com> (raw)
In-Reply-To: <1e266ddf1bf0b187028110e871078baa77cd3583.1770232424.git.m.wieczorretman@pm.me>
On 2/4/26 11:20, Maciej Wieczor-Retman wrote:
> From: Maciej Wieczor-Retman <maciej.wieczor-retman@intel.com>
>
> To make use of KASAN's tag based mode on x86, Linear Address Masking
> (LAM) needs to be enabled. To do that the 28th bit in CR4 has to be set.
I don't think we need to know the bit number in the changelog.
> Set the bit in early memory initialization.
Why does it need to be done early?
> When launching secondary CPUs the LAM bit gets lost. To avoid this add
> it in a mask in head_64.S. The bitmask permits some bits of CR4 to pass
> from the primary CPU to the secondary CPUs without being cleared.
Why does it get lost? Is it special somehow or is this normal for the
other CR4 bits? It sounds like it is normal, so let's lead with that.
next prev parent reply other threads:[~2026-02-23 20:43 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-04 19:18 [PATCH v10 00/13] kasan: x86: arm64: KASAN tag-based mode for x86 Maciej Wieczor-Retman
2026-02-04 19:19 ` [PATCH v10 01/13] kasan: sw_tags: Use arithmetic shift for shadow computation Maciej Wieczor-Retman
2026-03-05 19:05 ` Andrey Ryabinin
2026-03-05 20:18 ` Maciej Wieczor-Retman
2026-03-05 21:22 ` Andrey Ryabinin
2026-03-05 21:25 ` Maciej Wieczor-Retman
2026-02-04 19:19 ` [PATCH v10 02/13] kasan: arm64: x86: Make special tags arch specific Maciej Wieczor-Retman
2026-02-04 19:19 ` [PATCH v10 03/13] kasan: Fix inline mode for x86 tag-based mode Maciej Wieczor-Retman
2026-02-04 19:19 ` [PATCH v10 04/13] x86/kasan: Add arch specific kasan functions Maciej Wieczor-Retman
2026-02-04 19:19 ` [PATCH v10 05/13] x86/mm: Reset tag for virtual to physical address conversions Maciej Wieczor-Retman
2026-02-04 19:20 ` [PATCH v10 06/13] mm/execmem: Untag addresses in EXECMEM_ROX related pointer arithmetic Maciej Wieczor-Retman
2026-02-04 19:20 ` [PATCH v10 07/13] x86/mm: Use physical address comparisons in fill_p*d/pte Maciej Wieczor-Retman
2026-02-23 20:36 ` Dave Hansen
2026-02-04 19:20 ` [PATCH v10 08/13] x86/kasan: Initialize KASAN raw shadow memory Maciej Wieczor-Retman
2026-02-04 19:20 ` [PATCH v10 09/13] x86/mm: Reset tags in a canonical address helper call Maciej Wieczor-Retman
2026-02-23 20:39 ` Dave Hansen
2026-02-24 8:57 ` Maciej Wieczor-Retman
2026-02-26 19:39 ` Dave Hansen
2026-02-27 8:24 ` Maciej Wieczor-Retman
2026-02-04 19:20 ` [PATCH v10 10/13] x86/mm: Initialize LAM_SUP Maciej Wieczor-Retman
2026-02-23 20:43 ` Dave Hansen [this message]
2026-02-24 9:05 ` Maciej Wieczor-Retman
2026-02-04 19:20 ` [PATCH v10 11/13] x86: Increase minimal SLAB alignment for KASAN Maciej Wieczor-Retman
2026-02-04 19:20 ` [PATCH v10 12/13] x86/kasan: Use a logical bit shift for kasan_mem_to_shadow Maciej Wieczor-Retman
2026-02-04 19:20 ` [PATCH v10 13/13] x86/kasan: Make software tag-based kasan available Maciej Wieczor-Retman
2026-02-23 20:52 ` Dave Hansen
2026-02-24 9:10 ` Maciej Wieczor-Retman
2026-02-26 23:29 ` Dave Hansen
2026-02-27 8:27 ` Maciej Wieczor-Retman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5a25c22b-1ed8-491a-839a-a2374242b575@intel.com \
--to=dave.hansen@intel.com \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=glider@google.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=m.wieczorretman@pm.me \
--cc=maciej.wieczor-retman@intel.com \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=tglx@kernel.org \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®