[RFC,v2] random: implement getrandom() in vDSO

Two statements:

  1) Userspace wants faster cryptographically secure random numbers of
     arbitrary size, big or small.

  2) Userspace is currently unable to safely roll its own RNG with the
     same security profile as getrandom().

Statement (1) has been debated for years, with arguments ranging from
"we need faster cryptographically secure card shuffling!" to "the only
things that actually need good randomness are keys, which are few and
far between" to "actually, TLS CBC nonces are frequent" and so on. I
don't intend to wade into that debate substantially, except to note that
recently glibc added arc4random(), whose goal is to return a
cryptographically secure uint32_t. So here we are.

Statement (2) is more interesting. The kernel is the nexus of all
entropic inputs that influence the RNG. It is in the best position, and
probably the only position, to decide anything at all about the current
state of the RNG and of its entropy. One of the things it uniquely knows
about is when reseeding is necessary.

For example, when a virtual machine is forked, restored, or duplicated,
it's imparative that the RNG doesn't generate the same outputs. For this
reason, there's a small protocol between hypervisors and the kernel that
indicates this has happened, alongside some ID, which the RNG uses to
immediately reseed, so as not to return the same numbers. Were userspace
to expand a getrandom() seed from time T1 for the next hour, and at some
point T2 < hour, the virtual machine forked, userspace would continue to
provide the same numbers to two (or more) different virtual machines,
resulting in potential cryptographic catastrophe. Something similar
happens on resuming from hibernation (or even suspend), with various
compromise scenarios there in mind.

