Re: [PATCH v3 20/35] x86/bugs: Define attack vectors

[Pawan Gupta <pawan.kumar.gupta@linux.intel.com>]

On Wed, Feb 26, 2025 at 06:57:05PM +0000, Kaplan, David wrote:
> [AMD Official Use Only - AMD Internal Distribution Only]
> 
> > -----Original Message-----
> > From: Josh Poimboeuf <jpoimboe@kernel.org>
> > Sent: Thursday, February 20, 2025 4:05 PM
> > To: Borislav Petkov <bp@alien8.de>
> > Cc: Kaplan, David <David.Kaplan@amd.com>; Thomas Gleixner
> > <tglx@linutronix.de>; Peter Zijlstra <peterz@infradead.org>; Pawan Gupta
> > <pawan.kumar.gupta@linux.intel.com>; Ingo Molnar <mingo@redhat.com>; Dave
> > Hansen <dave.hansen@linux.intel.com>; x86@kernel.org; H . Peter Anvin
> > <hpa@zytor.com>; linux-kernel@vger.kernel.org
> > Subject: Re: [PATCH v3 20/35] x86/bugs: Define attack vectors
> >
> > Caution: This message originated from an External Source. Use proper caution
> > when opening attachments, clicking links, or responding.
> >
> >
> > On Tue, Feb 18, 2025 at 09:52:03AM +0100, Borislav Petkov wrote:
> > > On Mon, Feb 17, 2025 at 11:05:01PM -0800, Josh Poimboeuf wrote:
> > > > IMO, make them generic from the start, then there's less churn and
> > > > it's easy to port the other arches.
> > > >
> > > > If we went with putting everything in "mitigations=", making them
> > > > generic would be the obvious way to go anyway.
> > >
> > > Just to make sure we're all on the same page: we obviously cannot
> > > enable and test and support a mitigaion on another arch like, say, arm64, or so.
> > >
> > > This needs to come from the respective arch maintainers themselves and
> > > they'll have to say, yes, pls, enable it and we'll support it. We
> > > should not go "oh, this would be a good idea to do on all arches"
> > > without hearing from them first, even if it is a good idea on its face.
> > >
> > > That's why those are x86-only as they should be initially.
> >
> > I wasn't suggesting that this patch set should *enable* it on all arches.  Of course
> > that would need to be reviewed by the respective arch maintainers.
> >
> > But looking ahead, this *will* be needed for the other arches, for the same reason
> > we have a generic mitigations=off.  It's a user problem, not an arch-specific one.
> > Users need a simple interface that works everywhere.  That's why I suggested
> > integrating it into "mitigations=".
> >
> 
> Talked with Boris on the side, he is ok with supporting this in mitigations=, with a warning message if you try to use these controls on yet-unsupported architectures.
> 
> Going back to the command line definition, I think that to help make the selection clearer we could consider the following format:
> 
> mitigations=[on/off],[attack vectors]
> 
> For example:
> 
> "mitigations=on,no_user_kernel" to enable all attack vectors except user->kernel
> "mitigations=off,guest_host" to disable all vectors except guest->host

This is a bit ambiguous, mitigations=off,guest_host could be interpreted as
disabling guest->host and enabling all others. Using attack vectors with
both =on and =off seems unnecessary.

Also, we currently don't have mitigations=on option, it's equivalent is =auto.

static int __init mitigations_parse_cmdline(char *arg)
{
        if (!strcmp(arg, "off"))
                cpu_mitigations = CPU_MITIGATIONS_OFF;
        else if (!strcmp(arg, "auto"))
                cpu_mitigations = CPU_MITIGATIONS_AUTO;
        else if (!strcmp(arg, "auto,nosmt"))
                cpu_mitigations = CPU_MITIGATIONS_AUTO_NOSMT;
        else
                pr_crit("Unsupported mitigations=%s, system may still be vulnerable\n",
                        arg);

        return 0;
}

Extending =auto to take attack vectors is going to be tricky, because it
already takes ",nosmt" which would conflict with ",no_cross_thread".

How about we keep =off, and =auto as is, and add:

  mitigations=selective,no_user_kernel,no_cross_thread,...

Requiring the user to explicitly select attack vectors to disable (rather
than to enable). This would be more verbose, but it would be clear that the
user is explicitly selecting attack vectors to disable. Also, if a new
attack vector gets added in future, it would be mitigated by default,
without requiring the world to change their cmdline.