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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CA+i-1C3R=56CAMiDwuzrtxmQN+CN14hUeMfbv4k4WqyQfexZ1g@mail.gmail.com>
Date: Thu, 14 Nov 2024 10:32:34 +0100
From: Brendan Jackman <jackmanb@...gle.com>
To: "Kaplan, David" <David.Kaplan@....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

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

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@mail.gmail.com/

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