Re: [PATCH v2 19/35] Documentation/x86: Document the new attack vector controls

["Manwaring, Derek" <derekmn@amazon.com>]

On 2024-11-14 at 9:32+0000, Brendan Jackman wrote:
> On Wed, 13 Nov 2024 at 17:19, Brendan Jackman <jackmanb@google.com> wrote:
> >
> > On Wed, 13 Nov 2024 at 17:00, Kaplan, David <David.Kaplan@amd.com> wrote:
> > > 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.
> >
> > This is already the case for the mitigations that "go the other way":
> > IBPB protects the incoming domain from the outgoing one, but L1D flush
> > protects the outgoing from the incoming. So when you exit to the
> > unrestricted address space it never makes sense to flush L1D (everyone
> > trusts the kernel) but e.g. guest->guest still needs one.
>
> I'm straying quite far from the actual topic now but to avoid
> confusion for anyone reading later:
>
> A discussion off-list led me to realise that the specifics of this
> comment are nonsensical, I had L1TF in mind but I don't think you can
> exploit L1TF in a direct guest->guest attack (I'm probably still
> missing some nuance there). We wouldn't need to flush L1D there unless
> there's a new vuln.

With Foreshadow-VMM/CVE-2018-3646 I thought you can do guest->guest?
Since guest completely controls the physical address which ends up
probing L1D (as if it were a host physical address).

And agree with the flushes between different restricted address spaces
(e.g. context switch between guests, right?).

Derek