linux-kernel - Re: [PATCH 00/11] random: code cleanups

lists.openwall.net		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 linux-cve-announce 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]

Message-ID: <20131113060807.GA11394@thunk.org>
Date:	Wed, 13 Nov 2013 01:08:07 -0500
From:	Theodore Ts'o <tytso@....edu>
To:	Greg Price <price@....EDU>, "H. Peter Anvin" <hpa@...or.com>
Cc:	linux-kernel@...r.kernel.org, Jiri Kosina <jkosina@...e.cz>
Subject: Re: [PATCH 00/11] random: code cleanups

On Tue, Nov 12, 2013 at 11:23:03PM -0500, Greg Price wrote:
> > The basic idea is that we don't want to break systems, but we do want
> > to gently coerce people to do the right thing.  Otherwise, I'm worried
> > that distros, or embedded/mobile/consume electronics engineers would
> > just patch out the check.
> 
> That's a good idea.  I've worried about the same thing, but hadn't
> thought of that solution.

I think the key is that we set a default of requiring 128 bits, or 5
minutes, with boot-line options to change the defaults.  BTW, with the
changes that are scheduled for 3.13, this shouldn't be a problem on
most desktops.  From my T430s laptop:

...
[    4.446047] random: nonblocking pool is initialized
[    4.542119] usb 3-1.6: New USB device found, idVendor=04f2, idProduct=b2da
[    4.542124] usb 3-1.6: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[    4.542128] usb 3-1.6: Product: Integrated Camera
[    4.542131] usb 3-1.6: Manufacturer: Chicony Electronics Co., Ltd.
[    4.575753] SELinux: initialized (dev tmpfs, type tmpfs), uses transition SIDs
[    4.653338] udevd[462]: starting version 175
...
[    6.253131] EXT4-fs (sdc3): re-mounted. Opts: (null)

So even without adding device attach times (which is on the todo list)
the /dev/urandom pool is getting an estimated 128 bits of entropy
almost two seconds *before* the root file system is remouted
read/write.

(And this is also before fixing the rc80211 minstrel code to stop
wasting about two dozen bits of entropy at startup --- it's using
get_random_bytes even though it doesn't actually need
cryptographically secure random numbers.)

This is why I've been working improving the random driver's efficiency
in getting the urandom pool as soon as possible, as higher priority
than adding blocking-on-boot for /dev/urandom.

> And, pray tell, how will you know that you have done that?
> 
> Even the best entropy estimation algorithms are nothing but estimations,
> and min-entropy is the hardest form of entropy to estimate.

Of course it's only an estimate.  Some researchers have looked into
this and their results show that at least for x86 desktop/servers, we
appear to be conservative enough in our entropy estimation.  But
ultimately, yes, that is an issue which I am concerned about.  But I
believe that's a separable problem that we can work on separately from
other /dev/random issues --- and I'm hoping we can get some students
to study this problem on a variety of different hardware platforms and
entropy sources.

					- Ted

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/