Message-ID:
 <LV3PR12MB9265E8701CC9A8AF911163B2945A2@LV3PR12MB9265.namprd12.prod.outlook.com>
Date: Wed, 13 Nov 2024 15:42:17 +0000
From: "Kaplan, David" <David.Kaplan@....com>
To: Brendan Jackman <jackmanb@...gle.com>
CC: Thomas Gleixner <tglx@...utronix.de>, Borislav Petkov <bp@...en8.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: Brendan Jackman <jackmanb@...gle.com>
> Sent: Wednesday, November 13, 2024 8:16 AM
> To: Kaplan, David <David.Kaplan@....com>
> Cc: Thomas Gleixner <tglx@...utronix.de>; Borislav Petkov <bp@...en8.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.
>
>
> Hi David,
>
> I'll respond separately to the more interesting thread of discussion w/ Boris & Derek
> but here are some more specific comments:
>
> On Tue, 5 Nov 2024 at 23:00, David Kaplan <david.kaplan@....com> wrote:
> > +User-to-User
> Sorry for the annoying bikeshedding, but this naming could be misconstrued by a
> hasty reader as being concerned with the boundary between Unix users. I wonder if
> we should say "userspace-to-userspace"
> or "process-to-process" or something? The latter would be confusing because it
> doesn't imply any exclusion of KVM guests though.

This was a concern that crossed my mind.  mitigate_process_kernel or mitigate_process_process might be alternatives, while still keeping guest_host and guest_host (I think those names are less likely to be misunderstood).  Curious if other people have opinions here.

>
> At first I thought "don't be so pedantic, users really need to RTFM here regardless,
> at most we just need a 'note this has nothing to do with Unix users'"
>
> But... actually isn't it conceivable that one day we could want "mitigate attacks
> between userspace processes, unless they have the same effective UID" or
> something? So then the naming would be really confusing.
>
> On the other hand, your response to my "but my trust domains are way more
> complex than that" comment at LPC was "Google aren't the target audience for this
> mechanism". Maybe anyone who knows that their unix users are meaningful trust
> domains (probably: someone building a specialised distro (Android?)) is similarly
> outside the target audience here.
>
> > +The user-to-user attack vector involves a malicious userspace program
> > +attempting to influence the behavior of another unsuspecting
> > +userspace program in order to exfiltrate data.  The vulnerability of
> > +a userspace program is based on the program itself and the interfaces it
> provides.
>
> I find this confusing. "Influence the behaviour" sounds like it's talking specifically
> about attacks that drive mis-speculation (Spectre-type), but shouldn't this also
> include stuff more in the vein of L1TF and MDS? I also don't really understand "the
> interface it provides".

You're right, this is talking more about mis-speculation type attacks.  The interface point is that generally the attacker needs some way to invoke the victim and provide it some inputs to cause it to do something which results in leakage.

Even for something like MDS, I think in order to have any control over what data is being leaked, the attacker arguably needs some way to influence victim behavior.  Of course that is not always required if the victim just reads the secret all the time on its own (like your following example).

>
> To be concrete, imagine there's a system where process A just sits in a loop
> reading a secret, and on a system with mitigations=off there's a vuln if a userspace
> attacker can preempt process A, it can leak the secret from some uarch buffer it
> had naturally got into. I expect mitigate_user_user=on to prevent that, but this
> wording doesn't really sound like it does. I guess the vulnerability is "based on the
> program itself" in that it took advantage of the fact it read the data into the buffer, but
> there's no "interface" and no "influenced the behaviour".

In the current patch series, it would be prevented because mitigate_user_user mitigates things like MDS.  I think I can update the documentation to be clearer on this point.

>
> I think the best I can come up with to describe what I expect this flag to mitigate is:
> "a malicious userspace program attempting to leak data directly from the address
> space of the victim program". It's a bit unfortunate that "directly from the address
> space" implies there's some other avenue to leak that data, which might not always
> be the case and kinda gets back to the other thread about the user-to-user/user-to-
> kernel split. Maybe this is a point against that split.

What you are pointing out is that a user->user attack can either be due to influencing the speculative behavior of another process, or through microarchitectural buffer leakage that may occur while that user process is running.  That's a valid point.

