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: <3676f073-028e-4855-aa87-107e0607be24@amazon.com>
Date: Fri, 22 Nov 2024 09:15:11 -0700
From: "Manwaring, Derek" <derekmn@...zon.com>
To: <jackmanb@...gle.com>
CC: <David.Kaplan@....com>, <bp@...en8.de>, <canellac@...zon.at>,
	<dave.hansen@...ux.intel.com>, <derekmn@...zon.com>, <hpa@...or.com>,
	<jpoimboe@...nel.org>, <linux-kernel@...r.kernel.org>, <mingo@...hat.com>,
	<mlipp@...zon.at>, <pawan.kumar.gupta@...ux.intel.com>,
	<peterz@...radead.org>, <tglx@...utronix.de>, <x86@...nel.org>
Subject: Re: [PATCH v2 19/35] Documentation/x86: Document the new attack
 vector controls

On 2024-11-14 at 9:32+0000, Brendan Jackman wrote:
> 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.

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