Messages in this thread | | | Date | Mon, 22 Nov 2021 10:01:48 -0400 | From | Jason Gunthorpe <> | Subject | Re: [RFC v2 PATCH 01/13] mm/shmem: Introduce F_SEAL_GUEST |
| |
On Mon, Nov 22, 2021 at 02:35:49PM +0100, David Hildenbrand wrote: > On 22.11.21 14:31, Jason Gunthorpe wrote: > > On Mon, Nov 22, 2021 at 10:26:12AM +0100, David Hildenbrand wrote: > > > >> 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?
"no new access" makes sense to me, we have access through read/write/mmap/splice/etc and access to pages through the private in kernel interface (kvm, iommu)
Jason
| |