Paul Moore wrote: > On Thu, Jun 5, 2025 at 1:50 AM Mike Rapoport <rppt@xxxxxxxxxx> 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]
