Re: [RFC PATCH 0/7] support for mm-local memory allocations and use it

[David Hildenbrand <david@redhat.com>]

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