From: Sean Christopherson <seanjc@google.com>
To: Maciej Wieczor-Retman <maciej.wieczor-retman@intel.com>
Cc: Andrey Ryabinin <ryabinin.a.a@gmail.com>,
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>,
Alexander Potapenko <glider@google.com>,
linux-kernel@vger.kernel.org,
Paolo Bonzini <pbonzini@redhat.com>, kvm <kvm@vger.kernel.org>
Subject: Re: [PATCH v8 09/14] x86/mm: LAM compatible non-canonical definition
Date: Fri, 16 Jan 2026 09:00:42 -0800 [thread overview]
Message-ID: <aWpuuiuqZhkGRj2B@google.com> (raw)
In-Reply-To: <aWpb1AnRHW2yupZp@wieczorr-mobl1.localdomain>
On Fri, Jan 16, 2026, Maciej Wieczor-Retman wrote:
> On 2026-01-16 at 06:57:04 -0800, Sean Christopherson wrote:
> >On Fri, Jan 16, 2026, Andrey Ryabinin wrote:
> >> On 1/12/26 6:28 PM, Maciej Wieczor-Retman wrote:
> >> > diff --git a/arch/x86/include/asm/page.h b/arch/x86/include/asm/page.h
> >> > index bcf5cad3da36..b7940fa49e64 100644
> >> > --- a/arch/x86/include/asm/page.h
> >> > +++ b/arch/x86/include/asm/page.h
> >> > @@ -82,9 +82,22 @@ static __always_inline void *pfn_to_kaddr(unsigned long pfn)
> >> > return __va(pfn << PAGE_SHIFT);
> >> > }
> >> >
> >> > +#ifdef CONFIG_KASAN_SW_TAGS
> >> > +#define CANONICAL_MASK(vaddr_bits) (BIT_ULL(63) | BIT_ULL((vaddr_bits) - 1))
> >>
> >> why is the choice of CANONICAL_MASK() gated at compile time? Shouldn’t this be a
> >> runtime decision based on whether LAM is enabled or not on the running system?
>
> What would be appropriate for KVM? Instead of using #ifdefs checking
> if(cpu_feature_enabled(X86_FEATURE_LAM))?
None of the above. Practically speaking, the kernel APIs simply can't automatically
handle the checks, because they are dependent on guest virtual CPU state, _and_
on the exact operation. E.g. LAM doesn't apply to inputs to TLB invalidation
instructions like INVVPID and INVPCID.
By the time KVM invokes __is_canonical_address(), KVM has already done the necessary
LAM unmasking. E.g. having KVM pass in a flag saying it doesn't need LAM masking
would be rather silly.
> >> > +#else
> >> > +#define CANONICAL_MASK(vaddr_bits) GENMASK_ULL(63, vaddr_bits)
> >> > +#endif
> >> > +
> >> > +/*
> >> > + * To make an address canonical either set or clear the bits defined by the
> >> > + * CANONICAL_MASK(). Clear the bits for userspace addresses if the top address
> >> > + * bit is a zero. Set the bits for kernel addresses if the top address bit is a
> >> > + * one.
> >> > + */
> >> > static __always_inline u64 __canonical_address(u64 vaddr, u8 vaddr_bits)
> >>
> >> +Cc KVM
> >
> >Thanks!
> >
> >> This is used extensively in KVM code. As far as I can tell, it may be used to
> >> determine whether a guest virtual address is canonical or not.
> >
> >Yep, KVM uses this both to check canonical addresses and to force a canonical
> >address (Intel and AMD disagree on the MSR_IA32_SYSENTER_{EIP,ESP} semantics in
> >64-bit mode) for guest addresses. This change will break KVM badly if KASAN_SW_TAGS=y.
>
> Oh, thanks! That's good to know.
>
> >
> >> case, the result should depend on whether LAM is enabled for the guest, not
> >> the host (and certainly not a host's compile-time option).
> >
> >Ya, KVM could roll its own versions, but IMO these super low level helpers should
> >do exactly what they say. E.g. at a glance, I'm not sure pt_event_addr_filters_sync()
> >should be subjected to KASAN_SW_TAGS either. If that's true, then AFAICT the
> >_only_ code that wants the LAM-aware behavior is copy_from_kernel_nofault_allowed(),
> >so maybe just handle it there? Not sure that's a great long-term maintenance
> >story either though.
>
> Yes, longterm it's probably best to just get it right in here.
As above, I don't think that's feasible, because the context of both the current
(virtual) CPU and the usage matters. In other words, making __canonical_address()
itself LAM-aware feels wrong.
Actually, the kernel already has to deal with masking LAM bits for userspace
addresses, and this series needs to unmask kernel address in other flows that
effectively consume virtual addresses in software, so why not just do something
similar for copy_from_kernel_nofault_allowed()?
diff --git a/arch/x86/mm/maccess.c b/arch/x86/mm/maccess.c
index 42115ac079cf..0b3c96f8902a 100644
--- a/arch/x86/mm/maccess.c
+++ b/arch/x86/mm/maccess.c
@@ -33,7 +33,8 @@ bool copy_from_kernel_nofault_allowed(const void *unsafe_src, size_t size)
if (!boot_cpu_data.x86_virt_bits)
return true;
- return __is_canonical_address(vaddr, boot_cpu_data.x86_virt_bits);
+ return __is_canonical_address(__tag_reset(vaddr),
+ boot_cpu_data.x86_virt_bits);
}
#else
bool copy_from_kernel_nofault_allowed(const void *unsafe_src, size_t size)
next prev parent reply other threads:[~2026-01-16 17:00 UTC|newest]
Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-12 17:26 [PATCH v8 00/14] kasan: x86: arm64: KASAN tag-based mode for x86 Maciej Wieczor-Retman
2026-01-12 17:27 ` [PATCH v8 01/14] kasan: sw_tags: Use arithmetic shift for shadow computation Maciej Wieczor-Retman
2026-01-15 22:42 ` Andrey Ryabinin
2026-01-16 13:11 ` Maciej Wieczor-Retman
2026-01-12 17:27 ` [PATCH v8 02/14] kasan: arm64: x86: Make special tags arch specific Maciej Wieczor-Retman
2026-01-13 1:21 ` Andrey Konovalov
2026-01-13 17:32 ` Maciej Wieczor-Retman
2026-01-16 13:32 ` Andrey Ryabinin
2026-01-12 17:27 ` [PATCH v8 03/14] kasan: Fix inline mode for x86 tag-based mode Maciej Wieczor-Retman
2026-01-16 13:33 ` Andrey Ryabinin
2026-01-12 17:27 ` [PATCH v8 04/14] x86/kasan: Add arch specific kasan functions Maciej Wieczor-Retman
2026-01-13 1:21 ` Andrey Konovalov
2026-01-13 16:12 ` Maciej Wieczor-Retman
2026-01-16 13:35 ` Andrey Ryabinin
2026-01-12 17:27 ` [PATCH v8 05/14] x86/mm: Reset tag for virtual to physical address conversions Maciej Wieczor-Retman
2026-01-12 17:27 ` [PATCH v8 06/14] mm/execmem: Untag addresses in EXECMEM_ROX related pointer arithmetic Maciej Wieczor-Retman
2026-01-12 17:27 ` [PATCH v8 07/14] x86/mm: Physical address comparisons in fill_p*d/pte Maciej Wieczor-Retman
2026-01-12 17:28 ` [PATCH v8 08/14] x86/kasan: KASAN raw shadow memory PTE init Maciej Wieczor-Retman
2026-01-16 13:36 ` Andrey Ryabinin
2026-01-12 17:28 ` [PATCH v8 09/14] x86/mm: LAM compatible non-canonical definition Maciej Wieczor-Retman
2026-01-16 14:25 ` Andrey Ryabinin
2026-01-16 14:57 ` Sean Christopherson
2026-01-16 15:56 ` Maciej Wieczor-Retman
2026-01-16 17:00 ` Sean Christopherson [this message]
2026-01-16 17:09 ` Maciej Wieczor-Retman
2026-01-12 17:28 ` [PATCH v8 10/14] x86/mm: LAM initialization Maciej Wieczor-Retman
2026-01-12 17:28 ` [PATCH v8 11/14] x86: Minimal SLAB alignment Maciej Wieczor-Retman
2026-01-12 17:28 ` [PATCH v8 12/14] arm64: Unify software tag-based KASAN inline recovery path Maciej Wieczor-Retman
2026-01-12 17:28 ` [PATCH v8 13/14] x86/kasan: Logical bit shift for kasan_mem_to_shadow Maciej Wieczor-Retman
2026-01-13 1:21 ` Andrey Konovalov
2026-01-14 16:52 ` Maciej Wieczor-Retman
2026-01-15 3:57 ` Andrey Konovalov
2026-01-15 16:43 ` Maciej Wieczor-Retman
2026-01-17 1:21 ` Andrey Konovalov
2026-01-17 6:53 ` Maciej Wieczór-Retman
2026-01-19 11:40 ` Maciej Wieczor-Retman
2026-01-12 17:28 ` [PATCH v8 14/14] x86/kasan: Make software tag-based kasan available Maciej Wieczor-Retman
2026-01-13 1:21 ` Andrey Konovalov
2026-01-13 15:31 ` Maciej Wieczor-Retman
2026-01-13 11:45 ` Borislav Petkov
2026-01-13 16:00 ` Maciej Wieczor-Retman
2026-01-13 16:10 ` Borislav Petkov
2026-01-12 18:29 ` [PATCH v8 00/14] kasan: x86: arm64: KASAN tag-based mode for x86 Andrew Morton
2026-01-12 20:08 ` Maciej Wieczór-Retman
2026-01-12 20:53 ` Andrew Morton
2026-01-13 1:47 ` Andrey Konovalov
2026-01-12 20:27 ` Dave Hansen
2026-01-13 11:47 ` Borislav Petkov
2026-01-13 17:34 ` Andrew Morton
2026-01-22 17:25 ` Maciej Wieczor-Retman
2026-01-13 1:44 ` Andrey Konovalov
2026-01-19 16:33 ` Andrey Ryabinin
2026-01-19 19:43 ` 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=aWpuuiuqZhkGRj2B@google.com \
--to=seanjc@google.com \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=glider@google.com \
--cc=hpa@zytor.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=m.wieczorretman@pm.me \
--cc=maciej.wieczor-retman@intel.com \
--cc=mingo@redhat.com \
--cc=pbonzini@redhat.com \
--cc=ryabinin.a.a@gmail.com \
--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