linux.git/include/linux/random.h, branch v5.18-rc4

Revert "random: block in /dev/urandom"

2022-03-22T16:17:20+00:00

This reverts commit 6f98a4bfee72c22f50aedb39fb761567969865fe.

It turns out we still can't do this.  Way too many platforms that don't
have any real source of randomness at boot and no jitter entropy because
they don't even have a cycle counter.

As reported by Guenter Roeck:

 "This causes a large number of qemu boot test failures for various
  architectures (arm, m68k, microblaze, sparc32, xtensa are the ones I
  observed).

  Common denominator is that boot hangs at 'Saving random seed:'"

This isn't hugely unexpected - we tried it, it failed, so now we'll
revert it.

Link: https://lore.kernel.org/all/20220322155820.GA1745955@roeck-us.net/
Reported-and-bisected-by: Guenter Roeck 
Cc: Jason Donenfeld 
Signed-off-by: Linus Torvalds

random: provide notifier for VM fork

2022-03-13T01:00:56+00:00

Drivers such as WireGuard need to learn when VMs fork in order to clear
sessions. This commit provides a simple notifier_block for that, with a
register and unregister function. When no VM fork detection is compiled
in, this turns into a no-op, similar to how the power notifier works.

Cc: Dominik Brodowski 
Cc: Theodore Ts'o 
Reviewed-by: Greg Kroah-Hartman 
Signed-off-by: Jason A. Donenfeld

random: replace custom notifier chain with standard one

2022-03-13T01:00:56+00:00

We previously rolled our own randomness readiness notifier, which only
has two users in the whole kernel. Replace this with a more standard
atomic notifier block that serves the same purpose with less code. Also
unexport the symbols, because no modules use it, only unconditional
builtins. The only drawback is that it's possible for a notification
handler returning the "stop" code to prevent further processing, but
given that there are only two users, and that we're unexporting this
anyway, that doesn't seem like a significant drawback for the
simplification we receive here.

Cc: Greg Kroah-Hartman 
Cc: Theodore Ts'o 
Reviewed-by: Dominik Brodowski 
Signed-off-by: Jason A. Donenfeld

random: do not export add_vmfork_randomness() unless needed

2022-03-13T01:00:56+00:00

Since add_vmfork_randomness() is only called from vmgenid.o, we can
guard it in CONFIG_VMGENID, similarly to how we do with
add_disk_randomness() and CONFIG_BLOCK. If we ever have multiple things
calling into add_vmfork_randomness(), we can add another shared Kconfig
symbol for that, but for now, this is good enough. Even though
add_vmfork_randomess() is a pretty small function, removing it means
that there are only calls to crng_reseed(false) and none to
crng_reseed(true), which means the compiler can constant propagate the
false, removing branches from crng_reseed() and its descendants.

Additionally, we don't even need the symbol to be exported if
CONFIG_VMGENID is not a module, so conditionalize that too.

Cc: Dominik Brodowski 
Cc: Theodore Ts'o 
Signed-off-by: Jason A. Donenfeld

random: add mechanism for VM forks to reinitialize crng

2022-03-13T01:00:56+00:00

When a VM forks, we must immediately mix in additional information to
the stream of random output so that two forks or a rollback don't
produce the same stream of random numbers, which could have catastrophic
cryptographic consequences. This commit adds a simple API, add_vmfork_
randomness(), for that, by force reseeding the crng.

This has the added benefit of also draining the entropy pool and setting
its timer back, so that any old entropy that was there prior -- which
could have already been used by a different fork, or generally gone
stale -- does not contribute to the accounting of the next 256 bits.

Cc: Dominik Brodowski 
Cc: Theodore Ts'o 
Cc: Jann Horn 
Cc: Eric Biggers 
Reviewed-by: Ard Biesheuvel 
Signed-off-by: Jason A. Donenfeld

random: block in /dev/urandom

2022-03-13T01:00:55+00:00

This topic has come up countless times, and usually doesn't go anywhere.
This time I thought I'd bring it up with a slightly narrower focus,
updated for some developments over the last three years: we finally can
make /dev/urandom always secure, in light of the fact that our RNG is
now always seeded.

Ever since Linus' 50ee7529ec45 ("random: try to actively add entropy
rather than passively wait for it"), the RNG does a haveged-style jitter
dance around the scheduler, in order to produce entropy (and credit it)
for the case when we're stuck in wait_for_random_bytes(). How ever you
feel about the Linus Jitter Dance is beside the point: it's been there
for three years and usually gets the RNG initialized in a second or so.

As a matter of fact, this is what happens currently when people use
getrandom(). It's already there and working, and most people have been
using it for years without realizing.

So, given that the kernel has grown this mechanism for seeding itself
from nothing, and that this procedure happens pretty fast, maybe there's
no point any longer in having /dev/urandom give insecure bytes. In the
past we didn't want the boot process to deadlock, which was
understandable. But now, in the worst case, a second goes by, and the
problem is resolved. It seems like maybe we're finally at a point when
we can get rid of the infamous "urandom read hole".

