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-1C2JXYUBnE7fn6df0=KR4KeD0VgwO5Cc2xRhO8rBqC_p+Q@mail.gmail.com>
Date: Wed, 13 Nov 2024 16:31:46 +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 16:05, Kaplan, David <David.Kaplan@....com> wrote:
>
> I don't see how ASI can ever be a user_user mitigation.  User_user attacks are things like influencing the indirect predictions used by another process, causing that process to leak data from its address space.  User_user mitigations are things like doing an IBPB when switching tasks.

Well, in the RFC I'm currently (painfully slowly, sorry again) working
on, that IBPB is provided by ASI. Each process has an ASI domain, ASI
ensures there's an IBPB before we transition into any other domain
that doesn't trust it (VMs trust their VMM, but all other transitions
out of the userpace domain will flush).

In practice, this is just provided by the fact that context switching
currently incurs an asi_exit(), but that's an implementation detail,
if we transitioned directly from one process' domain to another that
would also create a flush.

(But yes, maybe that being "part of ASI" is just my very ASI-centric
perspective).

> Also guest_user mitigation is not a thing, did you mean guest_guest?  If so, the same argument applies.

Oh yep, sorry, and yep same response.