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

[Brendan Jackman]

On Wed, 13 Nov 2024 at 17:19, Brendan Jackman <jackmanb@xxxxxxxxxx> wrote:
>
> On Wed, 13 Nov 2024 at 17:00, Kaplan, David <David.Kaplan@xxxxxxx> 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.

I made a similar mistake in [1] where I had forgotten that you can't
really do direct user->user L1TF attacks either. I was thinking of
"Foreshadow-OS" [2] which is not really user->user.

[1] https://lore.kernel.org/linux-kernel/CA+i-1C38hxnCGC=Zr=hNFzJBceYoOHfixhpL3xiXEg3hcdgWUg@xxxxxxxxxxxxxx/

[2] https://foreshadowattack.eu/foreshadow-NG.pdf

Anyway, the underlying point I'm making is still valid I think. In
RFCv1 ASI has flushes on both transitions. In the RFCv2 as well as the
two transitions into & out of the restricted address space there are
transitions between different restricted address spaces and we can do
flushes there too.