Thread (10 messages) 10 messages, 6 authors, 2020-08-26

Re: [RFC PATCH] mm: extend memfd with ability to create "secret" memory areas

From: Mike Rapoport <rppt@kernel.org>
Date: 2020-02-16 06:47:00
Also in: linux-mm, lkml

On Wed, Feb 12, 2020 at 02:10:29PM -0700, Jonathan Corbet wrote:
On Thu, 30 Jan 2020 18:23:41 +0200
Mike Rapoport [off-list ref] wrote:
quoted
Hi,

This is essentially a resend of my attempt to implement "secret" mappings
using a file descriptor [1]. 
So one little thing I was curious about as I read through the patch...
quoted
+static int secretmem_check_limits(struct vm_fault *vmf)
+{
+	struct secretmem_state *state = vmf->vma->vm_file->private_data;
+	struct inode *inode = file_inode(vmf->vma->vm_file);
+	unsigned long limit;
+
+	if (((loff_t)vmf->pgoff << PAGE_SHIFT) >= i_size_read(inode))
+		return -EINVAL;
+
+	limit = rlimit(RLIMIT_MEMLOCK) >> PAGE_SHIFT;
+	if (state->nr_pages + 1 >= limit)
+		return -EPERM;
+
+	return 0;
+}
If I'm not mistaken, this means each memfd can be RLIMIT_MEMLOCK in length,
with no global limit on the number of locked pages.  What's keeping me from
creating 1000 of these things and locking down lots of RAM?
Indeed, it's possible to lock down RLIMIT_MEMLOCK * RLIMIT_NOFILE of RAM
with this implementation, thanks for catching this.

I'll surely update the resource limiting once we've settle on the API
selection :)
 
Thanks,

jon
-- 
Sincerely yours,
Mike.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help