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: <8c1fb4092547e2453ddcdcfab97f06e273ad17d8.camel@intel.com>
Date: Fri, 16 Jan 2026 17:51:30 +0000
From: "Edgecombe, Rick P" <rick.p.edgecombe@...el.com>
To: "Annapurve, Vishal" <vannapurve@...gle.com>
CC: "david@...nel.org" <david@...nel.org>, "kvm@...r.kernel.org"
	<kvm@...r.kernel.org>, "catalin.marinas@....com" <catalin.marinas@....com>,
	"palmer@...belt.com" <palmer@...belt.com>, "jgross@...e.com"
	<jgross@...e.com>, "bpf@...r.kernel.org" <bpf@...r.kernel.org>,
	"surenb@...gle.com" <surenb@...gle.com>, "riel@...riel.com"
	<riel@...riel.com>, "pfalcato@...e.de" <pfalcato@...e.de>,
	"peterx@...hat.com" <peterx@...hat.com>, "x86@...nel.org" <x86@...nel.org>,
	"rppt@...nel.org" <rppt@...nel.org>, "thuth@...hat.com" <thuth@...hat.com>,
	"borntraeger@...ux.ibm.com" <borntraeger@...ux.ibm.com>, "maz@...nel.org"
	<maz@...nel.org>, "svens@...ux.ibm.com" <svens@...ux.ibm.com>,
	"ast@...nel.org" <ast@...nel.org>, "vbabka@...e.cz" <vbabka@...e.cz>,
	"pjw@...nel.org" <pjw@...nel.org>, "alex@...ti.fr" <alex@...ti.fr>,
	"dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>,
	"tglx@...utronix.de" <tglx@...utronix.de>, "hca@...ux.ibm.com"
	<hca@...ux.ibm.com>, "willy@...radead.org" <willy@...radead.org>,
	"wyihan@...gle.com" <wyihan@...gle.com>, "ryan.roberts@....com"
	<ryan.roberts@....com>, "yang@...amperecomputing.com"
	<yang@...amperecomputing.com>, "jolsa@...nel.org" <jolsa@...nel.org>,
	"jmattson@...gle.com" <jmattson@...gle.com>, "aneesh.kumar@...nel.org"
	<aneesh.kumar@...nel.org>, "luto@...nel.org" <luto@...nel.org>,
	"haoluo@...gle.com" <haoluo@...gle.com>, "patrick.roy@...ux.dev"
	<patrick.roy@...ux.dev>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>, "akpm@...ux-foundation.org"
	<akpm@...ux-foundation.org>, "coxu@...hat.com" <coxu@...hat.com>,
	"mhocko@...e.com" <mhocko@...e.com>, "mlevitsk@...hat.com"
	<mlevitsk@...hat.com>, "linux-kselftest@...r.kernel.org"
	<linux-kselftest@...r.kernel.org>, "jgg@...pe.ca" <jgg@...pe.ca>,
	"loongarch@...ts.linux.dev" <loongarch@...ts.linux.dev>, "song@...nel.org"
	<song@...nel.org>, "oupton@...nel.org" <oupton@...nel.org>,
	"jhubbard@...dia.com" <jhubbard@...dia.com>, "kernel@...0n.name"
	<kernel@...0n.name>, "hpa@...or.com" <hpa@...or.com>,
	"lorenzo.stoakes@...cle.com" <lorenzo.stoakes@...cle.com>,
	"Liam.Howlett@...cle.com" <Liam.Howlett@...cle.com>, "martin.lau@...ux.dev"
	<martin.lau@...ux.dev>, "jthoughton@...gle.com" <jthoughton@...gle.com>, "Yu,
 Yu-cheng" <yu-cheng.yu@...el.com>, "maobibo@...ngson.cn"
	<maobibo@...ngson.cn>, "kvmarm@...ts.linux.dev" <kvmarm@...ts.linux.dev>,
	"Jonathan.Cameron@...wei.com" <Jonathan.Cameron@...wei.com>,
	"peterz@...radead.org" <peterz@...radead.org>, "eddyz87@...il.com"
	<eddyz87@...il.com>, "yonghong.song@...ux.dev" <yonghong.song@...ux.dev>,
	"linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>, "shuah@...nel.org"
	<shuah@...nel.org>, "chenhuacai@...nel.org" <chenhuacai@...nel.org>,
	"prsampat@....com" <prsampat@....com>, "kevin.brodsky@....com"
	<kevin.brodsky@....com>, "shijie@...amperecomputing.com"
	<shijie@...amperecomputing.com>, "suzuki.poulose@....com"
	<suzuki.poulose@....com>, "itazur@...zon.co.uk" <itazur@...zon.co.uk>,
	"pbonzini@...hat.com" <pbonzini@...hat.com>, "yuzenghui@...wei.com"
	<yuzenghui@...wei.com>, "dev.jain@....com" <dev.jain@....com>,
	"gor@...ux.ibm.com" <gor@...ux.ibm.com>, "jackabt@...zon.co.uk"
	<jackabt@...zon.co.uk>, "daniel@...earbox.net" <daniel@...earbox.net>,
	"agordeev@...ux.ibm.com" <agordeev@...ux.ibm.com>, "andrii@...nel.org"
	<andrii@...nel.org>, "mingo@...hat.com" <mingo@...hat.com>,
	"linux-riscv@...ts.infradead.org" <linux-riscv@...ts.infradead.org>,
	"aou@...s.berkeley.edu" <aou@...s.berkeley.edu>, "joey.gouly@....com"
	<joey.gouly@....com>, "derekmn@...zon.com" <derekmn@...zon.com>,
	"xmarcalx@...zon.co.uk" <xmarcalx@...zon.co.uk>, "linux-s390@...r.kernel.org"
	<linux-s390@...r.kernel.org>, "kpsingh@...nel.org" <kpsingh@...nel.org>,
	"kalyazin@...zon.co.uk" <kalyazin@...zon.co.uk>,
	"linux-arm-kernel@...ts.infradead.org"
	<linux-arm-kernel@...ts.infradead.org>, "sdf@...ichev.me" <sdf@...ichev.me>,
	"jackmanb@...gle.com" <jackmanb@...gle.com>, "bp@...en8.de" <bp@...en8.de>,
	"corbet@....net" <corbet@....net>, "linux-fsdevel@...r.kernel.org"
	<linux-fsdevel@...r.kernel.org>, "ackerleytng@...gle.com"
	<ackerleytng@...gle.com>, "jannh@...gle.com" <jannh@...gle.com>,
	"john.fastabend@...il.com" <john.fastabend@...il.com>, "kas@...nel.org"
	<kas@...nel.org>, "linux-mm@...ck.org" <linux-mm@...ck.org>,
	"will@...nel.org" <will@...nel.org>, "seanjc@...gle.com" <seanjc@...gle.com>