There's a more general reason why userspace rolling its own RNG from a
getrandom() seed is fraught. There's a lot of attention paid to this
particular Linuxism we have of the RNG being initialized and thus
non-blocking or uninitialized and thus blocking until it is initialized.
These are our Two Big States that many hold to be the holy
differentiating factor between safe and not safe, between
cryptographically secure and garbage. The fact is, however, that the
distinction between these two states is a hand-wavy wishy-washy inexact
approximation. Outside of a few exceptional cases (e.g. a HW RNG is
available), we actually don't really ever know with any rigor at all
when the RNG is safe and ready (nor when it's compromised). We do the
best we can to "estimate" it, but entropy estimation is fundamentally
impossible in the general case. So really, we're just doing guess work,
and hoping it's good and conservative enough. Let's then assume that
there's always some potential error involved in this differentiator.

In fact, under the surface, the RNG is engineered around a different
principal, and that is trying to *use* new entropic inputs regularly and
at the right specific moments in time. For example, close to boot time,
the RNG reseeds itself more often than later. At certain events, like VM
fork, the RNG reseeds itself immediately. The various heuristics for
when the RNG will use new entropy and how often is really a core aspect
of what the RNG has some potential to do decently enough (and something
that will probably continue to improve in the future from random.c's
present set of algorithms). So in your mind, put away the metal
attachment to the Two Big States, which represent an approximation with
a potential margin of error. Instead keep in mind that the RNG's primary
operating heuristic is how often and exactly when it's going to reseed.

So, if userspace takes a seed from getrandom() at point T1, and uses it
for the next hour (or N megabytes or some other meaningless metric),
during that time, potential errors in the Two Big States approximation
are amplified. During that time potential reseeds are being lost,
forgotten, not reflected in the output stream. That's not good.

The simplest statement you could make is that userspace RNGs that expand
a getrandom() seed at some point T1 are nearly always *worse*, in some
way, than just calling getrandom() every time a random number is
desired.

For those reasons, after some discussion on libc-alpha, glibc's
arc4random() now just calls getrandom() on each invocation. That's
trivially safe, and gives us latitude to then make the safe thing faster
without becoming unsafe at our leasure. Card shuffling isn't
particularly fast, however.

How do we rectify this? By putting a safe implementation of getrandom()
in the vDSO, which has access to whatever information a
particular iteration of random.c is using to make its decisions. I use
that careful language of "particular iteration of random.c", because the
set of things that a vDSO getrandom() implementation might need for making
decisions as good as the kernel's will likely change over time. This
isn't just a matter of exporting certain *data* to userspace. We're not
going to commit to a "data API" where the various heuristics used are
exposed, locking in how the kernel works for decades to come, and then
leave it to various userspaces to roll something on top and shoot
themselves in the foot and have all sorts of complexity disasters.
Rather, vDSO getrandom() is supposed to be the *same exact algorithm*
that runs in the kernel, except it's been hoisted into userspace as
much as possible. And so vDSO getrandom() and kernel getrandom() will
always mirror each other hermetically.

API-wise, vDSO getrandom has a pair of functions:

  ssize_t getrandom(void *state, void *buffer, size_t len, unsigned int flags);
  void *getrandom_alloc([inout] size_t *num, [out] size_t *size_per_each);

In the first function, the return value and the latter 3 arguments are
the same as ordinary getrandom(), while the first argument is a pointer
to some state allocated with getrandom_alloc(). getrandom_alloc() takes
the desired number of states, and returns an array of states, the number
actually allocated, and the size in bytes of each one, enabling a libc
to use one per thread. We very intentionally do *not* leave state
allocation up to the caller. There are too many weird things that can go
wrong, and it's important that vDSO does not provide too generic of a
mechanism. It's not going to store its state in just any old memory
address. It'll do it only in ones it allocates.

Right now this means it's a mlock'd page with WIPEONFORK set. In the
future maybe there will be other interesting page flags or
anti-heartbleed measures, or other platform-specific kernel-specific
things that can be set. Again, it's important that the vDSO has a say in
how this works rather than agreeing to operate on any old address;
memory isn't neutral.

The interesting meat of the implementation is in lib/vdso/getrandom.c,
as generic C code, and it aims to mainly follow random.c's buffered fast
key erasure logic. Before the RNG is initialized, it falls back to the
syscall. Right now it uses a simple generation counter to make its
decisions on reseeding; this covers many cases, but not all, so this RFC
still has a little bit of improvement work to do. But it should give you
the general idea.

The actual place that has the most work to do is in all of the other
files. Most of the vDSO shared page infrastructure is centered around
gettimeofday, and so the main structs are all in arrays for different
timestamp types, and attached to time namespaces, and so forth. I've
done the best I could to add onto this in an unintrusive way, but you'll
notice almost immediately from glancing at the code that it still needs
some untangling work. This also only works on x86 at the moment. I could
certainly use a hand with this part.

So far in my test results, performance is pretty stellar (around 15x for
uint32_t generation), and it seems to be working. But this is very, very
young, immature code, suitable for an RFC and no more, so expect
dragons.

Cc: linux-crypto@vger.kernel.org
Cc: x86@kernel.org
Cc: Nadia Heninger <nadiah@cs.ucsd.edu>
Cc: Thomas Ristenpart <ristenpart@cornell.edu>
Cc: Theodore Ts'o <tytso@mit.edu>
Cc: Vincenzo Frascino <vincenzo.frascino@arm.com>
Cc: Adhemerval Zanella Netto <adhemerval.zanella@linaro.org>
Cc: Florian Weimer <fweimer@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
---
I'm not in a hurry to make this patch happen, but I know some people
wanted to tinker around with this, and given that this v2 drops v1's
sharding, I figure I should post this sooner so there's something to
play with.

Changes v1->v2:
- Hoist !len check out of batch_len check.
- Use smp_store_release instead of WRITE_ONCE.
- Account for fork() during execution.
- Simplify API so that libc passes a state per thread, allocated with a
  separate function.
- Attempt to approximate crng_has_old_seed(). This needs work still, but is a
  step in the right direction.
- Document generation counter quirks in comment.
- getrandom() takes `unsigned int flags`, not `unsigned long flags`.

 MAINTAINERS                           |   1 +
 arch/x86/entry/vdso/Makefile          |   2 +-
 arch/x86/entry/vdso/vdso.lds.S        |   4 +
 arch/x86/entry/vdso/vgetrandom.c      |  24 ++++
 arch/x86/include/asm/vdso/getrandom.h |  74 +++++++++++++
 arch/x86/include/asm/vvar.h           |  16 +++
 drivers/char/random.c                 |   4 +
 include/vdso/datapage.h               |   6 +
 lib/vdso/getrandom.c                  | 151 ++++++++++++++++++++++++++
 9 files changed, 281 insertions(+), 1 deletion(-)
 create mode 100644 arch/x86/entry/vdso/vgetrandom.c
 create mode 100644 arch/x86/include/asm/vdso/getrandom.h
 create mode 100644 lib/vdso/getrandom.c

* Jason A. Donenfeld:

> API-wise, vDSO getrandom has a pair of functions:
>
>   ssize_t getrandom(void *state, void *buffer, size_t len, unsigned int flags);
>   void *getrandom_alloc([inout] size_t *num, [out] size_t *size_per_each);
>
> In the first function, the return value and the latter 3 arguments are
> the same as ordinary getrandom(), while the first argument is a pointer
> to some state allocated with getrandom_alloc(). getrandom_alloc() takes
> the desired number of states, and returns an array of states, the number
> actually allocated, and the size in bytes of each one, enabling a libc
> to use one per thread. We very intentionally do *not* leave state
> allocation up to the caller. There are too many weird things that can go
> wrong, and it's important that vDSO does not provide too generic of a
> mechanism. It's not going to store its state in just any old memory
> address. It'll do it only in ones it allocates.

I still don't see why this couldn't be per-thread state (if you handle
fork generations somehow).

I also think it makes sense to introduce batching for the system call
implementation first, and tie that to the vDSO acceleration.  I expect a
large part of the benefit comes from the batching, not the system call
avoidance.

Thanks,
Florian

Hey Florian,

On Mon, Aug 01, 2022 at 10:48:01AM +0200, Florian Weimer wrote:
> * Jason A. Donenfeld:
> 
> > API-wise, vDSO getrandom has a pair of functions:
> >
> >   ssize_t getrandom(void *state, void *buffer, size_t len, unsigned int flags);
> >   void *getrandom_alloc([inout] size_t *num, [out] size_t *size_per_each);
> >
> > In the first function, the return value and the latter 3 arguments are
> > the same as ordinary getrandom(), while the first argument is a pointer
> > to some state allocated with getrandom_alloc(). getrandom_alloc() takes
> > the desired number of states, and returns an array of states, the number
> > actually allocated, and the size in bytes of each one, enabling a libc
> > to use one per thread. We very intentionally do *not* leave state
> > allocation up to the caller. There are too many weird things that can go
> > wrong, and it's important that vDSO does not provide too generic of a
> > mechanism. It's not going to store its state in just any old memory
> > address. It'll do it only in ones it allocates.
> 
> I still don't see why this couldn't be per-thread state (if you handle
> fork generations somehow).

That actually *is* the intent of this v2. Specifically, you call
getrandom_alloc and you get an *array* of states, which you can then
pass off to various threads. Since we have to allocate in page sizes, we
can't do this piecemeal, so this is a mechanism for giving out chunks of
them (~28 at a time), which you'd then give to threads as they're
created, making more as needed.

> I also think it makes sense to introduce batching for the system call
> implementation first, and tie that to the vDSO acceleration.  I expect a
> large part of the benefit comes from the batching, not the system call
> avoidance.

What I understand you to mean is that *instead of* doing vDSO, we could
just batch in the kernel, and reap most of the performance benefits. If
that turns out to be true, and then we don't even need this vDSO stuff,
I'd be really happy. So I'll give this a try.

One question is where to store that batch. On the surface, per-cpu seems
appealing, like what we do for get_random_u32() and such for kernel
callers. But per-cpu means disabling preemption, which then becomes a
problem when copying into userspace, where the copies can fault. So
maybe something more sensible is, like above, just doing this per-task.
I'll give it a stab and will let you know what it looks like.

Jason

On Sun, Jul 31, 2022 at 03:31:25AM +0200, Jason A. Donenfeld wrote:
> +	batch_len = min_t(size_t, sizeof(state->batch) - state->pos, len);
> +	if (batch_len) {
> +		memcpy_and_zero(buffer, state->batch, batch_len);

Should be state->batch + state->pos, of course.

> +		state->pos += batch_len;
> +		buffer += batch_len;
> +		len -= batch_len;
> +	}

Hi Florian,

On Mon, Aug 01, 2022 at 02:49:17PM +0200, Jason A. Donenfeld wrote:
> What I understand you to mean is that *instead of* doing vDSO, we could
> just batch in the kernel, and reap most of the performance benefits. If
> that turns out to be true, and then we don't even need this vDSO stuff,
> I'd be really happy. So I'll give this a try.
> 
> One question is where to store that batch. On the surface, per-cpu seems
> appealing, like what we do for get_random_u32() and such for kernel
> callers. But per-cpu means disabling preemption, which then becomes a
> problem when copying into userspace, where the copies can fault. So
> maybe something more sensible is, like above, just doing this per-task.
> I'll give it a stab and will let you know what it looks like.

So doing the batching in the kernel gives roughly a 2x performance boost
for the u32 case. Below is a little hacky patch you can play with. This
isn't the face melting 15x of the vDSO approach, but it is something, I
guess.

Jason

On Sun, Jul 31 2022 at 03:31, Jason A. Donenfeld wrote:

> +vobjs-y := vdso-note.o vclock_gettime.o vgetcpu.o vgetrandom.o

You clearly forgot to tell people that they need a special config to
make this compile.

I don't even have to try to see that this cannot build with a defconfig:

Lacks -pg for that file and the included chacha.c contains
EXPORT_SYMBOL() which is not really working in the VDSO.

> +DECLARE_VVAR_SINGLE(640, struct vdso_rng_data, _vdso_rng_data)
...
> +#define __vdso_rng_data (VVAR(_vdso_rng_data))
> +
> +static __always_inline const struct vdso_rng_data *__arch_get_vdso_rng_data(void)
> +{
> +	return &__vdso_rng_data;
> +}

That's not working with time name spaces.

> +static __always_inline ssize_t
> +__cvdso_getrandom(void *opaque_state, void *buffer, size_t len, unsigned int flags)
> +{
> +	struct getrandom_state *state = opaque_state;
> +	const struct vdso_rng_data *rng_info = __arch_get_vdso_rng_data();

This gives you vvar__vdso_rng_data and that points to the VVAR page at
offset 640. That works up to the point where a task is part of a
non-root time name space.

The kernel side mapping (the one which is updated) looks like this:

    VVAR_PAGE
    VIRT_CLOCK_PAGE[S]
    TIMENS_PAGE

If time namespaces are disabled or the task is in the root time
namespace then the user mapping is in the same order.

If the task is in the non-root time namespace, then the user mapping is:

    TIMENS_PAGE
    VIRT_CLOCK_PAGE[S]
    VVAR_PAGE

So your user space looks at offset 640 in the TIMENS_PAGE, which has
rand_data->ready and rand_data->generation == 0 forever.

See the comment above timens_setup_vdso_data() and look at the way how
e.g. __cvdso_time_data() deals with that.

VDSO hacking is special and not a sunday evening project. :)

Thanks,

        tglx

Hi Thomas,

On Mon, Aug 01, 2022 at 10:48:56PM +0200, Thomas Gleixner wrote:
> On Sun, Jul 31 2022 at 03:31, Jason A. Donenfeld wrote:
> You clearly forgot to tell people that they need a special config to
> make this compile.

As I wrote in my patch body:

| The actual place that has the most work to do is in all of the other
| files. Most of the vDSO shared page infrastructure is centered around
| gettimeofday, and so the main structs are all in arrays for different
| timestamp types, and attached to time namespaces, and so forth. I've
| done the best I could to add onto this in an unintrusive way, but you'll
| notice almost immediately from glancing at the code that it still needs
| some untangling work. This also only works on x86 at the moment. I could
| certainly use a hand with this part.

So I'm not surprised other things are screwed up. This works well in my
test harness, indeed, but I imagine there are lots of fiddly bits like
that to work out. I wanted to send an RFC to elicit comments on the idea
and API before moving forward, as I have a strong sense this is one of
those "90% 10%" things, where 10% of the details take 90% of the time.

Also, I haven't hooked up vdso32 yet.

> > +vobjs-y := vdso-note.o vclock_gettime.o vgetcpu.o vgetrandom.o
> 
> I don't even have to try to see that this cannot build with a defconfig:
> 
> Lacks -pg for that file and the included chacha.c contains
> EXPORT_SYMBOL() which is not really working in the VDSO.

Thanks, I'll address this if I do a v3. You meant the removal of -pg,
right? For the EXPORT_SYMBOL() stuff (and other symbols), I'm not sure
whether I'll add an #ifdef maze, hoist a static function into a .h file,
or just make another minier implementation of the necessary functions.
Each approach has a pitfall.

> > +DECLARE_VVAR_SINGLE(640, struct vdso_rng_data, _vdso_rng_data)
> ...
> > +#define __vdso_rng_data (VVAR(_vdso_rng_data))
> > +
> > +static __always_inline const struct vdso_rng_data *__arch_get_vdso_rng_data(void)
> > +{
> > +	return &__vdso_rng_data;
> > +}
> 
> That's not working with time name spaces.

> > +static __always_inline ssize_t
> > +__cvdso_getrandom(void *opaque_state, void *buffer, size_t len, unsigned int flags)
> > +{
> > +	struct getrandom_state *state = opaque_state;
> > +	const struct vdso_rng_data *rng_info = __arch_get_vdso_rng_data();
> 
> This gives you vvar__vdso_rng_data and that points to the VVAR page at
> offset 640. That works up to the point where a task is part of a
> non-root time name space.
> 
> The kernel side mapping (the one which is updated) looks like this:
> 
>     VVAR_PAGE
>     VIRT_CLOCK_PAGE[S]
>     TIMENS_PAGE
> 
> If time namespaces are disabled or the task is in the root time
> namespace then the user mapping is in the same order.
> 
> If the task is in the non-root time namespace, then the user mapping is:
> 
>     TIMENS_PAGE
>     VIRT_CLOCK_PAGE[S]
>     VVAR_PAGE
> 
> So your user space looks at offset 640 in the TIMENS_PAGE, which has
> rand_data->ready and rand_data->generation == 0 forever.
> 
> See the comment above timens_setup_vdso_data() and look at the way how
> e.g. __cvdso_time_data() deals with that.

Ahhh, bingo! Thanks a lot for that. I couldn't quite grok before what
was happening with the timens stuff, but I think I get it now. When a
process is made in a timens, these pages are mapped differently, so that
the timens is in the same place as the init ns page would be. That's
clever. So I need to figure out some way to make __arch_get_vdso_rng_
data() always return the address of VVAR_PAGE, even when it's been
scooted down... I guess this means checking a bit in what's normally in
the vvar slot, and if it's a timens one, then loading the one that it's
in the timens slot, since that'll be the vvar one. Maybe that'll do it.

> VDSO hacking is special and not a sunday evening project. :)

While initially a somewhat bewildering maze, it's a rather fun puzzle.

Jason

On Tue, Aug 02, 2022 at 01:41:58AM +0200, Jason A. Donenfeld wrote:
> Hi Thomas,
> 
> On Mon, Aug 01, 2022 at 10:48:56PM +0200, Thomas Gleixner wrote:
> > On Sun, Jul 31 2022 at 03:31, Jason A. Donenfeld wrote:
> > You clearly forgot to tell people that they need a special config to
> > make this compile.
> 
> As I wrote in my patch body:
> 
> | The actual place that has the most work to do is in all of the other
> | files. Most of the vDSO shared page infrastructure is centered around
> | gettimeofday, and so the main structs are all in arrays for different
> | timestamp types, and attached to time namespaces, and so forth. I've
> | done the best I could to add onto this in an unintrusive way, but you'll
> | notice almost immediately from glancing at the code that it still needs
> | some untangling work. This also only works on x86 at the moment. I could
> | certainly use a hand with this part.
> 
> So I'm not surprised other things are screwed up. This works well in my
> test harness, indeed, but I imagine there are lots of fiddly bits like
> that to work out. I wanted to send an RFC to elicit comments on the idea
> and API before moving forward, as I have a strong sense this is one of
> those "90% 10%" things, where 10% of the details take 90% of the time.
> 
> Also, I haven't hooked up vdso32 yet.

Just to add, your "special config", "defconfig" remarks and such don't
strike me as very accurate. I had forgotten until a second ago that I'm
actually running this on my laptop's kernel, which is a fairly normal
"desktop distro" kernel with modules and lots of bloat turned on. So
c'mon now... the thing does work.

With that said, I've taken a stab at the various build, symbol, and
timens things you pointed out (thanks for that), and that's sitting now
in a branch, and will be part of a v3 if I ever post a v3:

https://git.zx2c4.com/linux-rng/commit/?h=jd/vdso

That pointer arithmetic around the timens stuff might not be super duper
appealing; I could add a symbol and have the linker resolve its location
and such. But also I wasn't keen on adding a symbol to a piece of data
that's not really there. So instead I calculate that offset from the
vdso_data and timens_vdso_data symbols.

By the way, in writing a test for that, I thought it was interesting
that CLONE_NEWTIME requires a new process, rather than just an execve.
You don't want to do it immediately, because that'd involve a
potentially racy remapping of the vvar pages. But at the very least it
could have been done on execve, right? Since all the maps are thrown out
then.

Jason