Message-ID: <813b9bcb-afde-40b6-a604-cdb71b4b6d7a@redhat.com>
Date: Fri, 27 Sep 2024 14:59:39 +0200
From: David Hildenbrand <david@...hat.com>
To: Fares Mehanna <faresx@...zon.de>
Cc: nh-open-source@...zon.com, Marc Zyngier <maz@...nel.org>,
 Oliver Upton <oliver.upton@...ux.dev>, James Morse <james.morse@....com>,
 Suzuki K Poulose <suzuki.poulose@....com>, Zenghui Yu
 <yuzenghui@...wei.com>, Catalin Marinas <catalin.marinas@....com>,
 Will Deacon <will@...nel.org>, Andrew Morton <akpm@...ux-foundation.org>,
 Kemeng Shi <shikemeng@...weicloud.com>,
 Pierre-Clément Tosi <ptosi@...gle.com>,
 Ard Biesheuvel <ardb@...nel.org>, Mark Rutland <mark.rutland@....com>,
 Javier Martinez Canillas <javierm@...hat.com>, Arnd Bergmann
 <arnd@...db.de>, Fuad Tabba <tabba@...gle.com>,
 Mark Brown <broonie@...nel.org>, Joey Gouly <joey.gouly@....com>,
 Kristina Martsenko <kristina.martsenko@....com>,
 Randy Dunlap <rdunlap@...radead.org>, Bjorn Helgaas <bhelgaas@...gle.com>,
 Jean-Philippe Brucker <jean-philippe@...aro.org>,
 "Mike Rapoport (IBM)" <rppt@...nel.org>, Roman Kagan <rkagan@...zon.de>,
 "moderated list:KERNEL VIRTUAL MACHINE FOR ARM64 (KVM/arm64)"
 <linux-arm-kernel@...ts.infradead.org>,
 "open list:KERNEL VIRTUAL MACHINE FOR ARM64 (KVM/arm64)"
 <kvmarm@...ts.linux.dev>, open list <linux-kernel@...r.kernel.org>,
 "open list:MEMORY MANAGEMENT" <linux-mm@...ck.org>
Subject: Re: [RFC PATCH 0/7] support for mm-local memory allocations and use
 it

On 11.09.24 16:33, Fares Mehanna wrote:
> In a series posted a few years ago [1], a proposal was put forward to allow the
> kernel to allocate memory local to a mm and thus push it out of reach for
> current and future speculation-based cross-process attacks.  We still believe
> this is a nice thing to have.
> 
> However, in the time passed since that post Linux mm has grown quite a few new
> goodies, so we'd like to explore possibilities to implement this functionality
> with less effort and churn leveraging the now available facilities.
> 
> An RFC was posted few months back [2] to show the proof of concept and a simple
> test driver.
> 
> In this RFC, we're using the same approach of implementing mm-local allocations
> piggy-backing on memfd_secret(), using regular user addresses but pinning the
> pages and flipping the user/supervisor flag on the respective PTEs to make them
> directly accessible from kernel.
> In addition to that we are submitting 5 patches to use the secret memory to hide
> the vCPU gp-regs and fp-regs on arm64 VHE systems.

I'm a bit lost on what exactly we want to achieve. The point where we 
start flipping user/supervisor flags confuses me :)

With secretmem, you'd get memory allocated that
(a) Is accessible by user space -- mapped into user space.
(b) Is inaccessible by kernel space -- not mapped into the direct map
(c) GUP will fail, but copy_from / copy_to user will work.


Another way, without secretmem, would be to consider these "secrets" 
kernel allocations that can be mapped into user space using mmap() of a 
special fd. That is, they wouldn't have their origin in secretmem, but 
in KVM as a kernel allocation. It could be achieved by using VM_MIXEDMAP 
with vm_insert_pages(), manually removing them from the directmap.

But, I am not sure who is supposed to access what. Let's explore the 
requirements. I assume we want:

(a) Pages accessible by user space -- mapped into user space.
(b) Pages inaccessible by kernel space -- not mapped into the direct map
(c) GUP to fail (no direct map).
(d) copy_from / copy_to user to fail?

And on top of that, some way to access these pages on demand from kernel 
space? (temporary CPU-local mapping?)

Or how would the kernel make use of these allocations?

-- 
Cheers,

David / dhildenb

Powered by blists - more mailing lists