| 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: <CAEvNRgHMOWfCRnkx7YJoAzNpBBOHCgvR5GHe66uHJX45WDT-YA@mail.gmail.com> Date: Tue, 27 Jan 2026 16:29:04 -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>, "peterx@...hat.com" <peterx@...hat.com>, "alex@...ti.fr" <alex@...ti.fr>, "pjw@...nel.org" <pjw@...nel.org>, "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>, "jolsa@...nel.org" <jolsa@...nel.org>, "yang@...amperecomputing.com" <yang@...amperecomputing.com>, "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>, "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>, "oupton@...nel.org" <oupton@...nel.org>, "Liam.Howlett@...cle.com" <Liam.Howlett@...cle.com>, "kernel@...0n.name" <kernel@...0n.name>, "Jonathan.Cameron@...wei.com" <Jonathan.Cameron@...wei.com>, "lorenzo.stoakes@...cle.com" <lorenzo.stoakes@...cle.com>, "jhubbard@...dia.com" <jhubbard@...dia.com>, "jthoughton@...gle.com" <jthoughton@...gle.com>, "martin.lau@...ux.dev" <martin.lau@...ux.dev>, "Yu, Yu-cheng" <yu-cheng.yu@...el.com>, "peterz@...radead.org" <peterz@...radead.org>, "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 14:47 -0800, Ackerley Tng wrote: >> >> 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. > > Ah! > >> >> 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? > > Yes, just private pages need the special treatment. But it will be much > simpler to start with just blocking the option for TDX. A shared pages > only mode could come later. > > In general I think we should try to break things up like this when we > can. Kernel code is not set in stone, only ABI. I think it will lead to > overall faster upstreaming, because the series' can be simpler. I agree on splitting the feature up :), agree that simpler series are better. Perhaps just for my understanding, + shared pages => not in direct map => no TDX clflush + private pages => always in direct map => TDX performs clflush (I could put pages back into the direct map while doing shared to private conversions). Is everything good then? Or does TDX code not apply the special treatment, as in clflush only for private pages, as of now?
Powered by blists - more mailing lists