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

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20250218070501.7mwcxqgsuxl3meef@jpoimboe>
Date: Mon, 17 Feb 2025 23:05:01 -0800
From: Josh Poimboeuf <jpoimboe@...nel.org>
To: "Kaplan, David" <David.Kaplan@....com>
Cc: Thomas Gleixner <tglx@...utronix.de>, Borislav Petkov <bp@...en8.de>,
	Peter Zijlstra <peterz@...radead.org>,
	Pawan Gupta <pawan.kumar.gupta@...ux.intel.com>,
	Ingo Molnar <mingo@...hat.com>,
	Dave Hansen <dave.hansen@...ux.intel.com>,
	"x86@...nel.org" <x86@...nel.org>,
	"H . Peter Anvin" <hpa@...or.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v3 20/35] x86/bugs: Define attack vectors

On Tue, Feb 18, 2025 at 02:24:01AM +0000, Kaplan, David wrote:
> > > I do agree that they can be arch-generic (hence why I originally put
> > > them in kernel/cpu.c) but I also don't know when (if ever) anyone from
> > > other archs will want to pick them up.
> >
> > Well, for example, we already have the generic
> > prctl(PR_SET_SPECULATION_CTRL) which is used by arm64.  If somebody boots
> > with mitigate_user_user=off on arm64, they could reasonably expect those context
> > switch mitigations to be disabled.
> 
> I'm not sure which this is an argument for actually :)
> 
> That is, I do agree that mitigate_user_user makes sense in an
> arch-agnostic way and a user might expect context switch mitigations
> disabled.  However this patch series doesn't implement these attack
> vector controls for anything other than x86.  So I guess I'm not sure
> if your argument is that because they aren't yet implemented for
> arm64, then keeping them x86-specific is better...or if we should make
> them generic to more easily support extension to other architectures.

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.

> > And then the mitigations= cmdline could simply be processed in order, without side
> > effects, to give the user full flexibility.  To opt-in to specific vectors:
> >
> >   mitigations=off mitigations=user_kernel,host_guest
> 
> I don't like this idea as much as the next, because as noted above, I
> think with most other command lines, a later version replaces an
> earlier one, it doesn't append to it.
>
> That is, something like "spectre_v2=retpoline spectre_v2=ibrs" ends up just meaning ibrs.

Yeah, that makes sense to me.

> > which is equivalent to:
> >
> >   mitigations=off,user_kernel,host_guest
> >
> > Or, if one prefers to opt-out:
> >
> >   mitigations=auto,no_user_user,no_guest_guest
> >
> > where the "auto" is optional for default configs.
> 
> This seems more appealing to me because I think it's clearer what 'on'
> vs 'off' is.  It retains the more compact form of the command line
> while also allowing for opt-in or opt-out style.  And if you specify
> multiple "mitigations=" command lines, the new one replaces the old
> one, like with most other options.
> 
> So I rather like this, and would be interested in what others think too.

+1

> > The priority could be simplified:
> >
> >   1) individual mitigations (=auto means use system-wide default)
> >
> >   2) system-wide defaults (tweaked by mitigations=/mitigate_*=)
> >
> > So the system-wide defaults would be defined by mitigations=whatever, and those
> > can be overriden by the individual mitigations.  That seems a lot more simple and
> > logical.
> >
> > And since you're already introducing "=auto" for the individual mitigations, I think that
> > would be easy enough to implement.
> >
> 
> Yes it wouldn't be very hard, and it does make logical sense.  But I
> think the big caveat is the change to the existing mitigations=off and
> that it would no longer override individual mitigations.  Changing
> that would seem to be a risk, and is that risk worth taking?

Honestly I don't see it as much of a risk.  AFAICT that behavior isn't
documented anywhere.  I'd view it as more of an implementation detail.

And we have to weigh that risk against better maintainability and ease
of use going forward.  These bugs are going to continue to be found
across all the major arches for a long time, let's get the interfaces
right.

-- 
Josh