Paul Moore wrote:

On Thu, Jun 5, 2025 at 1:50 AM Mike Rapoport [off-list ref] wrote:

quoted

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.

quoted

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]