RE: [RESEND RFC PATCH 0/5] Remote mapping

From: Andy Lutomirski <luto@kernel.org>

quoted

quoted

As it stands, the way that KVM memory mappings are created seems to
be convenient, but it also seems to be resulting in increasing
bizarre userspace mappings.  At what point is the right solution to
decouple KVM’s mappings from QEMU’s?

Convenience is one of the drivers of code reuse.

quoted

So what you are suggesting is that KVM manages its own address space
instead of host virtual addresses (and with no relationship to host
virtual addresses, it would be just a "cookie")?  It would then need a
couple ioctls to mmap/munmap (creating and deleting VMAs) into the
address space, and those cookies would be passed to
KVM_SET_USER_MEMORY_REGION.  QEMU would still need access to

these

quoted

VMAs, would it mmap a file descriptor provided by KVM?  All in all the
implementation seems quite complex, and I don't understand why it
would avoid incoherent SEV mappings; what am I missing?

It might not avoid incoherent SEV mappings in particular, but it would
certainly enable other, somewhat related usecases.  For example, QEMU
could have KVM map a memfd without itself mapping that memfd, which
would reduce the extent to which the memory would be exposed to an
attacker who can read QEMU memory.

Isn't this security through obscurity?

For this pidfd-mem scheme in particular, it might avoid the nasty corner case
I mentioned.  With pidfd-mem as in this patchset, I'm concerned about what
happens when process A maps some process B memory, process B maps
some of process A's memory, and there's a recursive mapping that results.
Or when a process maps its own memory, for that matter.  If KVM could map
fd's directly, then there could be a parallel mechanism for KVM to import
portions of more than one process's address space, and this particular
problem would be avoided.  So a process would create pidfd-mem-like
object and pass that to KVM (via an intermediary process or directly) and
KVM could map that, but no normal process would be allowed to map it.  This
avoids the recursion problems.

Or memfd could get fancier with operations to split memfds, remove pages
from memfds, etc.  Maybe that's overkill.

(Or a fancy recursion detector could be built, but this has been a pain point in
AF_UNIX, epoll, etc in the past.  It may be solvable, but it won't be pretty.)

I admit that allowing KVM to map fd's directly without some specific
vm_operations support for this could be challenging, but ISTM kvm could
plausibly own an mm_struct and pagetables at the cost of some wasted
memory.  The result would, under the hood, work more or less like the
current implementation, but the API would be quite different.

This looks like an attempt to pass memory related concerns to KVM developers.
The userspace mapping mechanism is good as it is. Probably not perfect, just 
good. The problem is that it's stuck to a few VMA models and needs to evolve
towards more bizarre/sketchy/weird/fragile patterns.

Also the memory code is one of the most tightly coupled code I have seen.
Probably explains the fear of the maintainers to try something new.

Mircea