The one slight drawback is that the Linus Jitter Dance relies on random_
get_entropy() being implemented. The first lines of try_to_generate_
entropy() are:

	stack.now = random_get_entropy();
	if (stack.now == random_get_entropy())
		return;

On most platforms, random_get_entropy() is simply aliased to get_cycles().
The number of machines without a cycle counter or some other
implementation of random_get_entropy() in 2022, which can also run a
mainline kernel, and at the same time have a both broken and out of date
userspace that relies on /dev/urandom never blocking at boot is thought
to be exceedingly low. And to be clear: those museum pieces without
cycle counters will continue to run Linux just fine, and even
/dev/urandom will be operable just like before; the RNG just needs to be
seeded first through the usual means, which should already be the case
now.

On systems that really do want unseeded randomness, we already offer
getrandom(GRND_INSECURE), which is in use by, e.g., systemd for seeding
their hash tables at boot. Nothing in this commit would affect
GRND_INSECURE, and it remains the means of getting those types of random
numbers.

This patch goes a long way toward eliminating a long overdue userspace
crypto footgun. After several decades of endless user confusion, we will
finally be able to say, "use any single one of our random interfaces and
you'll be fine. They're all the same. It doesn't matter." And that, I
think, is really something. Finally all of those blog posts and
disagreeing forums and contradictory articles will all become correct
about whatever they happened to recommend, and along with it, a whole
class of vulnerabilities eliminated.

With very minimal downside, we're finally in a position where we can
make this change.

Cc: Dinh Nguyen 
Cc: Nick Hu 
Cc: Max Filippov 
Cc: Palmer Dabbelt 
Cc: David S. Miller 
Cc: Yoshinori Sato 
Cc: Michal Simek 
Cc: Borislav Petkov 
Cc: Guo Ren 
Cc: Geert Uytterhoeven 
Cc: Joshua Kinard 
Cc: David Laight 
Cc: Dominik Brodowski 
Cc: Eric Biggers 
Cc: Ard Biesheuvel 
Cc: Arnd Bergmann 
Cc: Thomas Gleixner 
Cc: Andy Lutomirski 
Cc: Kees Cook 
Cc: Lennart Poettering 
Cc: Konstantin Ryabitsev 
Cc: Linus Torvalds 
Cc: Greg Kroah-Hartman 
Cc: Theodore Ts'o 
Signed-off-by: Jason A. Donenfeld

random: clear fast pool, crng, and batches in cpuhp bring up

2022-02-21T20:14:21+00:00

For the irq randomness fast pool, rather than having to use expensive
atomics, which were visibly the most expensive thing in the entire irq
handler, simply take care of the extreme edge case of resetting count to
zero in the cpuhp online handler, just after workqueues have been
reenabled. This simplifies the code a bit and lets us use vanilla
variables rather than atomics, and performance should be improved.

As well, very early on when the CPU comes up, while interrupts are still
disabled, we clear out the per-cpu crng and its batches, so that it
always starts with fresh randomness.

Cc: Thomas Gleixner 
Cc: Peter Zijlstra 
Cc: Theodore Ts'o 
Cc: Sultan Alsawaf 
Cc: Dominik Brodowski 
Acked-by: Sebastian Andrzej Siewior 
Signed-off-by: Jason A. Donenfeld

random: pull add_hwgenerator_randomness() declaration into random.h

2022-02-21T20:14:21+00:00

add_hwgenerator_randomness() is a function implemented and documented
inside of random.c. It is the way that hardware RNGs push data into it.
Therefore, it should be declared in random.h. Otherwise sparse complains
with:

random.c:1137:6: warning: symbol 'add_hwgenerator_randomness' was not declared. Should it be static?

The alternative would be to include hw_random.h into random.c, but that
wouldn't really be good for anything except slowing down compile time.

Cc: Matt Mackall 
Cc: Theodore Ts'o 
Acked-by: Herbert Xu 
Reviewed-by: Eric Biggers 
Reviewed-by: Dominik Brodowski 
Signed-off-by: Jason A. Donenfeld

random: remove useless header comment

2022-02-21T20:14:04+00:00

This really adds nothing at all useful.

Cc: Theodore Ts'o 
Reviewed-by: Dominik Brodowski 
Reviewed-by: Eric Biggers 
Signed-off-by: Jason A. Donenfeld

random: make more consistent use of integer types

2022-02-21T20:13:54+00:00

We've been using a flurry of int, unsigned int, size_t, and ssize_t.
Let's unify all of this into size_t where it makes sense, as it does in
most places, and leave ssize_t for return values with possible errors.

In addition, keeping with the convention of other functions in this
file, functions that are dealing with raw bytes now take void *
consistently instead of a mix of that and u8 *, because much of the time
we're actually passing some other structure that is then interpreted as
bytes by the function.

We also take the opportunity to fix the outdated and incorrect comment
in get_random_bytes_arch().

Cc: Theodore Ts'o 
Reviewed-by: Dominik Brodowski 
Reviewed-by: Jann Horn 
Reviewed-by: Eric Biggers 
Signed-off-by: Jason A. Donenfeld