[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID:
<LV3PR12MB92653337C2377D640BF81F84945A2@LV3PR12MB9265.namprd12.prod.outlook.com>
Date: Wed, 13 Nov 2024 16:00:02 +0000
From: "Kaplan, David" <David.Kaplan@....com>
To: Brendan Jackman <jackmanb@...gle.com>
CC: "Manwaring, Derek" <derekmn@...zon.com>, "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 9:32 AM
> To: Kaplan, David <David.Kaplan@....com>
> Cc: Manwaring, Derek <derekmn@...zon.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 16:05, Kaplan, David <David.Kaplan@....com> wrote:
> >
> > 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.
>
> Well, in the RFC I'm currently (painfully slowly, sorry again) working on, that IBPB is
> provided by ASI. Each process has an ASI domain, ASI ensures there's an IBPB
> before we transition into any other domain that doesn't trust it (VMs trust their VMM,
> but all other transitions out of the userpace domain will flush).
>
> In practice, this is just provided by the fact that context switching currently incurs an
> asi_exit(), but that's an implementation detail, if we transitioned directly from one
> process' domain to another that would also create a flush.
>
> (But yes, maybe that being "part of ASI" is just my very ASI-centric perspective).
Ah yes, this makes sense. As you said though, this is due to the fact that context switch incurs an asi_exit. As a thought exercise, I wonder what would happen if there was a mitigation that was required when switching to another guest, but not to the broader host address space. I think that would mean there would still be a need for extra flushes when switching guest->guest that may not be covered by asi_exit. (That's theoretical though but could be a reason not to tie these together forever)
And yes, please do keep up the ASI work, I'm very much looking forward to it, it should be a big improvement.
--David Kaplan
Powered by blists - more mailing lists