gitlab.arm.com will be in the maintainance mode on Wednesday June 29th 01:00 - 10:00 (UTC+1). Repositories is read only during the maintainance.

  • Linus Torvalds's avatar
    random: try to actively add entropy rather than passively wait for it · 50ee7529
    Linus Torvalds authored
    For 5.3 we had to revert a nice ext4 IO pattern improvement, because it
    caused a bootup regression due to lack of entropy at bootup together
    with arguably broken user space that was asking for secure random
    numbers when it really didn't need to.
    
    See commit 72dbcf72
    
     (Revert "ext4: make __ext4_get_inode_loc plug").
    
    This aims to solve the issue by actively generating entropy noise using
    the CPU cycle counter when waiting for the random number generator to
    initialize.  This only works when you have a high-frequency time stamp
    counter available, but that's the case on all modern x86 CPU's, and on
    most other modern CPU's too.
    
    What we do is to generate jitter entropy from the CPU cycle counter
    under a somewhat complex load: calling the scheduler while also
    guaranteeing a certain amount of timing noise by also triggering a
    timer.
    
    I'm sure we can tweak this, and that people will want to look at other
    alternatives, but there's been a number of papers written on jitter
    entropy, and this should really be fairly conservative by crediting one
    bit of entropy for every timer-induced jump in the cycle counter.  Not
    because the timer itself would be all that unpredictable, but because
    the interaction between the timer and the loop is going to be.
    
    Even if (and perhaps particularly if) the timer actually happens on
    another CPU, the cacheline interaction between the loop that reads the
    cycle counter and the timer itself firing is going to add perturbations
    to the cycle counter values that get mixed into the entropy pool.
    
    As Thomas pointed out, with a modern out-of-order CPU, even quite simple
    loops show a fair amount of hard-to-predict timing variability even in
    the absense of external interrupts.  But this tries to take that further
    by actually having a fairly complex interaction.
    
    This is not going to solve the entropy issue for architectures that have
    no CPU cycle counter, but it's not clear how (and if) that is solvable,
    and the hardware in question is largely starting to be irrelevant.  And
    by doing this we can at least avoid some of the even more contentious
    approaches (like making the entropy waiting time out in order to avoid
    the possibly unbounded waiting).
    
    Cc: Ahmed Darwish <darwish.07@gmail.com>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: Theodore Ts'o <tytso@mit.edu>
    Cc: Nicholas Mc Guire <hofrat@opentech.at>
    Cc: Andy Lutomirski <luto@kernel.org>
    Cc: Kees Cook <keescook@chromium.org>
    Cc: Willy Tarreau <w@1wt.eu>
    Cc: Alexander E. Patrakov <patrakov@gmail.com>
    Cc: Lennart Poettering <mzxreary@0pointer.de>
    Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
    50ee7529
random.c 72.9 KB