linux-kernel - Re: [PATCH 1/2] KVM: SEV: IBPB-on-Entry guest support

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: <20260130154534.GCaXzSHgkEFnk5mX14@fat_crate.local>
Date: Fri, 30 Jan 2026 16:45:34 +0100
From: Borislav Petkov <bp@...en8.de>
To: Tom Lendacky <thomas.lendacky@....com>
Cc: Kim Phillips <kim.phillips@....com>, linux-kernel@...r.kernel.org,
	kvm@...r.kernel.org, linux-coco@...ts.linux.dev, x86@...nel.org,
	Sean Christopherson <seanjc@...gle.com>,
	Paolo Bonzini <pbonzini@...hat.com>,
	K Prateek Nayak <kprateek.nayak@....com>,
	Nikunj A Dadhania <nikunj@....com>,
	Michael Roth <michael.roth@....com>,
	Naveen Rao <naveen.rao@....com>,
	David Kaplan <david.kaplan@....com>, stable@...nel.org
Subject: Re: [PATCH 1/2] KVM: SEV: IBPB-on-Entry guest support

On Fri, Jan 30, 2026 at 08:56:07AM -0600, Tom Lendacky wrote:
> It can be added. Any of the features added to SNP_FEATURES_PRESENT that
> aren't set in the SNP_FEATURES_IMPL_REQ bitmap are really a no-op. The
> SNP_FEATURES_PRESENT bitmap is meant to contain whatever bits are set in
> SNP_FEATURES_IMPL_REQ when an implementation has been implemented for the
> guest.
> 
> But, yeah, we could add all the bits that aren't set in
> SNP_FEATURES_IMPL_REQ to SNP_FEATURES_PRESENT if it makes it clearer.

Right, that's the question. SNP_FEATURES_PRESENT is used in the masking
operation to get the unsupported features.

But when we say a SNP feature is present, then, even if it doesn't need guest
implementation, that feature is still present nonetheless.

So our nomenclature is kinda imprecise here.

I'd say, we can always rename SNP_FEATURES_PRESENT to denote what it is there
for, i.e., the narrower functionality of the masking.

Or, if we want to gather there *all* features that are present, then we can
start adding them...

> If we do that, it should probably be a separate patch (?) that also
> rewords the comment above SNP_FEATURES_PRESENT

... yes, as a separate patch.

Question is, what do we really wanna do here?

Does it make sense and is it useful to have SNP_FEATURES_PRESENT contain *all*
guest SNP features...

Thx.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette