Re: [PATCH v11 4/9] mm: introduce memfd_secret system call to create "secret" memory areas

On Tue, Nov 24, 2020 at 10:59:48AM +0000, Catalin Marinas wrote:

Hi Mike,

On Tue, Nov 24, 2020 at 11:25:51AM +0200, Mike Rapoport wrote:

quoted

+static vm_fault_t secretmem_fault(struct vm_fault *vmf)
+{
+	struct address_space *mapping = vmf->vma->vm_file->f_mapping;

...

quoted

+
+		err = set_direct_map_invalid_noflush(page, 1);
+		if (err)
+			goto err_del_page_cache;

On arm64, set_direct_map_default_noflush() returns 0 if !rodata_full but
no pgtable changes happen since the linear map can be a mix of small and
huge pages. The arm64 implementation doesn't break large mappings. I
presume we don't want to tell the user that the designated memory is
"secret" but the kernel silently ignored it.

We could change the arm64 set_direct_map* to return an error, however, I
think it would be pretty unexpected for the user to get a fault when
trying to access it. It may be better to return a -ENOSYS or something
on the actual syscall if the fault-in wouldn't be allowed later.

Alternatively, we could make the linear map always use pages on arm64,
irrespective of other config or cmdline options (maybe not justified
unless we have clear memsecret users). Yet another idea is to get
set_direct_map* to break pmd/pud mappings into pte but that's not always
possible without a stop_machine() and potentially disabling the MMU.

My preference would be to check at secretmem initialization if
set_direct_map_*() actually do anything and then return an error from
the syscall if they are essentially nop.

I'll update the patches with something like this in v12.

-- 
Catalin

-- 
Sincerely yours,
Mike.