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

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

Message-ID: <20250312191717.GGZ9Hdvbi_kRZYaaVE@fat_crate.local>
Date: Wed, 12 Mar 2025 20:17:17 +0100
From: Borislav Petkov <bp@...en8.de>
To: Brendan Jackman <jackmanb@...gle.com>
Cc: Patrick Bellasi <derkling@...gle.com>,
	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 Tue, Mar 11, 2025 at 01:36:54PM +0000, Brendan Jackman wrote:
> This seems like a good idea to me, assuming we want ASI in the code
> eventually it seems worthwhile to make visible the places where we
> know we'll want to update the code when we get it in.
> 
> In RFCv2 this would be static_asi_enabled() [1] - I think in the
> current implementation it would be fine to use it directly, but in
> general we do need to be aware of initializion order.

Right, I'd suggest you whack that thing and use cpu_feature_enabled()
directly. No need for the indirection.

And I see you're setting X86_FEATURE_ASI in asi_check_boottime_disable() - I'm
presuming that's early enough so that cpu_select_mitigations() in bugs.c can
see it so that srso_select_mitigation() can act accordingly...

> Of course I'm biased here, from my perspective having such mentions of
> ASI in the code is unambiguously useful. But if others perceived it as
> useless noise I would understand!

Yeah, well, it'll be a single feature check in srso_select_mitigation() with
a big-fat comment in it explaining why so I think that should be ok...

Thx.

-- 
Regards/Gruss,
    Boris.

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