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
