linux-kernel - Re: [PATCH final?] x86/bugs: KVM: Add support for SRSO_MSR

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: <20250311120340.GFZ9AmnAcZg-4pXOBv@fat_crate.local>
Date: Tue, 11 Mar 2025 13:03:40 +0100
From: Borislav Petkov <bp@...en8.de>
To: Patrick Bellasi <derkling@...gle.com>,
	Brendan Jackman <jackmanb@...gle.com>
Cc: Sean Christopherson <seanjc@...gle.com>,
	Yosry Ahmed <yosry.ahmed@...ux.dev>,
	Paolo Bonzini <pbonzini@...hat.com>,
	Josh Poimboeuf <jpoimboe@...hat.com>,
	Pawan Gupta <pawan.kumar.gupta@...ux.intel.com>, x86@...nel.org,
	kvm@...r.kernel.org, linux-kernel@...r.kernel.org,
	Patrick Bellasi <derkling@...bug.net>,
	David Kaplan <David.Kaplan@....com>
Subject: Re: [PATCH final?] x86/bugs: KVM: Add support for SRSO_MSR_FIX

On Mon, Mar 03, 2025 at 03:05:56PM +0000, Patrick Bellasi wrote:
> That's why we are also going to detect this cases and set
> SRSO_MITIGATION_BP_SPEC_REDUCE_NA, so that we get a:
> 
>   "Vulnerable: Reduced Speculation, not available"
> 
> from vulnerabilities/spec_rstack_overflow, which should be the only place users
> look for to assess the effective mitigation posture, ins't it?

If they even look. The strategy so far has been that the kernel should simply
DTRT (it being the default) if the user doesn't know anything about
mitigations etc.

So I have another idea: how about we upstream enough ASI bits - i.e., the
function which checks whether ASI is enabled - and use that in the mitigation
selection?

IOW:
	case SRSO_CMD_BP_SPEC_REDUCE:
		if ((boot_cpu_has(X86_FEATURE_SRSO_BP_SPEC_REDUCE)) {
			select it
		} else {
			if (ASI enabled)
				do not fall back to IBPB;
			else
				fallback to IBPB;
		}

"ASI enabled" will return false upstream - at least initially only, until ASI
is out-of-tree - and then it'll fall back.

On your kernels, it'll return true and there it won't fall back.

We just need to sync with Brendan what "ASI enabled" would be and then it
should work and your backports would be easy in that respect.

Until ASI is not upstream, that is.

Hmmmm?

Thx.

-- 
Regards/Gruss,
    Boris.

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