Subject: Re: [PATCH v9 07/13] KVM: guest_memfd: Add flag to remove from direct
 map

On Fri, 2026-01-16 at 09:30 -0800, Vishal Annapurve wrote:
> > TDX does some clearing at the direct map mapping for pages that
> > comes from gmem, using a special instruction. It also does some
> > clflushing at the direct map address for these pages. So I think we
> > need to make sure TDs don't pull from gmem fds with this flag.
> 
> Disabling this feature for TDX VMs for now seems ok. I assume TDX
> code can establish temporary mappings to the physical memory and
> therefore doesn't necessarily have to rely on direct map.

Can, as in, can be changed to? It doesn't now, because the direct map
is reliable today.

> 
> Is it safe to say that we can remove direct map for guest memory for
> TDX VMs (and ideally other CC VMs as well) in future as needed?

Linux code doesn't need to read the cipher text of course, but it does
need to help with memory cleaning on the errata systems. Doing a new
mapping for each page getting reclaimed would add cost to the shutdown
path.

Then there is the clfush. It is not actually required for the most
part. There is a TDX flag to check to see if you need to do it, so we
could probably remove the direct map accesses for some systems and
avoid temporary mappings.

So long term, I don't see a problem. For the old systems it would have
extra cost of temporary mappings at shutdown, but I would have imagined
direct map removal would have been costly too.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