Hi, Thanks for taking a look and apologies for my delayed response. > It is not clear from the change log above or the cover letter as to why > you need to go this route instead of using the mmap lock. In the current form of the patches I use memfd_secret() to allocate the pages and remove them from kernel linear address. [1] This allocate pages, map them in user virtual addresses and track them in a VMA. Before flipping the permissions on those pages to be used by the kernel, I need to make sure that those virtual addresses and this VMA is off-limits to the owning process. memfd_secret() pages are locked by default, so they won't swap out. I need to seal the VMA to make sure the owner process can't unmap/remap/... or change the protection of this VMA. So before changing the permissions on the secret pages, I make sure the pages are faulted in, locked and sealed. So userspace can't influence this mapping. > We can't use the mseal feature for this; it is supposed to be a one way > transition. For this approach, I need the unseal operation when releasing the memory range. The kernel can be done with the secret pages in one of two scenarios: 1. During lifecycle of the process. 2. When the process terminates. For the first case, I need to unmap the VMA so it can be reused by the owning process later, so I need the unseal operation. For the second case however we don't need that since the process mm is already destructed or just about to be destructed anyway, regardless of sealed/unsealed VMAs. [1] I didn't expose the unseal operation to userspace. [1] https://lore.kernel.org/linux-arm-kernel/20240911143421.85612-3-faresx@xxxxxxxxx/ Thanks! Fares. Amazon Web Services Development Center Germany GmbH Krausenstr. 38 10117 Berlin Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss Eingetragen am Amtsgericht Charlottenburg unter HRB 257764 B Sitz: Berlin Ust-ID: DE 365 538 597
