1. 18 May, 2022 7 commits
    • Jason A. Donenfeld's avatar
      random: move initialization out of reseeding hot path · 68c9c8b1
      Jason A. Donenfeld authored
      Initialization happens once -- by way of credit_init_bits() -- and then
      it never happens again. Therefore, it doesn't need to be in
      crng_reseed(), which is a hot path that is called multiple times. It
      also doesn't make sense to have there, as initialization activity is
      better associated with initialization routines.
      
      After the prior commit, crng_reseed() now won't be called by multiple
      concurrent callers, which means that we can safely move the
      "finialize_init" logic into crng_init_bits() unconditionally.
      Reviewed-by: default avatarDominik Brodowski <linux@dominikbrodowski.net>
      Signed-off-by: default avatarJason A. Donenfeld <Jason@zx2c4.com>
      68c9c8b1
    • Jason A. Donenfeld's avatar
      random: avoid initializing twice in credit race · fed7ef06
      Jason A. Donenfeld authored
      Since all changes of crng_init now go through credit_init_bits(), we can
      fix a long standing race in which two concurrent callers of
      credit_init_bits() have the new bit count >= some threshold, but are
      doing so with crng_init as a lower threshold, checked outside of a lock,
      resulting in crng_reseed() or similar being called twice.
      
      In order to fix this, we can use the original cmpxchg value of the bit
      count, and only change crng_init when the bit count transitions from
      below a threshold to meeting the threshold.
      Reviewed-by: default avatarDominik Brodowski <linux@dominikbrodowski.net>
      Signed-off-by: default avatarJason A. Donenfeld <Jason@zx2c4.com>
      fed7ef06
    • Jason A. Donenfeld's avatar
      random: use symbolic constants for crng_init states · e3d2c5e7
      Jason A. Donenfeld authored
      crng_init represents a state machine, with three states, and various
      rules for transitions. For the longest time, we've been managing these
      with "0", "1", and "2", and expecting people to figure it out. To make
      the code more obvious, replace these with proper enum values
      representing the transition, and then redocument what each of these
      states mean.
      Reviewed-by: default avatarDominik Brodowski <linux@dominikbrodowski.net>
      Cc: Joe Perches <joe@perches.com>
      Signed-off-by: default avatarJason A. Donenfeld <Jason@zx2c4.com>
      e3d2c5e7
    • Jason A. Donenfeld's avatar
      random32: use real rng for non-deterministic randomness · d4150779
      Jason A. Donenfeld authored
      random32.c has two random number generators in it: one that is meant to
      be used deterministically, with some predefined seed, and one that does
      the same exact thing as random.c, except does it poorly. The first one
      has some use cases. The second one no longer does and can be replaced
      with calls to random.c's proper random number generator.
      
      The relatively recent siphash-based bad random32.c code was added in
      response to concerns that the prior random32.c was too deterministic.
      Out of fears that random.c was (at the time) too slow, this code was
      anonymously contributed. Then out of that emerged a kind of shadow
      entropy gathering system, with its own tentacles throughout various net
      code, added willy nilly.
      
      Stop👏making👏bespoke👏random👏number👏generators👏.
      
      Fortunately, recent advances in random.c mean that we can stop playing
      with this sketchiness, and just use get_random_u32(), which is now fast
      enough. In micro benchmarks using RDPMC, I'm seeing the same median
      cycle count between the two functions, with the mean being _slightly_
      higher due to batches refilling (which we can optimize further need be).
      However, when doing *real* benchmarks of the net functions that actually
      use these random numbers, the mean cycles actually *decreased* slightly
      (with the median still staying the same), likely because the additional
      prandom code means icache misses and complexity, whereas random.c is
      generally already being used by something else nearby.
      
      The biggest benefit of this is that there are many users of prandom who
      probably should be using cryptographically secure random numbers. This
      makes all of those accidental cases become secure by just flipping a
      switch. Later on, we can do a tree-wide cleanup to remove the static
      inline wrapper functions that this commit adds.
      
      There are also some low-ish hanging fruits for making this even faster
      in the future: a get_random_u16() function for use in the networking
      stack will give a 2x performance boost there, using SIMD for ChaCha20
      will let us compute 4 or 8 or 16 blocks of output in parallel, instead
      of just one, giving us large buffers for cheap, and introducing a
      get_random_*_bh() function that assumes irqs are already disabled will
      shave off a few cycles for ordinary calls. These are things we can chip
      away at down the road.
      Acked-by: default avatarJakub Kicinski <kuba@kernel.org>
      Acked-by: default avatarTheodore Ts'o <tytso@mit.edu>
      Signed-off-by: default avatarJason A. Donenfeld <Jason@zx2c4.com>
      d4150779
    • Jason A. Donenfeld's avatar
      siphash: use one source of truth for siphash permutations · e73aaae2
      Jason A. Donenfeld authored
      The SipHash family of permutations is currently used in three places:
      
      - siphash.c itself, used in the ordinary way it was intended.
      - random32.c, in a construction from an anonymous contributor.
      - random.c, as part of its fast_mix function.
      
      Each one of these places reinvents the wheel with the same C code, same
      rotation constants, and same symmetry-breaking constants.
      
      This commit tidies things up a bit by placing macros for the
      permutations and constants into siphash.h, where each of the three .c
      users can access them. It also leaves a note dissuading more users of
      them from emerging.
      Signed-off-by: default avatarJason A. Donenfeld <Jason@zx2c4.com>
      e73aaae2
    • Jason A. Donenfeld's avatar
      random: help compiler out with fast_mix() by using simpler arguments · 791332b3
      Jason A. Donenfeld authored
      Now that fast_mix() has more than one caller, gcc no longer inlines it.
      That's fine. But it also doesn't handle the compound literal argument we
      pass it very efficiently, nor does it handle the loop as well as it
      could. So just expand the code to spell out this function so that it
      generates the same code as it did before. Performance-wise, this now
      behaves as it did before the last commit. The difference in actual code
      size on x86 is 45 bytes, which is less than a cache line.
      Signed-off-by: default avatarJason A. Donenfeld <Jason@zx2c4.com>
      791332b3
    • Jason A. Donenfeld's avatar
      random: do not use input pool from hard IRQs · e3e33fc2
      Jason A. Donenfeld authored
      Years ago, a separate fast pool was added for interrupts, so that the
      cost associated with taking the input pool spinlocks and mixing into it
      would be avoided in places where latency is critical. However, one
      oversight was that add_input_randomness() and add_disk_randomness()
      still sometimes are called directly from the interrupt handler, rather
      than being deferred to a thread. This means that some unlucky interrupts
      will be caught doing a blake2s_compress() call and potentially spinning
      on input_pool.lock, which can also be taken by unprivileged users by
      writing into /dev/urandom.
      
      In order to fix this, add_timer_randomness() now checks whether it is
      being called from a hard IRQ and if so, just mixes into the per-cpu IRQ
      fast pool using fast_mix(), which is much faster and can be done
      lock-free. A nice consequence of this, as well, is that it means hard
      IRQ context FPU support is likely no longer useful.
      
      The entropy estimation algorithm used by add_timer_randomness() is also
      somewhat different than the one used for add_interrupt_randomness(). The
      former looks at deltas of deltas of deltas, while the latter just waits
      for 64 interrupts for one bit or for one second since the last bit. In
      order to bridge these, and since add_interrupt_randomness() runs after
      an add_timer_randomness() that's called from hard IRQ, we add to the
      fast pool credit the related amount, and then subtract one to account
      for add_interrupt_randomness()'s contribution.
      
      A downside of this, however, is that the num argument is potentially
      attacker controlled, which puts a bit more pressure on the fast_mix()
      sponge to do more than it's really intended to do. As a mitigating
      factor, the first 96 bits of input aren't attacker controlled (a cycle
      counter followed by zeros), which means it's essentially two rounds of
      siphash rather than one, which is somewhat better. It's also not that
      much different from add_interrupt_randomness()'s use of the irq stack
      instruction pointer register.
      
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Filipe Manana <fdmanana@suse.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Theodore Ts'o <tytso@mit.edu>
      Signed-off-by: default avatarJason A. Donenfeld <Jason@zx2c4.com>
      e3e33fc2
  2. 15 May, 2022 2 commits
    • Jason A. Donenfeld's avatar
      random: order timer entropy functions below interrupt functions · a4b5c26b
      Jason A. Donenfeld authored
      There are no code changes here; this is just a reordering of functions,
      so that in subsequent commits, the timer entropy functions can call into
      the interrupt ones.
      Signed-off-by: default avatarJason A. Donenfeld <Jason@zx2c4.com>
      a4b5c26b
    • Jason A. Donenfeld's avatar
      random: do not pretend to handle premature next security model · e85c0fc1
      Jason A. Donenfeld authored
      Per the thread linked below, "premature next" is not considered to be a
      realistic threat model, and leads to more serious security problems.
      
      "Premature next" is the scenario in which:
      
      - Attacker compromises the current state of a fully initialized RNG via
        some kind of infoleak.
      - New bits of entropy are added directly to the key used to generate the
        /dev/urandom stream, without any buffering or pooling.
      - Attacker then, somehow having read access to /dev/urandom, samples RNG
        output and brute forces the individual new bits that were added.
      - Result: the RNG never "recovers" from the initial compromise, a
        so-called violation of what academics term "post-compromise security".
      
      The usual solutions to this involve some form of delaying when entropy
      gets mixed into the crng. With Fortuna, this involves multiple input
      buckets. With what the Linux RNG was trying to do prior, this involves
      entropy estimation.
      
      However, by delaying when entropy gets mixed in, it also means that RNG
      compromises are extremely dangerous during the window of time before
      the RNG has gathered enough entropy, during which time nonces may become
      predictable (or repeated), ephemeral keys may not be secret, and so
      forth. Moreover, it's unclear how realistic "premature next" is from an
      attack perspective, if these attacks even make sense in practice.
      
      Put together -- and discussed in more detail in the thread below --
      these constitute grounds for just doing away with the current code that
      pretends to handle premature next. I say "pretends" because it wasn't
      doing an especially great job at it either; should we change our mind
      about this direction, we would probably implement Fortuna to "fix" the
      "problem", in which case, removing the pretend solution still makes
      sense.
      
      This also reduces the crng reseed period from 5 minutes down to 1
      minute. The rationale from the thread might lead us toward reducing that
      even further in the future (or even eliminating it), but that remains a
      topic of a future commit.
      
      At a high level, this patch changes semantics from:
      
          Before: Seed for the first time after 256 "bits" of estimated
          entropy have been accumulated since the system booted. Thereafter,
          reseed once every five minutes, but only if 256 new "bits" have been
          accumulated since the last reseeding.
      
          After: Seed for the first time after 256 "bits" of estimated entropy
          have been accumulated since the system booted. Thereafter, reseed
          once every minute.
      
      Most of this patch is renaming and removing: POOL_MIN_BITS becomes
      POOL_INIT_BITS, credit_entropy_bits() becomes credit_init_bits(),
      crng_reseed() loses its "force" parameter since it's now always true,
      the drain_entropy() function no longer has any use so it's removed,
      entropy estimation is skipped if we've already init'd, the various
      notifiers for "low on entropy" are now only active prior to init, and
      finally, some documentation comments are cleaned up here and there.
      
      Link: https://lore.kernel.org/lkml/YmlMGx6+uigkGiZ0@zx2c4.com/
      Cc: Theodore Ts'o <tytso@mit.edu>
      Cc: Nadia Heninger <nadiah@cs.ucsd.edu>
      Cc: Tom Ristenpart <ristenpart@cornell.edu>
      Reviewed-by: default avatarEric Biggers <ebiggers@google.com>
      Signed-off-by: default avatarJason A. Donenfeld <Jason@zx2c4.com>
      e85c0fc1
  3. 13 May, 2022 23 commits
    • Jason A. Donenfeld's avatar
      random: use first 128 bits of input as fast init · 5c3b747e
      Jason A. Donenfeld authored
      Before, the first 64 bytes of input, regardless of how entropic it was,
      would be used to mutate the crng base key directly, and none of those
      bytes would be credited as having entropy. Then 256 bits of credited
      input would be accumulated, and only then would the rng transition from
      the earlier "fast init" phase into being actually initialized.
      
      The thinking was that by mixing and matching fast init and real init, an
      attacker who compromised the fast init state, considered easy to do
      given how little entropy might be in those first 64 bytes, would then be
      able to bruteforce bits from the actual initialization. By keeping these
      separate, bruteforcing became impossible.
      
      However, by not crediting potentially creditable bits from those first 64
      bytes of input, we delay initialization, and actually make the problem
      worse, because it means the user is drawing worse random numbers for a
      longer period of time.
      
      Instead, we can take the first 128 bits as fast init, and allow them to
      be credited, and then hold off on the next 128 bits until they've
      accumulated. This is still a wide enough margin to prevent bruteforcing
      the rng state, while still initializing much faster.
      
      Then, rather than trying to piecemeal inject into the base crng key at
      various points, instead just extract from the pool when we need it, for
      the crng_init==0 phase. Performance may even be better for the various
      inputs here, since there are likely more calls to mix_pool_bytes() then
      there are to get_random_bytes() during this phase of system execution.
      
      Since the preinit injection code is gone, bootloader randomness can then
      do something significantly more straight forward, removing the weird
      system_wq hack in hwgenerator randomness.
      
      Cc: Theodore Ts'o <tytso@mit.edu>
      Cc: Dominik Brodowski <linux@dominikbrodowski.net>
      Signed-off-by: default avatarJason A. Donenfeld <Jason@zx2c4.com>
      5c3b747e
    • Jason A. Donenfeld's avatar
      random: do not use batches when !crng_ready() · cbe89e5a
      Jason A. Donenfeld authored
      It's too hard to keep the batches synchronized, and pointless anyway,
      since in !crng_ready(), we're updating the base_crng key really often,
      where batching only hurts. So instead, if the crng isn't ready, just
      call into get_random_bytes(). At this stage nothing is performance
      critical anyhow.
      
      Cc: Theodore Ts'o <tytso@mit.edu>
      Reviewed-by: default avatarDominik Brodowski <linux@dominikbrodowski.net>
      Signed-off-by: default avatarJason A. Donenfeld <Jason@zx2c4.com>
      cbe89e5a
    • Jason A. Donenfeld's avatar
      random: mix in timestamps and reseed on system restore · b7b67d13
      Jason A. Donenfeld authored
      Since the RNG loses freshness with system suspend/hibernation, when we
      resume, immediately reseed using whatever data we can, which for this
      particular case is the various timestamps regarding system suspend time,
      in addition to more generally the RDSEED/RDRAND/RDTSC values that happen
      whenever the crng reseeds.
      
      On systems that suspend and resume automatically all the time -- such as
      Android -- we skip the reseeding on suspend resumption, since that could
      wind up being far too busy. This is the same trade-off made in
      WireGuard.
      
      In addition to reseeding upon resumption always mix into the pool these
      various stamps on every power notification event.
      
      Cc: Theodore Ts'o <tytso@mit.edu>
      Signed-off-by: default avatarJason A. Donenfeld <Jason@zx2c4.com>
      b7b67d13
    • Jason A. Donenfeld's avatar
      random: vary jitter iterations based on cycle counter speed · 78c768e6
      Jason A. Donenfeld authored
      Currently, we do the jitter dance if two consecutive reads to the cycle
      counter return different values. If they do, then we consider the cycle
      counter to be fast enough that one trip through the scheduler will yield
      one "bit" of credited entropy. If those two reads return the same value,
      then we assume the cycle counter is too slow to show meaningful
      differences.
      
      This methodology is flawed for a variety of reasons, one of which Eric
      posted a patch to fix in [1]. The issue that patch solves is that on a
      system with a slow counter, you might be [un]lucky and read the counter
      _just_ before it changes, so that the second cycle counter you read
      differs from the first, even though there's usually quite a large period
      of time in between the two. For example:
      
      | real time | cycle counter |
      | --------- | ------------- |
      | 3         | 5             |
      | 4         | 5             |
      | 5         | 5             |
      | 6         | 5             |
      | 7         | 5             | <--- a
      | 8         | 6             | <--- b
      | 9         | 6             | <--- c
      
      If we read the counter at (a) and compare it to (b), we might be fooled
      into thinking that it's a fast counter, when in reality it is not. The
      solution in [1] is to also compare counter (b) to counter (c), on the
      theory that if the counter is _actually_ slow, and (a)!=(b), then
      certainly (b)==(c).
      
      This helps solve this particular issue, in one sense, but in another
      sense, it mostly functions to disallow jitter entropy on these systems,
      rather than simply taking more samples in that case.
      
      Instead, this patch takes a different approach. Right now we assume that
      a difference in one set of consecutive samples means one "bit" of
      credited entropy per scheduler trip. We can extend this so that a
      difference in two sets of consecutive samples means one "bit" of
      credited entropy per /two/ scheduler trips, and three for three, and
      four for four. In other words, we can increase the amount of jitter
      "work" we require for each "bit", depending on how slow the cycle
      counter is.
      
      So this patch takes whole bunch of samples, sees how many of them are
      different, and divides to find the amount of work required per "bit",
      and also requires that at least some minimum of them are different in
      order to attempt any jitter entropy.
      
      Note that this approach is still far from perfect. It's not a real
      statistical estimate on how much these samples vary; it's not a
      real-time analysis of the relevant input data. That remains a project
      for another time. However, it makes the same (partly flawed) assumptions
      as the code that's there now, so it's probably not worse than the status
      quo, and it handles the issue Eric mentioned in [1]. But, again, it's
      probably a far cry from whatever a really robust version of this would
      be.
      
      [1] https://lore.kernel.org/lkml/20220421233152.58522-1-ebiggers@kernel.org/
          https://lore.kernel.org/lkml/20220421192939.250680-1-ebiggers@kernel.org/
      
      Cc: Eric Biggers <ebiggers@google.com>
      Cc: Theodore Ts'o <tytso@mit.edu>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarJason A. Donenfeld <Jason@zx2c4.com>
      78c768e6
    • Jason A. Donenfeld's avatar
      random: insist on random_get_entropy() existing in order to simplify · 4b758eda
      Jason A. Donenfeld authored
      All platforms are now guaranteed to provide some value for
      random_get_entropy(). In case some bug leads to this not being so, we
      print a warning, because that indicates that something is really very
      wrong (and likely other things are impacted too). This should never be
      hit, but it's a good and cheap way of finding out if something ever is
      problematic.
      
      Since we now have viable fallback code for random_get_entropy() on all
      platforms, which is, in the worst case, not worse than jiffies, we can
      count on getting the best possible value out of it. That means there's
      no longer a use for using jiffies as entropy input. It also means we no
      longer have a reason for doing the round-robin register flow in the IRQ
      handler, which was always of fairly dubious value.
      
      Instead we can greatly simplify the IRQ handler inputs and also unify
      the construction between 64-bits and 32-bits. We now collect the cycle
      counter and the return address, since those are the two things that
      matter. Because the return address and the irq number are likely
      related, to the extent we mix in the irq number, we can just xor it into
      the top unchanging bytes of the return address, rather than the bottom
      changing bytes of the cycle counter as before. Then, we can do a fixed 2
      rounds of SipHash/HSipHash. Finally, we use the same construction of
      hashing only half of the [H]SipHash state on 32-bit and 64-bit. We're
      not actually discarding any entropy, since that entropy is carried
      through until the next time. And more importantly, it lets us do the
      same sponge-like construction everywhere.
      
      Cc: Theodore Ts'o <tytso@mit.edu>
      Signed-off-by: default avatarJason A. Donenfeld <Jason@zx2c4.com>
      4b758eda
    • Jason A. Donenfeld's avatar
      xtensa: use fallback for random_get_entropy() instead of zero · e10e2f58
      Jason A. Donenfeld authored
      In the event that random_get_entropy() can't access a cycle counter or
      similar, falling back to returning 0 is really not the best we can do.
      Instead, at least calling random_get_entropy_fallback() would be
      preferable, because that always needs to return _something_, even
      falling back to jiffies eventually. It's not as though
      random_get_entropy_fallback() is super high precision or guaranteed to
      be entropic, but basically anything that's not zero all the time is
      better than returning zero all the time.
      
      This is accomplished by just including the asm-generic code like on
      other architectures, which means we can get rid of the empty stub
      function here.
      
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Acked-by: default avatarMax Filippov <jcmvbkbc@gmail.com>
      Signed-off-by: default avatarJason A. Donenfeld <Jason@zx2c4.com>
      e10e2f58
    • Jason A. Donenfeld's avatar
      sparc: use fallback for random_get_entropy() instead of zero · ac9756c7
      Jason A. Donenfeld authored
      In the event that random_get_entropy() can't access a cycle counter or
      similar, falling back to returning 0 is really not the best we can do.
      Instead, at least calling random_get_entropy_fallback() would be
      preferable, because that always needs to return _something_, even
      falling back to jiffies eventually. It's not as though
      random_get_entropy_fallback() is super high precision or guaranteed to
      be entropic, but basically anything that's not zero all the time is
      better than returning zero all the time.
      
      This is accomplished by just including the asm-generic code like on
      other architectures, which means we can get rid of the empty stub
      function here.
      
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: David S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarJason A. Donenfeld <Jason@zx2c4.com>
      ac9756c7
    • Jason A. Donenfeld's avatar
      um: use fallback for random_get_entropy() instead of zero · 9f13fb0c
      Jason A. Donenfeld authored
      In the event that random_get_entropy() can't access a cycle counter or
      similar, falling back to returning 0 is really not the best we can do.
      Instead, at least calling random_get_entropy_fallback() would be
      preferable, because that always needs to return _something_, even
      falling back to jiffies eventually. It's not as though
      random_get_entropy_fallback() is super high precision or guaranteed to
      be entropic, but basically anything that's not zero all the time is
      better than returning zero all the time.
      
      This is accomplished by just including the asm-generic code like on
      other architectures, which means we can get rid of the empty stub
      function here.
      
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Richard Weinberger <richard@nod.at>
      Cc: Anton Ivanov <anton.ivanov@cambridgegreys.com>
      Acked-by: default avatarJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: default avatarJason A. Donenfeld <Jason@zx2c4.com>
      9f13fb0c
    • Jason A. Donenfeld's avatar
      x86/tsc: Use fallback for random_get_entropy() instead of zero · 3bd4abc0
      Jason A. Donenfeld authored
      In the event that random_get_entropy() can't access a cycle counter or
      similar, falling back to returning 0 is suboptimal. Instead, fallback
      to calling random_get_entropy_fallback(), which isn't extremely high
      precision or guaranteed to be entropic, but is certainly better than
      returning zero all the time.
      
      If CONFIG_X86_TSC=n, then it's possible for the kernel to run on systems
      without RDTSC, such as 486 and certain 586, so the fallback code is only
      required for that case.
      
      As well, fix up both the new function and the get_cycles() function from
      which it was derived to use cpu_feature_enabled() rather than
      boot_cpu_has(), and use !IS_ENABLED() instead of #ifndef.
      Signed-off-by: default avatarJason A. Donenfeld <Jason@zx2c4.com>
      Reviewed-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: x86@kernel.org
      3bd4abc0
    • Jason A. Donenfeld's avatar
      nios2: use fallback for random_get_entropy() instead of zero · c04e7270
      Jason A. Donenfeld authored
      In the event that random_get_entropy() can't access a cycle counter or
      similar, falling back to returning 0 is really not the best we can do.
      Instead, at least calling random_get_entropy_fallback() would be
      preferable, because that always needs to return _something_, even
      falling back to jiffies eventually. It's not as though
      random_get_entropy_fallback() is super high precision or guaranteed to
      be entropic, but basically anything that's not zero all the time is
      better than returning zero all the time.
      
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Acked-by: default avatarDinh Nguyen <dinguyen@kernel.org>
      Signed-off-by: default avatarJason A. Donenfeld <Jason@zx2c4.com>
      c04e7270
    • Jason A. Donenfeld's avatar
      arm: use fallback for random_get_entropy() instead of zero · ff8a8f59
      Jason A. Donenfeld authored
      In the event that random_get_entropy() can't access a cycle counter or
      similar, falling back to returning 0 is really not the best we can do.
      Instead, at least calling random_get_entropy_fallback() would be
      preferable, because that always needs to return _something_, even
      falling back to jiffies eventually. It's not as though
      random_get_entropy_fallback() is super high precision or guaranteed to
      be entropic, but basically anything that's not zero all the time is
      better than returning zero all the time.
      
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Reviewed-by: default avatarRussell King (Oracle) <rmk+kernel@armlinux.org.uk>
      Signed-off-by: default avatarJason A. Donenfeld <Jason@zx2c4.com>
      ff8a8f59
    • Jason A. Donenfeld's avatar
      mips: use fallback for random_get_entropy() instead of just c0 random · 1c99c6a7
      Jason A. Donenfeld authored
      For situations in which we don't have a c0 counter register available,
      we've been falling back to reading the c0 "random" register, which is
      usually bounded by the amount of TLB entries and changes every other
      cycle or so. This means it wraps extremely often. We can do better by
      combining this fast-changing counter with a potentially slower-changing
      counter from random_get_entropy_fallback() in the more significant bits.
      This commit combines the two, taking into account that the changing bits
      are in a different bit position depending on the CPU model. In addition,
      we previously were falling back to 0 for ancient CPUs that Linux does
      not support anyway; remove that dead path entirely.
      
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Tested-by: default avatarMaciej W. Rozycki <macro@orcam.me.uk>
      Acked-by: default avatarThomas Bogendoerfer <tsbogend@alpha.franken.de>
      Signed-off-by: default avatarJason A. Donenfeld <Jason@zx2c4.com>
      1c99c6a7
    • Jason A. Donenfeld's avatar
      riscv: use fallback for random_get_entropy() instead of zero · 6d012386
      Jason A. Donenfeld authored
      In the event that random_get_entropy() can't access a cycle counter or
      similar, falling back to returning 0 is really not the best we can do.
      Instead, at least calling random_get_entropy_fallback() would be
      preferable, because that always needs to return _something_, even
      falling back to jiffies eventually. It's not as though
      random_get_entropy_fallback() is super high precision or guaranteed to
      be entropic, but basically anything that's not zero all the time is
      better than returning zero all the time.
      
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Paul Walmsley <paul.walmsley@sifive.com>
      Acked-by: default avatarPalmer Dabbelt <palmer@rivosinc.com>
      Reviewed-by: default avatarPalmer Dabbelt <palmer@rivosinc.com>
      Signed-off-by: default avatarJason A. Donenfeld <Jason@zx2c4.com>
      6d012386
    • Jason A. Donenfeld's avatar
      m68k: use fallback for random_get_entropy() instead of zero · 0f392c95
      Jason A. Donenfeld authored
      In the event that random_get_entropy() can't access a cycle counter or
      similar, falling back to returning 0 is really not the best we can do.
      Instead, at least calling random_get_entropy_fallback() would be
      preferable, because that always needs to return _something_, even
      falling back to jiffies eventually. It's not as though
      random_get_entropy_fallback() is super high precision or guaranteed to
      be entropic, but basically anything that's not zero all the time is
      better than returning zero all the time.
      
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Acked-by: default avatarGeert Uytterhoeven <geert@linux-m68k.org>
      Signed-off-by: default avatarJason A. Donenfeld <Jason@zx2c4.com>
      0f392c95
    • Jason A. Donenfeld's avatar
      timekeeping: Add raw clock fallback for random_get_entropy() · 1366992e
      Jason A. Donenfeld authored
      The addition of random_get_entropy_fallback() provides access to
      whichever time source has the highest frequency, which is useful for
      gathering entropy on platforms without available cycle counters. It's
      not necessarily as good as being able to quickly access a cycle counter
      that the CPU has, but it's still something, even when it falls back to
      being jiffies-based.
      
      In the event that a given arch does not define get_cycles(), falling
      back to the get_cycles() default implementation that returns 0 is really
      not the best we can do. Instead, at least calling
      random_get_entropy_fallback() would be preferable, because that always
      needs to return _something_, even falling back to jiffies eventually.
      It's not as though random_get_entropy_fallback() is super high precision
      or guaranteed to be entropic, but basically anything that's not zero all
      the time is better than returning zero all the time.
      
      Finally, since random_get_entropy_fallback() is used during extremely
      early boot when randomizing freelists in mm_init(), it can be called
      before timekeeping has been initialized. In that case there really is
      nothing we can do; jiffies hasn't even started ticking yet. So just give
      up and return 0.
      Suggested-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarJason A. Donenfeld <Jason@zx2c4.com>
      Reviewed-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Theodore Ts'o <tytso@mit.edu>
      1366992e
    • Jason A. Donenfeld's avatar
      openrisc: start CPU timer early in boot · 516dd4aa
      Jason A. Donenfeld authored
      In order to measure the boot process, the timer should be switched on as
      early in boot as possible. As well, the commit defines the get_cycles
      macro, like the previous patches in this series, so that generic code is
      aware that it's implemented by the platform, as is done on other archs.
      
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Jonas Bonn <jonas@southpole.se>
      Cc: Stefan Kristiansson <stefan.kristiansson@saunalahti.fi>
      Acked-by: default avatarStafford Horne <shorne@gmail.com>
      Reported-by: default avatarGuenter Roeck <linux@roeck-us.net>
      Signed-off-by: default avatarJason A. Donenfeld <Jason@zx2c4.com>
      516dd4aa
    • Jason A. Donenfeld's avatar
      powerpc: define get_cycles macro for arch-override · 40883583
      Jason A. Donenfeld authored
      PowerPC defines a get_cycles() function, but it does not do the usual
      `#define get_cycles get_cycles` dance, making it impossible for generic
      code to see if an arch-specific function was defined. While the
      get_cycles() ifdef is not currently used, the following timekeeping
      patch in this series will depend on the macro existing (or not existing)
      when defining random_get_entropy().
      
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Benjamin Herrenschmidt <benh@ozlabs.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Acked-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Signed-off-by: default avatarJason A. Donenfeld <Jason@zx2c4.com>
      40883583
    • Jason A. Donenfeld's avatar
      alpha: define get_cycles macro for arch-override · 1097710b
      Jason A. Donenfeld authored
      Alpha defines a get_cycles() function, but it does not do the usual
      `#define get_cycles get_cycles` dance, making it impossible for generic
      code to see if an arch-specific function was defined. While the
      get_cycles() ifdef is not currently used, the following timekeeping
      patch in this series will depend on the macro existing (or not existing)
      when defining random_get_entropy().
      
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Richard Henderson <rth@twiddle.net>
      Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
      Acked-by: default avatarMatt Turner <mattst88@gmail.com>
      Signed-off-by: default avatarJason A. Donenfeld <Jason@zx2c4.com>
      1097710b
    • Jason A. Donenfeld's avatar
      parisc: define get_cycles macro for arch-override · 8865bbe6
      Jason A. Donenfeld authored
      PA-RISC defines a get_cycles() function, but it does not do the usual
      `#define get_cycles get_cycles` dance, making it impossible for generic
      code to see if an arch-specific function was defined. While the
      get_cycles() ifdef is not currently used, the following timekeeping
      patch in this series will depend on the macro existing (or not existing)
      when defining random_get_entropy().
      
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Acked-by: default avatarHelge Deller <deller@gmx.de>
      Signed-off-by: default avatarJason A. Donenfeld <Jason@zx2c4.com>
      8865bbe6
    • Jason A. Donenfeld's avatar
      s390: define get_cycles macro for arch-override · 2e3df523
      Jason A. Donenfeld authored
      S390x defines a get_cycles() function, but it does not do the usual
      `#define get_cycles get_cycles` dance, making it impossible for generic
      code to see if an arch-specific function was defined. While the
      get_cycles() ifdef is not currently used, the following timekeeping
      patch in this series will depend on the macro existing (or not existing)
      when defining random_get_entropy().
      
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Vasily Gorbik <gor@linux.ibm.com>
      Cc: Alexander Gordeev <agordeev@linux.ibm.com>
      Cc: Christian Borntraeger <borntraeger@linux.ibm.com>
      Cc: Sven Schnelle <svens@linux.ibm.com>
      Acked-by: default avatarHeiko Carstens <hca@linux.ibm.com>
      Signed-off-by: default avatarJason A. Donenfeld <Jason@zx2c4.com>
      2e3df523
    • Jason A. Donenfeld's avatar
      ia64: define get_cycles macro for arch-override · 57c0900b
      Jason A. Donenfeld authored
      Itanium defines a get_cycles() function, but it does not do the usual
      `#define get_cycles get_cycles` dance, making it impossible for generic
      code to see if an arch-specific function was defined. While the
      get_cycles() ifdef is not currently used, the following timekeeping
      patch in this series will depend on the macro existing (or not existing)
      when defining random_get_entropy().
      
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarJason A. Donenfeld <Jason@zx2c4.com>
      57c0900b
    • Jason A. Donenfeld's avatar
      init: call time_init() before rand_initialize() · fe222a6c
      Jason A. Donenfeld authored
      Currently time_init() is called after rand_initialize(), but
      rand_initialize() makes use of the timer on various platforms, and
      sometimes this timer needs to be initialized by time_init() first. In
      order for random_get_entropy() to not return zero during early boot when
      it's potentially used as an entropy source, reverse the order of these
      two calls. The block doing random initialization was right before
      time_init() before, so changing the order shouldn't have any complicated
      effects.
      
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Reviewed-by: default avatarStafford Horne <shorne@gmail.com>
      Signed-off-by: default avatarJason A. Donenfeld <Jason@zx2c4.com>
      fe222a6c
    • Jason A. Donenfeld's avatar
      random: fix sysctl documentation nits · 069c4ea6
      Jason A. Donenfeld authored
      A semicolon was missing, and the almost-alphabetical-but-not ordering
      was confusing, so regroup these by category instead.
      Signed-off-by: default avatarJason A. Donenfeld <Jason@zx2c4.com>
      069c4ea6
  4. 08 May, 2022 8 commits