public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
From: Brendan Jackman <jackmanb@google.com>
To: Borislav Petkov <bp@alien8.de>
Cc: Patrick Bellasi <derkling@google.com>,
	Sean Christopherson <seanjc@google.com>,
	Yosry Ahmed <yosry.ahmed@linux.dev>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Josh Poimboeuf <jpoimboe@redhat.com>,
	Pawan Gupta <pawan.kumar.gupta@linux.intel.com>,
	x86@kernel.org, kvm@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	Patrick Bellasi <derkling@matbug.net>,
	David Kaplan <David.Kaplan@amd.com>
Subject: Re: [PATCH final?] x86/bugs: KVM: Add support for SRSO_MSR_FIX
Date: Tue, 11 Mar 2025 13:36:54 +0000	[thread overview]
Message-ID: <Z9A8djMzajTAOawM@google.com> (raw)
In-Reply-To: <20250311120340.GFZ9AmnAcZg-4pXOBv@fat_crate.local>

On Tue, Mar 11, 2025 at 01:03:40PM +0100, Borislav Petkov wrote:
> 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?

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.

[0] (first half of)
https://lore.kernel.org/all/DS0PR12MB9273553AE4096FCCBBB4000E94D62@DS0PR12MB9273.namprd12.prod.outlook.com/

[1]
https://lore.kernel.org/linux-mm/20250110-asi-rfc-v2-v2-4-8419288bc805@google.com/

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!

  reply	other threads:[~2025-03-11 13:37 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-03-03 15:05 [PATCH final?] x86/bugs: KVM: Add support for SRSO_MSR_FIX Patrick Bellasi
2025-03-11 12:03 ` Borislav Petkov
2025-03-11 13:36   ` Brendan Jackman [this message]
2025-03-12 19:17     ` Borislav Petkov
  -- strict thread matches above, loose matches on Subject: below --
2025-02-26 18:45 Patrick Bellasi
2025-02-26 19:51 ` Yosry Ahmed
2025-03-03 13:59   ` Borislav Petkov
2025-03-03 14:10 ` Borislav Petkov
2025-02-13 14:28 Re: Re: [PATCH] " Borislav Petkov
2025-02-13 17:50 ` Patrick Bellasi
2025-02-14 20:10   ` Borislav Petkov
2025-02-15 12:53     ` Borislav Petkov
2025-02-17  5:59       ` Yosry Ahmed
2025-02-17 16:07         ` Borislav Petkov
2025-02-17 19:56           ` Yosry Ahmed
2025-02-17 20:20             ` Borislav Petkov
2025-02-17 20:32               ` Yosry Ahmed
2025-02-18 11:13                 ` [PATCH final?] " Borislav Petkov
2025-02-18 14:42                   ` Patrick Bellasi
2025-02-18 15:34                     ` Borislav Petkov

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=Z9A8djMzajTAOawM@google.com \
    --to=jackmanb@google.com \
    --cc=David.Kaplan@amd.com \
    --cc=bp@alien8.de \
    --cc=derkling@google.com \
    --cc=derkling@matbug.net \
    --cc=jpoimboe@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pawan.kumar.gupta@linux.intel.com \
    --cc=pbonzini@redhat.com \
    --cc=seanjc@google.com \
    --cc=x86@kernel.org \
    --cc=yosry.ahmed@linux.dev \
    /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