[RFC PATCH 0/7] support for mm-local memory allocations and use it
David Hildenbrand
david at redhat.com
Fri Sep 27 05:59:39 PDT 2024
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
More information about the linux-arm-kernel
mailing list