lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Fri, 27 Apr 2018 15:14:58 -0400
From:   "Theodore Y. Ts'o" <>
To:     "Jason A. Donenfeld" <>
Cc:     Christian Brauner <>,
        Sultan Alsawaf <>,
        LKML <>, Jann Horn <>
Subject: Re: Linux messages full of `random: get_random_u32 called from`

On Fri, Apr 27, 2018 at 05:38:52PM +0200, Jason A. Donenfeld wrote:
> Please correct me if I'm wrong, but my present understanding of this
> is that crng readiness used to be broken, meaning people would have a
> seeded rng without it actually being seeded. You fixed this bug, and
> now people are discovering that they don't have crng readiness during
> a late stage of their init, which is breaking all sorts of entirely
> reasonable and widely deployed userspaces.

I'd say the problem is a combination of some classes of x86 hardware
devices (so far I've mainly seen repurposed chromebooks and VM's that
don't have virtio-rng enabled) combined with some distributions that
could make themselves more amenable to platforms with minimal amounts
of entropy available to them during system startup.

> Sultan mentioned that his machine actually does trigger large
> quantities of interrupts. Is it possible that the entropy gathering
> algorithm has some issues, and Sultan's report points to a real bug
> here? Considering the crng readiness state hasn't been working until
> your recent fix, I suspect the actual entropy gathering code probably
> hasn't prompted too many bug reports, until now that is.

It's not clear when his machine is triggering the "large quantity of
interrupts".  Is it during the system startup, or after he's logged
into the machine?  I suspect what is going on is the Chromebook has
been engineered so that when it's idle, it doesn't issue any
interrupts at all --- which is a good thing from a power management
perspective.  So if nothing is actually _querying_ the SD Card reader,
it's not generating any interrupts.

This is a feature, and not a bug.  That being said, a laptop which
sends some number of interrupts as it receives, say, WiFi packets, and
a system which automatically starts looking for suitable access points
as soon as the machine is started gives us timing events which is not
easily available to an analyst sitting in Fort Meade, Maryland.  In
practice, that seems to be much more of the rule and not the
exception.  However, as laptops try to become much more sparing
interrupts to save power, then we either have to (a) be willing to
trust hardware random number generators available to the laptop,
and/or (b) change userspace to *wait* until after the user has logged
in to try to obtain cryptographic-graded randomness.

If you think there is an alternative besides those two, I'm all ears...

       	     	      	 	      	      - Ted

Powered by blists - more mailing lists