Thread (51 messages) 51 messages, 10 authors, 2021-12-03

Re: [RFC v2 PATCH 01/13] mm/shmem: Introduce F_SEAL_GUEST

From: Jason Gunthorpe <jgg@ziepe.ca>
Date: 2021-11-22 14:01:53
Also in: linux-fsdevel, linux-mm, lkml, qemu-devel

On Mon, Nov 22, 2021 at 02:35:49PM +0100, David Hildenbrand wrote:
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?

"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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help