linux-crypto.vger.kernel.org archive mirror
 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,
	tglx@linutronix.de, linux-crypto@vger.kernel.org,
	linux-api@vger.kernel.org, x86@kernel.org,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Adhemerval Zanella Netto <adhemerval.zanella@linaro.org>,
	Carlos O'Donell <carlos@redhat.com>,
	Florian Weimer <fweimer@redhat.com>,
	Arnd Bergmann <arnd@arndb.de>, Jann Horn <jannh@google.com>,
	Christian Brauner <brauner@kernel.org>,
	David Hildenbrand <dhildenb@redhat.com>
Subject: Re: [PATCH v16 2/5] random: add vgetrandom_alloc() syscall
Date: Fri, 7 Jun 2024 16:41:26 +0200	[thread overview]
Message-ID: <ZmMcFonXPVtU0moO@zx2c4.com> (raw)
In-Reply-To: <20240604172249.GA1566@sol.localdomain>

On Tue, Jun 04, 2024 at 10:22:49AM -0700, Eric Biggers wrote:
> On Sat, Jun 01, 2024 at 12:56:40PM +0200, Jason A. Donenfeld wrote:
> > On Thu, May 30, 2024 at 08:59:17PM -0700, Eric Biggers wrote:
> > > On Tue, May 28, 2024 at 02:19:51PM +0200, Jason A. Donenfeld wrote:
> > > > +/**
> > > > + * sys_vgetrandom_alloc - Allocate opaque states for use with vDSO getrandom().
> > > > + *
> > > > + * @num:	   On input, a pointer to a suggested hint of how many states to
> > > > + * 		   allocate, and on return the number of states actually allocated.
> > > > + *
> > > > + * @size_per_each: On input, must be zero. On return, the size of each state allocated,
> > > > + * 		   so that the caller can split up the returned allocation into
> > > > + * 		   individual states.
> > > > + *
> > > > + * @addr:	   Reserved, must be zero.
> > > > + *
> > > > + * @flags:	   Reserved, must be zero.
> > > > + *
> > > > + * The getrandom() vDSO function in userspace requires an opaque state, which
> > > > + * this function allocates by mapping a certain number of special pages into
> > > > + * the calling process. It takes a hint as to the number of opaque states
> > > > + * desired, and provides the caller with the number of opaque states actually
> > > > + * allocated, the size of each one in bytes, and the address of the first
> > > > + * state, which may be split up into @num states of @size_per_each bytes each,
> > > > + * by adding @size_per_each to the returned first state @num times, while
> > > > + * ensuring that no single state straddles a page boundary.
> > > > + *
> > > > + * Returns the address of the first state in the allocation on success, or a
> > > > + * negative error value on failure.
> > > > + *
> > > > + * The returned address of the first state may be passed to munmap(2) with a
> > > > + * length of `(size_t)num * (size_t)size_per_each`, in order to deallocate the
> > > > + * memory, after which it is invalid to pass it to vDSO getrandom().
> > > 
> > > Wouldn't a munmap with '(size_t)num * (size_t)size_per_each' be potentially too
> > > short, due to how the allocation is sized such that states don't cross page
> > > boundaries?
> > 
> > You're right, I think. The calculation should instead be something like:
> > 
> >     DIV_ROUND_UP(num, PAGE_SIZE / size_per_each) * PAGE_SIZE
> > 
> > Does that seem correct to you?
> > 
> 
> Yes, though I wonder if it would be better to give userspace the number of pages
> instead of the number of states.

Or maybe just the number of total bytes allocated? That would match
what's expected to be passed to munmap() and is maybe the easiest to
deal with. I'll give that a shot for v+1.

Jason

  reply	other threads:[~2024-06-07 14:41 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-05-28 12:19 [PATCH v16 0/5] implement getrandom() in vDSO Jason A. Donenfeld
2024-05-28 12:19 ` [PATCH v16 1/5] mm: add VM_DROPPABLE for designating always lazily freeable mappings Jason A. Donenfeld
2024-05-28 20:41   ` Frank van der Linden
2024-05-28 20:51     ` Jason A. Donenfeld
2024-05-31 10:48   ` Jann Horn
2024-05-31 12:13     ` Jason A. Donenfeld
2024-05-31 13:00       ` Jann Horn
2024-06-07 14:35         ` Jason A. Donenfeld
2024-06-07 15:12           ` Jann Horn
2024-06-07 15:50             ` Jann Horn
2024-06-10 12:00               ` Michal Hocko
2024-06-14 18:35                 ` Jason A. Donenfeld
2024-06-07 18:40   ` Andy Lutomirski
2024-05-28 12:19 ` [PATCH v16 2/5] random: add vgetrandom_alloc() syscall Jason A. Donenfeld
2024-05-31  3:59   ` Eric Biggers
2024-06-01 10:56     ` Jason A. Donenfeld
2024-06-04 17:22       ` Eric Biggers
2024-06-07 14:41         ` Jason A. Donenfeld [this message]
2024-06-07 14:45           ` Jason A. Donenfeld
2024-05-28 12:19 ` [PATCH v16 3/5] arch: allocate vgetrandom_alloc() syscall number Jason A. Donenfeld
2024-05-28 13:08   ` Geert Uytterhoeven
2024-05-28 13:10     ` Jason A. Donenfeld
2024-05-28 13:28       ` Jason A. Donenfeld
2024-05-31  2:26         ` Eric Biggers
2024-06-01 10:58           ` Jason A. Donenfeld
2024-05-28 12:19 ` [PATCH v16 4/5] random: introduce generic vDSO getrandom() implementation Jason A. Donenfeld
2024-05-31 19:12   ` Randy Dunlap
2024-05-31 19:15   ` Randy Dunlap
2024-06-07 15:37     ` Jason A. Donenfeld
2024-05-31 23:06   ` Andy Lutomirski
2024-06-07 15:52     ` Jason A. Donenfeld
2024-06-05 21:03   ` Thomas Gleixner
2024-06-05 22:10     ` Thomas Gleixner
2024-06-07 15:59       ` Jason A. Donenfeld
2024-06-07 16:32     ` Jason A. Donenfeld
2024-06-07 18:39   ` Andy Lutomirski
2024-05-28 12:19 ` [PATCH v16 5/5] x86: vdso: Wire up getrandom() vDSO implementation Jason A. Donenfeld
2024-05-31  3:38   ` Eric Biggers
2024-06-07 15:27     ` Jason A. Donenfeld
2024-05-31 19:16   ` Randy Dunlap
2024-06-07 15:30     ` Jason A. Donenfeld
2024-06-05 21:41   ` Thomas Gleixner
2024-06-07 15:32     ` Jason A. Donenfeld
2024-05-28 14:46 ` [PATCH v16 0/5] implement getrandom() in vDSO 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=ZmMcFonXPVtU0moO@zx2c4.com \
    --to=jason@zx2c4.com \
    --cc=adhemerval.zanella@linaro.org \
    --cc=arnd@arndb.de \
    --cc=brauner@kernel.org \
    --cc=carlos@redhat.com \
    --cc=dhildenb@redhat.com \
    --cc=ebiggers@kernel.org \
    --cc=fweimer@redhat.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=jannh@google.com \
    --cc=linux-api@vger.kernel.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;
as well as URLs for NNTP newsgroup(s).