Message-ID: <f3ddabdc-39fa-45fa-97fd-d8508c2229c9@amazon.com>
Date: Tue, 12 Nov 2024 20:58:29 -0700
From: "Manwaring, Derek" <derekmn@...zon.com>
To: <david.kaplan@....com>, <jackmanb@...gle.com>
CC: <bp@...en8.de>, <dave.hansen@...ux.intel.com>, <hpa@...or.com>,
	<jpoimboe@...nel.org>, <linux-kernel@...r.kernel.org>, <mingo@...hat.com>,
	<pawan.kumar.gupta@...ux.intel.com>, <peterz@...radead.org>,
	<tglx@...utronix.de>, <x86@...nel.org>, <mlipp@...zon.at>,
	<canellac@...zon.at>
Subject: RE: [PATCH v2 19/35] Documentation/x86: Document the new attack
 vector controls

+Brendan

On 2024-11-06 at 14:49+0000, David Kaplan wrote:
> On 2024-11-06 at 10:39+0000, Borislav Petkov wrote:
> > 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.
>
> 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 think the further simplification makes sense (merge to mitigate_user
or mitigate_guest). I would say definitely don't do both (ending up with
end-use, vector controls, *and* existing parameters). Both just seems
like more confusion rather than simplification overall.

For me the major dissonance in all of this remains cross_thread. Based
on either approach (end-use or vector), SMT should be disabled unless
the admin explicitly asks to keep it (presumably because they are
running with core scheduling correctly configured).

What if mitigate_user_user defaulted to 'defaults' instead of 'on'? I'm
thinking 'defaults' meaning "do the things the kernel normally did
before thinking in these attack-vector terms." That way we could
differentiate between "admin didn't specify anything" and "admin said
they cared about mitigating this vector (or case)." That should make it
reasonable to disable SMT when mitigate_user_user=on is supplied, yeah?

> 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.

Personally I wouldn't put too much weight on the possibility of
disabling kernel mitigations with these future approaches. For what
we're looking at with direct map removal, I would still keep kernel
mitigations on unless we really needed one off. Brendan, I know you were
looking at this differently though for ASI. What are your thoughts?

Derek

Powered by blists - more mailing lists