linux-kernel - Re: [RFC PATCH v3 0/6] Direct Map Removal for guest

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: <27646c08-f724-49f7-9f45-d03bad500219@amazon.co.uk>
Date: Thu, 31 Oct 2024 10:42:00 +0000
From: Patrick Roy <roypat@...zon.co.uk>
To: David Hildenbrand <david@...hat.com>, <tabba@...gle.com>,
	<quic_eberman@...cinc.com>, <seanjc@...gle.com>, <pbonzini@...hat.com>,
	<jthoughton@...gle.com>, <ackerleytng@...gle.com>, <vannapurve@...gle.com>,
	<rppt@...nel.org>
CC: <graf@...zon.com>, <jgowans@...zon.com>, <derekmn@...zon.com>,
	<kalyazin@...zon.com>, <xmarcalx@...zon.com>, <linux-mm@...ck.org>,
	<corbet@....net>, <catalin.marinas@....com>, <will@...nel.org>,
	<chenhuacai@...nel.org>, <kernel@...0n.name>, <paul.walmsley@...ive.com>,
	<palmer@...belt.com>, <aou@...s.berkeley.edu>, <hca@...ux.ibm.com>,
	<gor@...ux.ibm.com>, <agordeev@...ux.ibm.com>, <borntraeger@...ux.ibm.com>,
	<svens@...ux.ibm.com>, <gerald.schaefer@...ux.ibm.com>, <tglx@...utronix.de>,
	<mingo@...hat.com>, <bp@...en8.de>, <dave.hansen@...ux.intel.com>,
	<x86@...nel.org>, <hpa@...or.com>, <luto@...nel.org>, <peterz@...radead.org>,
	<rostedt@...dmis.org>, <mhiramat@...nel.org>,
	<mathieu.desnoyers@...icios.com>, <shuah@...nel.org>, <kvm@...r.kernel.org>,
	<linux-doc@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
	<linux-arm-kernel@...ts.infradead.org>, <loongarch@...ts.linux.dev>,
	<linux-riscv@...ts.infradead.org>, <linux-s390@...r.kernel.org>,
	<linux-trace-kernel@...r.kernel.org>, <linux-kselftest@...r.kernel.org>
Subject: Re: [RFC PATCH v3 0/6] Direct Map Removal for guest_memfd

On Thu, 2024-10-31 at 09:50 +0000, David Hildenbrand wrote:
> On 30.10.24 14:49, Patrick Roy wrote:
>> Unmapping virtual machine guest memory from the host kernel's direct map
>> is a successful mitigation against Spectre-style transient execution
>> issues: If the kernel page tables do not contain entries pointing to
>> guest memory, then any attempted speculative read through the direct map
>> will necessarily be blocked by the MMU before any observable
>> microarchitectural side-effects happen. This means that Spectre-gadgets
>> and similar cannot be used to target virtual machine memory. Roughly 60%
>> of speculative execution issues fall into this category [1, Table 1].
>>
>> This patch series extends guest_memfd with the ability to remove its
>> memory from the host kernel's direct map, to be able to attain the above
>> protection for KVM guests running inside guest_memfd.
>>
>> === Changes to v2 ===
>>
>> - Handle direct map removal for physically contiguous pages in arch code
>>    (Mike R.)
>> - Track the direct map state in guest_memfd itself instead of at the
>>    folio level, to prepare for huge pages support (Sean C.)
>> - Allow configuring direct map state of not-yet faulted in memory
>>    (Vishal A.)
>> - Pay attention to alignment in ftrace structs (Steven R.)
>>
>> Most significantly, I've reduced the patch series to focus only on
>> direct map removal for guest_memfd for now, leaving the whole "how to do
>> non-CoCo VMs in guest_memfd" for later. If this separation is
>> acceptable, then I think I can drop the RFC tag in the next revision
>> (I've mainly kept it here because I'm not entirely sure what to do with
>> patches 3 and 4).
> 
> Hi,
> 
> keeping upcoming "shared and private memory in guest_memfd" in mind, I
> assume the focus would be to only remove the direct map for private memory?
> 
> So in the current upstream state, you would only be removing the direct
> map for private memory, currently translating to "encrypted"/"protected"
> memory that is inaccessible either way already.
> 
> Correct?

Yea, with the upcomming "shared and private" stuff, I would expect the
the shared<->private conversions would call the routines from patch 3 to
restore direct map entries on private->shared, and zap them on
shared->private.

But as you said, the current upstream state has no notion of "shared"
memory in guest_memfd, so everything is private and thus everything is
direct map removed (although it is indeed already inaccessible anyway
for TDX and friends. That's what makes this patch series a bit awkward
:( )

> -- 
> Cheers,
> 
> David / dhildenb
> 

Best, 
Patrick