Message-ID:
 <LV3PR12MB92658EA6CCF18F90DAAA168394532@LV3PR12MB9265.namprd12.prod.outlook.com>
Date: Wed, 6 Nov 2024 14:49:56 +0000
From: "Kaplan, David" <David.Kaplan@....com>
To: Borislav Petkov <bp@...en8.de>
CC: Thomas Gleixner <tglx@...utronix.de>, Peter Zijlstra
	<peterz@...radead.org>, Josh Poimboeuf <jpoimboe@...nel.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 v2 19/35] Documentation/x86: Document the new attack
 vector controls

[AMD Official Use Only - AMD Internal Distribution Only]

> -----Original Message-----
> From: Borislav Petkov <bp@...en8.de>
> Sent: Wednesday, November 6, 2024 4:39 AM
> To: Kaplan, David <David.Kaplan@....com>
> Cc: Thomas Gleixner <tglx@...utronix.de>; Peter Zijlstra <peterz@...radead.org>;
> Josh Poimboeuf <jpoimboe@...nel.org>; Pawan Gupta
> <pawan.kumar.gupta@...ux.intel.com>; Ingo Molnar <mingo@...hat.com>; Dave
> Hansen <dave.hansen@...ux.intel.com>; x86@...nel.org; H . Peter Anvin
> <hpa@...or.com>; linux-kernel@...r.kernel.org
> Subject: Re: [PATCH v2 19/35] Documentation/x86: Document the new attack
> vector controls
>
> Caution: This message originated from an External Source. Use proper caution
> when opening attachments, clicking links, or responding.
>
>
> On Tue, Nov 05, 2024 at 03:54:39PM -0600, David Kaplan wrote:
> > Document the 5 new attack vector command line options, how they
> > interact with existing vulnerability controls, and recommendations on
> > when they can be disabled.
> >
> > Note that while mitigating against untrusted userspace requires both
> > mitigate_user_kernel and mitigate_user_user, these are kept separate.
> > The kernel can control what code executes inside of it and that may
> > affect the risk associated with vulnerabilities especially if new
> > kernel mitigations are implemented.  The same isn't typically true of userspace.
> >
> > In other words, the risk associated with user_user or guest_guest
> > attacks is unlikely to change over time.  While the risk associated
> > with user_kernel or guest_host attacks may change.  Therefore, these
> > controls are separated.
>
> Right, and this is one of the thing David and I have been bikeshedding on recently
> so perhaps it'll be cool to hear some more opinions.
>
> My issue with this is, because I always try to make the user interface as simple as
> possible, I'm wondering if we should merge
>
>         user_kernel and user_user
>
> and
>
>         guest_host and guest_guest
>
> each into a single option.
>
> Because user_user and guest_guest each pull in user_kernel and guest_host
> respectively, due to how the protections work.

To be clear, in the current patch series the user_user and guest_guest protections only turn on the mitigations required for those specific vectors, as noted in this patch.  They do not automatically enable the same protections as user_kernel or guest_host.

However due to how Linux works (at least today), if you have one trusted userspace process and another untrusted one, you really should enable both user_kernel and user_user controls to have complete protection.

>
> As David says, what user_kernel and guest_host enable for mitigating the
> respective vector, will change when we add more involved kernel protection
> schemes so their overhead should potentially go down.
>
> While the user_user and guest_guest things should not change that much.
>
> So, provided we always DTRT, what gets enabled behind those vectors will change
> but still be sufficient depending on the kernel and its protections.

One key point is noted in the commit message: the kernel can control how it behaves, what it executes, its address space, etc.  But it cannot control how userspace works.  Therefore, the risk associated with attacks that target the kernel might change over time, while the same can't really be said for userspace.  Risk is not always a black-and-white decision, and there could be a point where kernel defense-in-depth measures may be deemed sufficient by some, but not all, admins to eliminate the need for more expensive mitigations.

>
> One of the arguments against those getting merged is, those are not going to be
> *vector* controls anymore but something else:
>
> mitigate_user - that will mitigate everything that has to do with executing user
> processes
>
> mitigate_guest - same but when running guests
>
> The third one will be the SMT off: mitigate_cross_thread.
>
> Oh and whatever we do now, we can always change it later but that means an
> additional change.
>
> Anyway, this should be the gist of our bikeshedding.
>
> Thoughts? Ideas?
>

Right, so the way I think of this is that there is a cognitive process that administrators must go through:

1. Determine how the system will be used (e.g., am I running untrusted VMs?)
2. Determine the attack vectors relevant for that configuration (e.g., I need guest->host and guest->guest protection)
3. Determine which mitigations are required to enable the desired level of security (e.g., enable vulnerability X mitigation but not Y)

Today, the administrator must do all 3 of these, which requires in-depth knowledge of all these bugs, and isn't forward compatible.  The proposed patch series has the kernel take care of step 3, but still requires the administrator to do steps 1 and 2.  The provided documentation helps with step 2, but ultimately the admin must decide which attack vectors they want to turn on/off.  But the attack vectors are also forward compatible in case new bugs show up in the future.

What you've proposed is up-leveling things a bit further and trying to have the kernel do both steps 2 and 3 in the above flow.  That is, the admin decides for example they have untrusted userspace, and the kernel then determines they need user->kernel and user->user protection, and then which bug fixes to enable.

I'm not necessarily opposed to that, and welcome feedback on this.  But as you said, that is not an attack-vector control anymore, it is more of an end-use control.  It is possible to do both...we could also create end-use options like the ones you mention, and just map those in a pretty trivial way to the attack vector controls.

I'm nervous about only doing the end-use controls and not the attack vector controls because of the reasons outlined above.  For example, I'm thinking about some proposed technologies such as KVM Address Space Isolation which may go a long way to reducing the risk of guest->host attacks but may not be fully secure yet (where the kernel would feel comfortable disabling a bunch of guest->host protections automatically).  With attack vector-level controls, it would be easier to turn off guest->host protection if the admin is comfortable with this technology, but still leaving the (almost certainly needed) guest->guest protections in place.

--David Kaplan

Powered by blists - more mailing lists