public inbox for linux-crypto@vger.kernel.org
 help / color / mirror / Atom feed
From: "Jason A. Donenfeld" <Jason@zx2c4.com>
To: Eric Biggers <ebiggers@kernel.org>
Cc: linux-kernel@vger.kernel.org, patches@lists.linux.dev,
	linux-crypto@vger.kernel.org, x86@kernel.org,
	Thomas Gleixner <tglx@linutronix.de>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Adhemerval Zanella Netto <adhemerval.zanella@linaro.org>,
	Carlos O'Donell <carlos@redhat.com>
Subject: Re: [PATCH v5 1/3] random: add vgetrandom_alloc() syscall
Date: Sun, 20 Nov 2022 00:59:07 +0100	[thread overview]
Message-ID: <Y3ltyzxIPwniRNW5@zx2c4.com> (raw)
In-Reply-To: <Y3k+/hSL5rIIkBhK@sol.localdomain>

Hi Eric,

On Sat, Nov 19, 2022 at 12:39:26PM -0800, Eric Biggers wrote:
> On Sat, Nov 19, 2022 at 01:09:27PM +0100, Jason A. Donenfeld wrote:
> > +SYSCALL_DEFINE3(vgetrandom_alloc, unsigned long __user *, num,
> > +		unsigned long __user *, size_per_each, unsigned int, flags)
> > +{
> > +	unsigned long alloc_size;
> > +	unsigned long num_states;
> > +	unsigned long pages_addr;
> > +	int ret;
> > +
> > +	if (flags)
> > +		return -EINVAL;
> > +
> > +	if (get_user(num_states, num))
> > +		return -EFAULT;
> > +
> > +	alloc_size = size_mul(num_states, sizeof(struct vgetrandom_state));
> > +	if (alloc_size == SIZE_MAX)
> > +		return -EOVERFLOW;
> > +	alloc_size = roundup(alloc_size, PAGE_SIZE);
> 
> Small detail: the roundup to PAGE_SIZE can make alloc_size overflow to 0.
> 
> Also, 'roundup(alloc_size, PAGE_SIZE)' could be 'PAGE_ALIGN(alloc_size)'.

Good catch, thanks. So perhaps this?

        alloc_size = size_mul(num_states, sizeof(struct vgetrandom_state));
        if (alloc_size > SIZE_MAX - PAGE_SIZE + 1)
                return -EOVERFLOW;
        alloc_size = PAGE_ALIGN(alloc_size);

Does that look right?

> > +	pages_addr = vm_mmap(NULL, 0, alloc_size, PROT_READ | PROT_WRITE,
> > +			     MAP_PRIVATE | MAP_ANONYMOUS | MAP_LOCKED, 0);
> > +	if (IS_ERR_VALUE(pages_addr))
> > +		return pages_addr;
> 
> This will only succeed if the userspace process has permission to mlock pages,
> i.e. if there is space available in RLIMIT_MEMLOCK or if process has
> CAP_IPC_LOCK.  I suppose this is working as intended, as this syscall can be
> used to try to allocate and mlock arbitrary amounts of memory.
> 
> I wonder if this permission check will cause problems.  Maybe there could be a
> way to relax it for just one page per task?  I don't know how that would work,
> though, especially when the planned usage involves userspace allocating a single
> pool of these contexts per process that get handed out to threads.

Probably though, we don't want to create a mlock backdoor, right? I
suppose if a user is above RLIMIT_MEMLOCK, it'll just fallback to the
slowpath, which still works. That seems like an okay enough
circumstance.

Jason

  reply	other threads:[~2022-11-19 23:59 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-19 12:09 [PATCH v5 0/3] implement getrandom() in vDSO Jason A. Donenfeld
2022-11-19 12:09 ` [PATCH v5 1/3] random: add vgetrandom_alloc() syscall Jason A. Donenfeld
2022-11-19 20:39   ` Eric Biggers
2022-11-19 23:59     ` Jason A. Donenfeld [this message]
2022-11-20  1:40       ` Eric Biggers
2022-11-20  1:45         ` Jason A. Donenfeld
2022-11-19 12:09 ` [PATCH v5 2/3] random: introduce generic vDSO getrandom() implementation Jason A. Donenfeld
2022-11-19 23:10   ` Eric Biggers
2022-11-20  0:53     ` Jason A. Donenfeld
2022-11-20  1:04       ` Jason A. Donenfeld
2022-11-21  3:23         ` Jason A. Donenfeld
2022-11-20  1:43       ` Jason A. Donenfeld
2022-11-21  3:22         ` Jason A. Donenfeld
2022-11-20  1:51       ` Eric Biggers
2022-11-19 12:09 ` [PATCH v5 3/3] x86: vdso: Wire up getrandom() vDSO implementation Jason A. Donenfeld

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Y3ltyzxIPwniRNW5@zx2c4.com \
    --to=jason@zx2c4.com \
    --cc=adhemerval.zanella@linaro.org \
    --cc=carlos@redhat.com \
    --cc=ebiggers@kernel.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=patches@lists.linux.dev \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox