linux-kernel - Re: [PATCH v5 00/12] AMD broadcast TLB invalidation

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: <01cba8ef-b68f-4074-9a7b-7258eaee3893@intel.com>
Date: Tue, 21 Jan 2025 09:14:32 -0800
From: Dave Hansen <dave.hansen@...el.com>
To: Michael Kelley <mhklinux@...look.com>, "riel@...riel.com"
 <riel@...riel.com>, "x86@...nel.org" <x86@...nel.org>
Cc: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
 "bp@...en8.de" <bp@...en8.de>, "peterz@...radead.org"
 <peterz@...radead.org>,
 "dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>,
 "zhengqi.arch@...edance.com" <zhengqi.arch@...edance.com>,
 "nadav.amit@...il.com" <nadav.amit@...il.com>,
 "thomas.lendacky@....com" <thomas.lendacky@....com>,
 "kernel-team@...a.com" <kernel-team@...a.com>,
 "linux-mm@...ck.org" <linux-mm@...ck.org>,
 "akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
 "jannh@...gle.com" <jannh@...gle.com>,
 "andrew.cooper3@...rix.com" <andrew.cooper3@...rix.com>
Subject: Re: [PATCH v5 00/12] AMD broadcast TLB invalidation

On 1/16/25 10:14, Michael Kelley wrote:
> So CoCo VMs may still use the paravirtualization that makes
> hypercalls to do TLB flushes. It's future work to *always* use
> INVLPGB (if available) in a CoCo VM.

How would this actually work, though?

One of the reasons that we have the whole TLB_NR_DYN_ASIDS mechanism is
that picking a PCID to shove in CR3 is an entirely CPU local operation.
The PCID is in a CPU-local namespace and nobody else cares what it is.

Rik obviously now has a system-wide set of IDs which are globally
visible and globally valid. But his mechanism is also a bit choosy so
that the global resource management doesn't get to be a choke point.

But if we move to INVLPGB-only, we're all of a sudden *forced* to do
some kind of wide global resource management, even for single-threaded
processes. Rik doesn't have a scheme for that in the current set.

So I think this would be a whole separate conversation from this series.