linux-kernel - Re: [PATCH v4 1/6] x86/cpu: Use a new feature flag for 5 level paging

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: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <aC-iHUcRmgYoE59E@google.com>
Date: Thu, 22 May 2025 15:15:57 -0700
From: Sean Christopherson <seanjc@...gle.com>
To: Thomas Gleixner <tglx@...utronix.de>
Cc: Peter Zijlstra <peterz@...radead.org>, Borislav Petkov <bp@...en8.de>, Ingo Molnar <mingo@...nel.org>, 
	"Ahmed S. Darwish" <darwi@...utronix.de>, Ard Biesheuvel <ardb+git@...gle.com>, linux-kernel@...r.kernel.org, 
	x86@...nel.org, Ard Biesheuvel <ardb@...nel.org>, 
	Linus Torvalds <torvalds@...ux-foundation.org>, Brian Gerst <brgerst@...il.com>, 
	"Kirill A. Shutemov" <kirill@...temov.name>
Subject: Re: [PATCH v4 1/6] x86/cpu: Use a new feature flag for 5 level paging

On Thu, May 22, 2025, Thomas Gleixner wrote:
> On Thu, May 22 2025 at 08:08, Sean Christopherson wrote:
> > On Thu, May 22, 2025, Peter Zijlstra wrote:
> >> On Wed, May 21, 2025 at 05:23:37PM +0200, Thomas Gleixner wrote:
> >> 
> >> >    4) Drivers having access to CPUID is just wrong. We've had issues
> >> >       with that in the past because drivers evaluated CPUID themself and
> >> >       missed that the core code had stuff disabled.
> >> 
> >> I had this patch that read the module instructions and failed loading if
> >> they used 'fancy' instructions. Do you want me to revive that?
> 
> Once we have the new infrastructure in place....
> 
> > Unless you want to grant exceptions, that's not going to fly for KVM.  KVM makes
> > heavy use of CPUID, the consumption/output of which is firmly entrenched in KVM's
> > ABI.
> 
> If there is a full in memory copy of all CPUID leafs, then what needs KVM beyond
> reading it from there?

Ah, I missed that context.  If it's a truly full (e.g. includes the XSTATE sizes
sub-leafs and all that jazz) and unmodified copy, then it'll work.

If it's a modified/filtered copy, it might work?  I'd have to think/dig more.
I'm pretty sure the only CPUID-based feature that KVM supports based solely on
hardware capabilities is LA57, and it sounds like that will have special handling
anyways.

My bigger concern is cases where the kernel _adds_ features.  KVM's default
handling of features is to advertise support if and only both the host kernel
and hardware support a feature.  I.e. KVM does a bitwise-AND of CPUID and
boot_cpu_data.x86_capability.  KVM does opt-in for a handful of features, but
they are the exception, not the rule.  I don't see an obvious way to maintain
that behavior without KVM doing CPUID itself.