linux-kernel - Re: [PATCH v7 06/12] KVM: guest_memfd: add module param for disabling TLB flushing

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: <c1875a54-0c87-450f-9370-29e7ec4fea3d@redhat.com>
Date: Thu, 25 Sep 2025 21:20:23 +0200
From: David Hildenbrand <david@...hat.com>
To: Dave Hansen <dave.hansen@...el.com>, "Roy, Patrick" <roypat@...zon.co.uk>
Cc: "pbonzini@...hat.com" <pbonzini@...hat.com>,
 "corbet@....net" <corbet@....net>, "maz@...nel.org" <maz@...nel.org>,
 "oliver.upton@...ux.dev" <oliver.upton@...ux.dev>,
 "joey.gouly@....com" <joey.gouly@....com>,
 "suzuki.poulose@....com" <suzuki.poulose@....com>,
 "yuzenghui@...wei.com" <yuzenghui@...wei.com>,
 "catalin.marinas@....com" <catalin.marinas@....com>,
 "will@...nel.org" <will@...nel.org>, "tglx@...utronix.de"
 <tglx@...utronix.de>, "mingo@...hat.com" <mingo@...hat.com>,
 "bp@...en8.de" <bp@...en8.de>,
 "dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>,
 "x86@...nel.org" <x86@...nel.org>, "hpa@...or.com" <hpa@...or.com>,
 "luto@...nel.org" <luto@...nel.org>,
 "peterz@...radead.org" <peterz@...radead.org>,
 "willy@...radead.org" <willy@...radead.org>,
 "akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
 "lorenzo.stoakes@...cle.com" <lorenzo.stoakes@...cle.com>,
 "Liam.Howlett@...cle.com" <Liam.Howlett@...cle.com>,
 "vbabka@...e.cz" <vbabka@...e.cz>, "rppt@...nel.org" <rppt@...nel.org>,
 "surenb@...gle.com" <surenb@...gle.com>, "mhocko@...e.com"
 <mhocko@...e.com>, "song@...nel.org" <song@...nel.org>,
 "jolsa@...nel.org" <jolsa@...nel.org>, "ast@...nel.org" <ast@...nel.org>,
 "daniel@...earbox.net" <daniel@...earbox.net>,
 "andrii@...nel.org" <andrii@...nel.org>,
 "martin.lau@...ux.dev" <martin.lau@...ux.dev>,
 "eddyz87@...il.com" <eddyz87@...il.com>,
 "yonghong.song@...ux.dev" <yonghong.song@...ux.dev>,
 "john.fastabend@...il.com" <john.fastabend@...il.com>,
 "kpsingh@...nel.org" <kpsingh@...nel.org>, "sdf@...ichev.me"
 <sdf@...ichev.me>, "haoluo@...gle.com" <haoluo@...gle.com>,
 "jgg@...pe.ca" <jgg@...pe.ca>, "jhubbard@...dia.com" <jhubbard@...dia.com>,
 "peterx@...hat.com" <peterx@...hat.com>, "jannh@...gle.com"
 <jannh@...gle.com>, "pfalcato@...e.de" <pfalcato@...e.de>,
 "shuah@...nel.org" <shuah@...nel.org>, "seanjc@...gle.com"
 <seanjc@...gle.com>, "kvm@...r.kernel.org" <kvm@...r.kernel.org>,
 "linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
 "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
 "linux-arm-kernel@...ts.infradead.org"
 <linux-arm-kernel@...ts.infradead.org>,
 "kvmarm@...ts.linux.dev" <kvmarm@...ts.linux.dev>,
 "linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>,
 "linux-mm@...ck.org" <linux-mm@...ck.org>,
 "bpf@...r.kernel.org" <bpf@...r.kernel.org>,
 "linux-kselftest@...r.kernel.org" <linux-kselftest@...r.kernel.org>,
 "Cali, Marco" <xmarcalx@...zon.co.uk>,
 "Kalyazin, Nikita" <kalyazin@...zon.co.uk>,
 "Thomson, Jack" <jackabt@...zon.co.uk>,
 "derekmn@...zon.co.uk" <derekmn@...zon.co.uk>,
 "tabba@...gle.com" <tabba@...gle.com>,
 "ackerleytng@...gle.com" <ackerleytng@...gle.com>
Subject: Re: [PATCH v7 06/12] KVM: guest_memfd: add module param for disabling
 TLB flushing

On 25.09.25 20:27, Dave Hansen wrote:
> On 9/24/25 08:22, Roy, Patrick wrote:
>> Add an option to not perform TLB flushes after direct map manipulations.
> 
> I'd really prefer this be left out for now. It's a massive can of worms.
> Let's agree on something that works and has well-defined behavior before
> we go breaking it on purpose.

May I ask what the big concern here is? Not to challenge your position 
but to understand the involved problems and what would have to be 
documented at some point in a patch.

Essentially we're removing the direct map from some memory we allocated 
through the buddy to reinstall it before we free the memory back to the 
buddy.

So from the buddy POV whether we flush or don't flush the TLB shouldn't 
matter, right?

Where the missing TLB flush would be relevant is to the workload (VM) 
where some (speculative) access through the direct map would be possible 
until the TLB was flushed.

So until flushed, it's not-as-secure-as-you think. A flush after some 
time (batched over multiple page allocations?) could make it deterministic.

Is there something else that's problematic?

-- 
Cheers

David / dhildenb