linux-kernel - Re: [RFC PATCH 0/8] Unmapping 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: <CAJD7tkbeHVwABajRis0hHx9WLQ+yvnr=8gHQeEQcAi_BW9fAGQ@mail.gmail.com>
Date: Fri, 26 Jul 2024 09:44:40 -0700
From: Yosry Ahmed <yosryahmed@...gle.com>
To: Patrick Roy <roypat@...zon.co.uk>
Cc: seanjc@...gle.com, pbonzini@...hat.com, akpm@...ux-foundation.org, 
	dwmw@...zon.co.uk, rppt@...nel.org, david@...hat.com, tglx@...utronix.de, 
	mingo@...hat.com, bp@...en8.de, dave.hansen@...ux.intel.com, x86@...nel.org, 
	hpa@...or.com, willy@...radead.org, graf@...zon.com, derekmn@...zon.com, 
	kalyazin@...zon.com, kvm@...r.kernel.org, linux-kernel@...r.kernel.org, 
	linux-mm@...ck.org, dmatlack@...gle.com, tabba@...gle.com, 
	chao.p.peng@...ux.intel.com, xmarcalx@...zon.co.uk
Subject: Re: [RFC PATCH 0/8] Unmapping guest_memfd from Direct Map

On Tue, Jul 9, 2024 at 6:21 AM Patrick Roy <roypat@...zon.co.uk> wrote:
>
> Hey all,
>
> This RFC series is a rough draft adding support for running
> non-confidential compute VMs in guest_memfd, based on prior discussions
> with Sean [1]. Our specific usecase for this is the ability to unmap
> guest memory from the host kernel's direct map, as a mitigation against
> a large class of speculative execution issues.

Not to sound like a salesman, but did you happen to come across the RFC for ASI?
https://lore.kernel.org/lkml/20240712-asi-rfc-24-v1-0-144b319a40d8@google.com/

The current implementation considers userspace allocations as
sensitive, so when a VM is running with ASI, the memory of other VMs
is unmapped from the direct map (i.e. in the restricted address
space). It also incorporates a mechanism to map this memory on-demand
when needed (i.e. switch to the unrestricted address space), and
running mitigations at this point to make sure it isn't exploited.

In theory, it should be a more generic approach because it should
apply to VMs that do not use guest_memfd as well, and it should be
extensible to protect other parts of memory (e.g. sensitive kernel
allocations).

I understand that unmapping guest_memfd memory from the direct map in
general could still be favorable, and for other reasons beyond
mitigating speculative execution attacks. Just thought you may be
interested in looking at ASI.