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

[Brendan Jackman]

On Fri, 22 Nov 2024 at 17:15, Manwaring, Derek <derekmn@xxxxxxxxxx> wrote:
>
> On 2024-11-14 at 9:32+0000, Brendan Jackman wrote:
> > On Wed, 13 Nov 2024 at 17:19, Brendan Jackman <jackmanb@xxxxxxxxxx> wrote:

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

You are almost certainly right!

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

Yeah basically, although with the RFCv2 I'm gonna be proposing this
"tainting" model where instead of having to flush, in context switch
we just set a flag to say "another MM* might have left data in a
sidechannel". Then if we have that flag set on an asi_enter we flush
at that point.

*We could break that down further too, e.g. whether the thing that
left data behind was a VM guest or a userspace task, if that ever
influences what caches/buffers we wanna burn.