On Wed, Aug 10, 2022 at 11:55:19AM +0200, David Hildenbrand wrote:
On 10.08.22 11:37, Chao Peng wrote:
On Fri, Aug 05, 2022 at 03:28:50PM +0200, David Hildenbrand wrote:
On 06.07.22 10:20, Chao Peng wrote:
Introduce a new memfd_create() flag indicating the content of the created memfd is inaccessible from userspace through ordinary MMU access (e.g., read/write/mmap). However, the file content can be accessed via a different mechanism (e.g. KVM MMU) indirectly.
It provides semantics required for KVM guest private memory support that a file descriptor with this flag set is going to be used as the source of guest memory in confidential computing environments such as Intel TDX/AMD SEV but may not be accessible from host userspace.
The flag can not coexist with MFD_ALLOW_SEALING, future sealing is also impossible for a memfd created with this flag.
It's kind of weird to have it that way. Why should the user have to care? It's the notifier requirement to have that, no?
Why can't we handle that when register a notifier? If anything is already mapped, fail registering the notifier if the notifier has these demands. If registering succeeds, block it internally.
Or what am I missing? We might not need the memfile set flag semantics eventually and would not have to expose such a flag to user space.
This makes sense if doable. The major concern was: is there a reliable way to detect this (already mapped) at the time of memslot registering.
If too complicated, we could simplify to "was this ever mapped" and fail for now. Hooking into shmem_mmap() might be sufficient for that to get notified about the first mmap.
As an alternative, mapping_mapped() or similar *might* do what we want.
mapping_mapped() sounds the right one, I remember SEV people want first map then unmap. "was this ever mapped" may not work for them.
Thanks, Chao
-- Thanks,
David / dhildenb