>
> > +The guest-to-guest attack vector involves a malicious VM [...]
> (Ditto of course)
>
> > +Summary of attack-vector mitigations
> > +------------------------------------
> > +
> > +When a vulnerability is mitigated due to an attack-vector control,
> > +the default mitigation option for that particular vulnerability is
> > +used.  To use a different mitigation, please use the vulnerability-specific
> command line option.
> > +
> > +The table below summarizes which vulnerabilities are mitigated when
> > +different attack vectors are enabled and assuming the CPU is vulnerable.
> > +
> > +=============== ============== ============ =============
> ============== ============
> > +Vulnerability   User-to-Kernel User-to-User Guest-to-Host Guest-to-Guest
> Cross-Thread
> > +=============== ============== ============ =============
> ============== ============
> > +BHI                   X                           X
> > +GDS                   X              X            X              X            X
> > +L1TF                                              X                       (Note 1)
> > +MDS                   X              X            X              X        (Note 1)
> > +MMIO                  X              X            X              X        (Note 1)
> > +Meltdown              X
> > +Retbleed              X                           X                       (Note 2)
> > +RFDS                  X              X            X              X
> > +Spectre_v1            X
> > +Spectre_v2            X                           X
> > +Spectre_v2_user                      X                           X
> > +SRBDS                 X              X            X              X
> > +SRSO                  X                           X
> > +SSB (Note 3)
> > +TAA                   X              X            X              X        (Note 1)
> > +=============== ============== ============ =============
> > +============== ============
>
> Hmm, I'm also confused by this. This mechanism is supposed to be about mitigating
> attack vectors, but now suddenly we've gone back to talking about vulnerabilities.
> Vulns and vectors are obviously not totally orthogonal but there isn't a 1:1 mapping.

I did simplify things a bit for this table, but I think it’s the mitigations where there isn't a 1:1 mapping.  In reality, a single vulnerability may have different mitigations for different vectors.  BHI is a great example of this where there is one option to clear the BHB on syscall and another to do it on VMEXIT.  And in the patches in this series, these are applied differently depending on the selected attack vectors.  So this table really was meant to indicate which bugs are relevant for each attack vector, and which require some form of mitigation.

>
> To be concrete again: this seems to say if mitigate_guest_host=off there's no L1TF
> mitigation? (I think in fact it's mitigated by PTE inversion).

Correct

>
> And I don't understand why Retbleed doesn't require user_user or guest_guest
> mitigation. I assume I can figure this out by reading about the details of Retbleed
> exploitation or looking in bugs.c. But given this is about making things easier I think
> we should probably assume the reader is as ignorant about that as I am.

Retbleed is a complex example because it is different on AMD vs Intel, but let me take SRSO instead which is a bit simpler to talk about.

SRSO involves the attacker poisoning the BTB so it can influence return instructions executed by the victim (AMD retbleed is similar).  This requires mitigation in the kernel to prevent this.

User->user or guest->guest are possible attack vectors for SRSO too, however they are mitigated by the fact that IBPB is done on context switches (through spectre_v2_user).

(That said, I think this points out something in the upstream code...if spectre_v2_user is disabled but SRSO/retbleed are enabled then I think we don't do the IBPB on context switch.  Not sure if that's a bug)

>
> I dunno exactly what to suggest here, but maybe instead of "we do/don't mitigate
> these vulns" this would be more helpful as "we do/don't enable this specific
> mitigation action". So instead of a row for L1TF, there would be a row for the flush
> that l1tf=flush gives you (basically, like this kinda already has for spectre_v2_user).
> Maybe again I'm just being pedantic and making life difficult here though.

I see your point...and in fact the example I just outlined above is a good argument in your favor.  It really should be attack vectors mapping to mitigations, not necessarily to vulnerabilities.  Many of the vulnerabilities though (other than BHI) don't do a good job of differentiating this though...so it simply becomes "turn on the mitigation if a relevant attack vector is enabled".  That could be improved in the future (and that might be good to see), but as you'll see in the later patches in the series, in most cases the attack vectors are mapping directly to vulnerabilities currently.

One concern I had is that the specific mitigations are very bug-specific, and some bugs have their own documentation files about them.  I don't know if the attack vector documentation is the place to go into the exact mitigation choice being used for each bug, or if that is something that the bug-specific documentation should be updated to discuss.

--David Kaplan

Powered by blists - more mailing lists