[PATCH 1/2] fs: Provide function that allocates a secure anonymous inode

[Ira Weiny]

Paul Moore wrote:
> On Thu, Jun 5, 2025 at 1:50 AM Mike Rapoport <rppt at kernel.org> wrote:
> >
> > secretmem always had S_PRIVATE set because alloc_anon_inode() clears it
> > anyway and this patch does not change it.
> 
> Yes, my apologies, I didn't look closely enough at the code.
> 
> > I'm just thinking that it makes sense to actually allow LSM/SELinux
> > controls that S_PRIVATE bypasses for both secretmem and guest_memfd.
> 
> It's been a while since we added the anon_inode hooks so I'd have to
> go dig through the old thread to understand the logic behind marking
> secretmem S_PRIVATE, especially when the
> anon_inode_make_secure_inode() function cleared it.  It's entirely
> possible it may have just been an oversight.

I'm jumping in where I don't know what I'm talking about...

But my reading of the S_PRIVATE flag is that the memory can't be mapped by
user space.  So for guest_memfd() we need !S_PRIVATE because it is
intended to be mapped by user space.  So we want the secure checks.

I think secretmem is the same.

Do I have that right?

Ira

[snip]