linux-kernel - Re: [PATCH v3 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: <81c63009-efc2-4f82-a6f8-b6378cb11a6b@citrix.com>
Date: Thu, 9 Jan 2025 02:25:14 +0000
From: Andrew Cooper <andrew.cooper3@...rix.com>
To: yosryahmed@...gle.com
Cc: akpm@...ux-foundation.org, bp@...en8.de, dave.hansen@...ux.intel.com,
 hpa@...or.com, jackmanb@...gle.com, kernel-team@...a.com,
 linux-kernel@...r.kernel.org, linux-mm@...ck.org, luto@...nel.org,
 mingo@...hat.com, nadav.amit@...il.com, peterz@...radead.org,
 reijiw@...gle.com, riel@...riel.com, tglx@...utronix.de, x86@...nel.org,
 zhengqi.arch@...edance.com
Subject: Re: [PATCH v3 00/12] AMD broadcast TLB invalidation

>> I suspect AMD wouldn't tell us exactly ;)
>
> Well, ideally they would just tell us the conditions under which CPUs
> respond to the broadcast TLB flush or the expectations around latency.

Disclaimer.  I'm not at AMD; I don't know how they implement it; I'm
just a random person on the internet.  But, here are a few things that
might be relevant to know.

AMD's SEV-SNP whitepaper [1] states that RMP permissions "are cached in
the CPU TLB and related structures" and also "When required, hardware
automatically performs TLB invalidations to ensure that all processors
in the system see the updated RMP entry information."

That sentence doesn't use "broadcast" or "remote", but "all processors"
is a pretty clear clue.  Broadcast TLB invalidations are a building
block of all the RMP-manipulation instructions.

Furthermore, to be useful in this context, they need to be ordered with
memory.  Specifically, a new pagewalk mustn't start after an
invalidation, yet observe the stale RMP entry.

x86 CPUs do have reasonable forward-progress guarantees, but in order to
achieve forward progress, they need to e.g. guarantee that one memory
access doesn't displace the TLB entry backing a different memory access
from the same instruction, or you could livelock while trying to
complete a single instruction.

A consequence is that you can't safely invalidate a TLB entry of an
in-progress instruction (although this means only the oldest instruction
in the pipeline, because everything else is speculative and potentially
transient).

INVLPGB invalidations are interrupt-like from the point of view of the
remote core, but can be processed

~Andrew

[1]
https://www.amd.com/content/dam/amd/en/documents/epyc-business-docs/white-papers/SEV-SNP-strengthening-vm-isolation-with-integrity-protection-and-more.pdf