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-1C2cyypfrTNauqEn_640k36Cvtf-qw4vJEDx0bQuJOO6gg@mail.gmail.com>
Date: Fri, 22 Nov 2024 17:36:53 +0100
From: Brendan Jackman <jackmanb@...gle.com>
To: "Manwaring, Derek" <derekmn@...zon.com>
Cc: David.Kaplan@....com, bp@...en8.de, canellac@...zon.at, 
	dave.hansen@...ux.intel.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 Fri, 22 Nov 2024 at 17:15, Manwaring, Derek <derekmn@...zon.com> wrote:
>
> 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:

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