Re: [RFC v2 PATCH 01/13] mm/shmem: Introduce F_SEAL_GUEST
From: David Hildenbrand <hidden>
Date: 2021-11-22 14:57:27
Also in:
kvm, linux-fsdevel, lkml, qemu-devel
From: David Hildenbrand <hidden>
Date: 2021-11-22 14:57:27
Also in:
kvm, linux-fsdevel, lkml, qemu-devel
On 22.11.21 15:01, Jason Gunthorpe wrote:
On Mon, Nov 22, 2021 at 02:35:49PM +0100, David Hildenbrand wrote:quoted
On 22.11.21 14:31, Jason Gunthorpe wrote:quoted
On Mon, Nov 22, 2021 at 10:26:12AM +0100, David Hildenbrand wrote:quoted
I do wonder if we want to support sharing such memfds between processes in all cases ... we most certainly don't want to be able to share encrypted memory between VMs (I heard that the kernel has to forbid that). It would make sense in the use case you describe, though.If there is a F_SEAL_XX that blocks every kind of new access, who cares if userspace passes the FD around or not?I was imagining that you actually would want to do some kind of "change ownership". But yeah, the intended semantics and all use cases we have in mind are not fully clear to me yet. If it's really "no new access" (side note: is "access" the right word?) then sure, we can pass the fd around.What is "ownership" in a world with kvm and iommu are reading pages out of the same fd?
In the world of encrypted memory / TDX, KVM somewhat "owns" that memory IMHO (for example, only it can migrate or swap out these pages; it's might be debatable if the TDX module or KVM actually "own" these pages ). -- Thanks, David / dhildenb