| 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
| ||
|
Message-ID: <CAEvNRgEz0+ic9uvcsWYqWgR5EV=TfY0SAGC39zAL+n19SoBXmw@mail.gmail.com> Date: Thu, 22 Jan 2026 14:47:28 -0800 From: Ackerley Tng <ackerleytng@...gle.com> To: "Edgecombe, Rick P" <rick.p.edgecombe@...el.com>, "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>, "svens@...ux.ibm.com" <svens@...ux.ibm.com>, "jgross@...e.com" <jgross@...e.com>, "bpf@...r.kernel.org" <bpf@...r.kernel.org>, "surenb@...gle.com" <surenb@...gle.com>, "vbabka@...e.cz" <vbabka@...e.cz>, "riel@...riel.com" <riel@...riel.com>, "pfalcato@...e.de" <pfalcato@...e.de>, "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>, "palmer@...belt.com" <palmer@...belt.com>, "ast@...nel.org" <ast@...nel.org>, "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>, "luto@...nel.org" <luto@...nel.org>, "aneesh.kumar@...nel.org" <aneesh.kumar@...nel.org>, "haoluo@...gle.com" <haoluo@...gle.com>, "patrick.roy@...ux.dev" <patrick.roy@...ux.dev>, "peterx@...hat.com" <peterx@...hat.com>, "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>, "linux-kselftest@...r.kernel.org" <linux-kselftest@...r.kernel.org>, "mlevitsk@...hat.com" <mlevitsk@...hat.com>, "jgg@...pe.ca" <jgg@...pe.ca>, "loongarch@...ts.linux.dev" <loongarch@...ts.linux.dev>, "song@...nel.org" <song@...nel.org>, "Liam.Howlett@...cle.com" <Liam.Howlett@...cle.com>, "oupton@...nel.org" <oupton@...nel.org>, "kernel@...0n.name" <kernel@...0n.name>, "lorenzo.stoakes@...cle.com" <lorenzo.stoakes@...cle.com>, "peterz@...radead.org" <peterz@...radead.org>, "Jonathan.Cameron@...wei.com" <Jonathan.Cameron@...wei.com>, "martin.lau@...ux.dev" <martin.lau@...ux.dev>, "jthoughton@...gle.com" <jthoughton@...gle.com>, "jhubbard@...dia.com" <jhubbard@...dia.com>, "Yu, Yu-cheng" <yu-cheng.yu@...el.com>, "kvmarm@...ts.linux.dev" <kvmarm@...ts.linux.dev>, "eddyz87@...il.com" <eddyz87@...il.com>, "hpa@...or.com" <hpa@...or.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>, "maobibo@...ngson.cn" <maobibo@...ngson.cn>, "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>, "gor@...ux.ibm.com" <gor@...ux.ibm.com>, "dev.jain@....com" <dev.jain@....com>, "daniel@...earbox.net" <daniel@...earbox.net>, "jackabt@...zon.co.uk" <jackabt@...zon.co.uk>, "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>, "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 "Edgecombe, Rick P" <rick.p.edgecombe@...el.com> writes: > On Thu, 2026-01-22 at 08:44 -0800, Ackerley Tng wrote: >> >> Can we disable direct map removal for errata systems using TDX only, >> instead of all TDX? >> >> If it's complicated to figure that out, we can disable direct map >> removal for TDX for now and figure that out later. > > In theory, but it still would require changes to TDX code since it does > the clflush unconditionally today. To know whether clflush is needed > (it's a different thing to the errata), you need to check a TDX module > flag. (CLFLUSH_BEFORE_ALLOC) > > Gosh, you know what, I should double check that we don't need the > clflush from the vm shutdown optimization. It should be a different > thing, but for we gave scrutiny to the whole Linux flow when we did > that. So I'd have to double check nothing relied on it. We can follow > up here. > >> >> > 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. >> >> Is there a way to check if the code is running on the errata system >> and set up the temporary mappings only for those? > > The TDX code today doesn't do any remapping because the direct map is > reliably present. There isn't a flag or anything to just do the > remapping automatically. We would have to do some vmalloc mapping or > temporary_mm or something. > > Can you explain what the use case is for unmapping encrypted TDX > private memory from the host direct map? There's no use case I can think of for unmapping TDX private memory from the host direct map, but Sean's suggestion https://lore.kernel.org/all/aWpcDrGVLrZOqdcg@google.com/ won't even let shared guest_memfd memory be unmapped from the direct map for TDX VMs. Actually, does TDX's clflush that assumes presence in the direct map apply only for private pages, or all pages? If TDX's clflush only happens for private pages, then we could restore private pages to the direct map, and then we'd be safe even for TDX?
Powered by blists - more mailing lists