Messages in this thread | | | Date | Tue, 23 Aug 2022 09:36:57 +0200 | Subject | Re: [PATCH v7 01/14] mm: Add F_SEAL_AUTO_ALLOCATE seal to memfd | From | David Hildenbrand <> |
| |
On 18.08.22 01:41, Kirill A. Shutemov wrote: > On Fri, Aug 05, 2022 at 07:55:38PM +0200, Paolo Bonzini wrote: >> On 7/21/22 11:44, David Hildenbrand wrote: >>> >>> Also, I*think* you can place pages via userfaultfd into shmem. Not >>> sure if that would count "auto alloc", but it would certainly bypass >>> fallocate(). >> >> Yeah, userfaultfd_register would probably have to forbid this for >> F_SEAL_AUTO_ALLOCATE vmas. Maybe the memfile_node can be reused for this, >> adding a new MEMFILE_F_NO_AUTO_ALLOCATE flags? Then userfault_register >> would do something like memfile_node_get_flags(vma->vm_file) and check the >> result. > > I donno, memory allocation with userfaultfd looks pretty intentional to > me. Why would F_SEAL_AUTO_ALLOCATE prevent it? >
Can't we say the same about a write()?
> Maybe we would need it in the future for post-copy migration or something? > > Or existing practises around userfaultfd touch memory randomly and > therefore incompatible with F_SEAL_AUTO_ALLOCATE intent? > > Note, that userfaultfd is only relevant for shared memory as it requires > VMA which we don't have for MFD_INACCESSIBLE.
This feature (F_SEAL_AUTO_ALLOCATE) is independent of all the lovely encrypted VM stuff, so it doesn't matter how it relates to MFD_INACCESSIBLE.
-- Thanks,
David / dhildenb
| |