On Fri, Feb 11, 2022 at 03:33:35PM -0800, Andy Lutomirski wrote: > On 1/18/22 05:21, Chao Peng wrote: > > From: "Kirill A. Shutemov" <kirill.shutemov@xxxxxxxxxxxxxxx> > > > > Introduce a new seal F_SEAL_INACCESSIBLE indicating the content of > > the file 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 seal 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. > > > > At this time only shmem implements this seal. > > > > I don't dislike this *that* much, but I do dislike this. F_SEAL_INACCESSIBLE > essentially transmutes a memfd into a different type of object. While this > can apparently be done successfully and without races (as in this code), > it's at least awkward. I think that either creating a special inaccessible > memfd should be a single operation that create the correct type of object or > there should be a clear justification for why it's a two-step process. Now one justification maybe from Stever's comment to patch-00: for ARM usage it can be used with creating a normal memfd, (partially)populate it with initial guest memory content (e.g. firmware), and then F_SEAL_INACCESSIBLE it just before the first time lunch of the guest in KVM (definitely the current code needs to be changed to support that). Thanks, Chao > > (Imagine if the way to create an eventfd would be to call timerfd_create() > and then do a special fcntl to turn it into an eventfd but only if it's not > currently armed. This would be weird.)
