Message-ID:
 <LV3PR12MB926503BA63C616562E508D8C945A2@LV3PR12MB9265.namprd12.prod.outlook.com>
Date: Wed, 13 Nov 2024 15:05:00 +0000
From: "Kaplan, David" <David.Kaplan@....com>
To: Brendan Jackman <jackmanb@...gle.com>, "Manwaring, Derek"
	<derekmn@...zon.com>
CC: "bp@...en8.de" <bp@...en8.de>, "dave.hansen@...ux.intel.com"
	<dave.hansen@...ux.intel.com>, "hpa@...or.com" <hpa@...or.com>,
	"jpoimboe@...nel.org" <jpoimboe@...nel.org>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>, "mingo@...hat.com" <mingo@...hat.com>,
	"pawan.kumar.gupta@...ux.intel.com" <pawan.kumar.gupta@...ux.intel.com>,
	"peterz@...radead.org" <peterz@...radead.org>, "tglx@...utronix.de"
	<tglx@...utronix.de>, "x86@...nel.org" <x86@...nel.org>, "mlipp@...zon.at"
	<mlipp@...zon.at>, "canellac@...zon.at" <canellac@...zon.at>
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: Brendan Jackman <jackmanb@...gle.com>
> Sent: Wednesday, November 13, 2024 8:16 AM
> To: Manwaring, Derek <derekmn@...zon.com>
> Cc: Kaplan, David <David.Kaplan@....com>; 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
>
> Caution: This message originated from an External Source. Use proper caution
> when opening attachments, clicking links, or responding.
>
>
> On Wed, 13 Nov 2024 at 04:58, Manwaring, Derek <derekmn@...zon.com>
> wrote:
> > > 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
> > > guest->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?
>
> Yeah, personally my vision for ASI is more than it _is_ the guest_host/guest_user
> mitigation and for the RFCv2 (long-awaited,
> sorry) it will be the user_user/user_kernel mitigation too.

I don't see how ASI can ever be a user_user mitigation.  User_user attacks are things like influencing the indirect predictions used by another process, causing that process to leak data from its address space.  User_user mitigations are things like doing an IBPB when switching tasks.

Also guest_user mitigation is not a thing, did you mean guest_guest?  If so, the same argument applies.


> If we decide we wanna
> keep existing mitigations in place once ASI is at full strength then ASI mostly failed.
> (Or perhaps to be more charitable to ASI's strategic prospects, I'd feel OK if people
> said "I want ASI, but I'll keep the old mitigations for defence-in-depth" as long as we
> usually don't need to develop _new_ mitigations for those people).
>
> So rather than saying "I have ASI, I can turn guest->host mitigation off", you say "I
> have ASI, guest->host mitigation is very cheap, let's have some champagne". In the
> utopian champagne future only very advanced users will have any interest in more
> fine-grained questions than "do I trust my KVM guests".
>
> I guess another way to look at that is: the distinction in these pairs of attack vectors
> is quite subtle. The fact that we are even considering exposing users to that
> awkward subtle distinction highlights a weakness of Linux's current mitigation
> posture and I think ASI reduces that weakness. The weakness is: the cost of
> mitigating attack vectors doesn't line up very well with the degree of threat they
> present. We think it's kinda tricky in practice to steal interesting data just by going
> into the kernel, but it's probably possible, so we have to pay mitigation costs every
> time we go into the kernel. Relatively low risk, relatively high cost. So we're having
> to say to the user "do you wanna pay that high cost for this low risk? We can't tell
> you how low it is though, we can only start rambling incomprehensibly about
> something called the 'fizz map'".

I disagree somewhat.  The distinction between say guest->host or guest->guest attacks is what is being targeted.  This is especially easy to see in the case of the branch-based side channels.  It's about whether you're influencing the predictions in the host or another guest.  The subtle part is that today, guest secrets exist both in the victim guest's address space as well as the host's address space.  Meaning that if you want to prevent those secrets from leaking, you need to protect both places.  ASI can potentially solve one of those problems, but not the other.

I'm also nervous to assert that because certain attack vectors are cheap to mitigate today doesn't mean they will always be.

--David Kaplan

>
> At first I wanted to say the same thing about your work to remove stuff from the
> direct map. Basically that's about architecting ourselves towards a world where the
> "guest->kernel" attack vector just isn't meaningful, right?

Powered by blists - more mailing lists