linux-kernel - Re: [PATCH 2/4] x86/virt/tdx: Advertise the CC_ATTR_HOST_MEM

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]

Date: Wed, 31 Jan 2024 09:11:20 -0800
From: Dave Hansen <dave.hansen@...el.com>
To: "Huang, Kai" <kai.huang@...el.com>, linux-kernel@...r.kernel.org
Cc: x86@...nel.org, kirill.shutemov@...ux.intel.com, tglx@...utronix.de,
 bp@...en8.de, mingo@...hat.com, hpa@...or.com, luto@...nel.org,
 peterz@...radead.org, thomas.lendacky@....com, chao.gao@...el.com,
 bhe@...hat.com, nik.borisov@...e.com, pbonzini@...hat.com
Subject: Re: [PATCH 2/4] x86/virt/tdx: Advertise the
 CC_ATTR_HOST_MEM_INCOHERENT for TDX host

On 1/31/24 03:31, Huang, Kai wrote:
> From: Kai Huang <kai.huang@...el.com>
> 
> On the TDX capable platform, during kexec() the old kernel needs to
> flush dirty cachelines of all TDX private memory otherwise they may
> silently corrupt the new kernel's memory.
> 
> Advertise the new introduced CC_ATTR_HOST_MEM_INCOHERENT attribute for
> TDX host platform so the cache will be flushed during kexec().

So, you're setting a new bit, CC_ATTR_HOST_MEM_INCOHERENT.  The way I
like to deal with these is to go back and look at the definition of
CC_ATTR_HOST_MEM_INCOHERENT and see whether the changelog here convinces
me that CC_ATTR_HOST_MEM_INCOHERENT is being set appropriately.  Bonus
points if this changelog uses the same nomenclature as the comment
describing CC_ATTR_HOST_MEM_INCOHERENT.

How well does this match the comment above CC_ATTR_HOST_MEM_INCOHERENT?

> Note theoretically cache flush is only needed when TDX module is
> initialized, but the module initialization is done at runtime so just
> advertise the CC attribute when the platform has TDX enabled.

I find this really hard to parse.  Here's a rewrite, as usual:

	A TDX-host-capable system might not actually have any incoherent
	memory.  This can occur if a TDX module was never initialized or
	if the caches have been flushed since the last time TDX was
	used.  Ignore that case.  Eliminate the need for any locking and
	assume that any TDX-host-capable system might have incoherent
	memory by always setting CC_ATTR_HOST_MEM_INCOHERENT.