1. 06 Apr, 2022 1 commit
    • Jason A. Donenfeld's avatar
      random: do not allow user to keep crng key around on stack · aba120cc
      Jason A. Donenfeld authored
      The fast key erasure RNG design relies on the key that's used to be used
      and then discarded. We do this, making judicious use of
      memzero_explicit().  However, reads to /dev/urandom and calls to
      getrandom() involve a copy_to_user(), and userspace can use FUSE or
      userfaultfd, or make a massive call, dynamically remap memory addresses
      as it goes, and set the process priority to idle, in order to keep a
      kernel stack alive indefinitely. By probing
      /proc/sys/kernel/random/entropy_avail to learn when the crng key is
      refreshed, a malicious userspace could mount this attack every 5 minutes
      thereafter, breaking the crng's forward secrecy.
      
      In order to fix this, we just overwrite the stack's key with the first
      32 bytes of the "free" fast key erasure output. If we're returning <= 32
      bytes to the user, then we can still return those bytes directly, so
      that short reads don't become slower. And for long reads, the difference
      is hopefully lost in the amortization, so it doesn't change much, with
      that amortization helping variously for medium reads.
      
      We don't need to do this for get_random_bytes() and the various
      kernel-space callers, and later, if we ever switch to always batching,
      this won't be necessary either, so there's no need to change the API of
      these functions.
      
      Cc: Theodore Ts'o <tytso@mit.edu>
      Reviewed-by: default avatarJann Horn <jannh@google.com>
      Fixes: c92e040d ("random: add backtracking protection to the CRNG")
      Fixes: 186873c5 ("random: use simpler fast key erasure flow on per-cpu keys")
      Signed-off-by: default avatarJason A. Donenfeld <Jason@zx2c4.com>
      aba120cc
  2. 05 Apr, 2022 1 commit
    • Jason A. Donenfeld's avatar
      random: opportunistically initialize on /dev/urandom reads · 48bff105
      Jason A. Donenfeld authored
      In 6f98a4bf ("random: block in /dev/urandom"), we tried to make a
      successful try_to_generate_entropy() call *required* if the RNG was not
      already initialized. Unfortunately, weird architectures and old
      userspaces combined in TCG test harnesses, making that change still not
      realistic, so it was reverted in 0313bc27 ("Revert "random: block in
      /dev/urandom"").
      
      However, rather than making a successful try_to_generate_entropy() call
      *required*, we can instead make it *best-effort*.
      
      If try_to_generate_entropy() fails, it fails, and nothing changes from
      the current behavior. If it succeeds, then /dev/urandom becomes safe to
      use for free. This way, we don't risk the regression potential that led
      to us reverting the required-try_to_generate_entropy() call before.
      
      Practically speaking, this means that at least on x86, /dev/urandom
      becomes safe. Probably other architectures with working cycle counters
      will also become safe. And architectures with slow or broken cycle
      counters at least won't be affected at all by this change.
      
      So it may not be the glorious "all things are unified!" change we were
      hoping for initially, but practically speaking, it makes a positive
      impact.
      
      Cc: Theodore Ts'o <tytso@mit.edu>
      Cc: Dominik Brodowski <linux@dominikbrodowski.net>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarJason A. Donenfeld <Jason@zx2c4.com>
      48bff105
  3. 04 Apr, 2022 1 commit
    • Jan Varho's avatar
      random: do not split fast init input in add_hwgenerator_randomness() · 527a9867
      Jan Varho authored
      add_hwgenerator_randomness() tries to only use the required amount of input
      for fast init, but credits all the entropy, rather than a fraction of
      it. Since it's hard to determine how much entropy is left over out of a
      non-unformly random sample, either give it all to fast init or credit
      it, but don't attempt to do both. In the process, we can clean up the
      injection code to no longer need to return a value.
      Signed-off-by: default avatarJan Varho <jan.varho@gmail.com>
      [Jason: expanded commit message]
      Fixes: 73c7733f ("random: do not throw away excess input to crng_fast_load")
      Cc: stable@vger.kernel.org # 5.17+, requires af704c85Signed-off-by: default avatarJason A. Donenfeld <Jason@zx2c4.com>
      527a9867
  4. 03 Apr, 2022 8 commits
  5. 02 Apr, 2022 29 commits