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: <CAG48ez2F_rcqoBndiJb_r1wWCJG9wHenpQ=N8h5B6XBgb_1p2g@mail.gmail.com>
Date: Tue, 21 Jan 2025 18:22:09 +0100
From: Jann Horn <jannh@...gle.com>
To: Michael Kelley <mhklinux@...look.com>
Cc: "riel@...riel.com" <riel@...riel.com>, "x86@...nel.org" <x86@...nel.org>, 
	"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>, 
	"andrew.cooper3@...rix.com" <andrew.cooper3@...rix.com>
Subject: Re: [PATCH v5 00/12] AMD broadcast TLB invalidation

On Thu, Jan 16, 2025 at 7:14 PM Michael Kelley <mhklinux@...look.com> wrote:
> We had an earlier thread about INVLPGB/TLBSYNC in a VM [1]. It
> turns out that Hyper-V in the Azure public cloud enables
> INVLPGB/TLBSYNC in Confidential VMs (CVMs, which conform to the
> Linux concept of a CoCo VM) running on AMD processors using SEV-SNP.
> The CPUID instruction in a such a VM reports the enablement as
> expected. The instructions are *not* enabled in general purpose VMs
> running on the same AMD processors. The enablement is a natural
> outgrowth of CoCo VM's wanting to be able to avoid a dependency on
> the untrusted hypervisor to perform TLB flushes.

What is this current dependency on the untrusted hypervisor? Is it
just the PV TLB flushing optimization for preempted vCPUs? The normal
x86 TLB flushing machinery waits for confirmation from the other vCPUs
in smp_call_function_many_cond(), and the hypervisor shouldn't be able
to fake that confirmation, right?

Can you avoid this issue by disabling the PV TLB flushing optimization?