linux-kernel - Re: [PATCH] /dev/random: Insufficient of entropy on many architectures

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: <20130912210717.GC3809@logfs.org>
Date:	Thu, 12 Sep 2013 17:07:17 -0400
From:	Jörn Engel <joern@...fs.org>
To:	Theodore Ts'o <tytso@....edu>
Cc:	John Stultz <john.stultz@...aro.org>,
	Stephan Mueller <smueller@...onox.de>,
	LKML <linux-kernel@...r.kernel.org>, dave.taht@...ferbloat.net,
	Frederic Weisbecker <fweisbec@...il.com>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH] /dev/random: Insufficient of entropy on many
 architectures

On Tue, 10 September 2013 20:50:47 -0400, Theodore Ts'o wrote:
> 
> Yep.  The worse case would probably a serial port running at 230400
> bps.  Even with a 16550A UART with the 16-byte FIFO, we're talking
> about close to 2,000 interrupts per second.  A 16450 running at 115200
> bps would give us 11,520 interrupts per second....

I happen to have a real-world system with >100k interrupts per second
and - surprise - add_interrupt_randomness() showed up prominently in
the profiles.  I was also told twice to just remove that call.  I
resisted both times and have done far more work to reduce overhead
while still collecting entropy.  Some others would have caved in.

My bottom line: we have to make add_interrupt_randomness() cheaper or
else it will get removed in custom kernels.  Quite likely it already
has been removed in a number of places.

One option is to add the "input_pool.entropy_count > trickle_thresh"
condition that all other entropy sources currently have.  But instead
I would rather rename fast_mix() to not_too_fast_mix() and implement a
real fast_mix().  Essentially just xor the collected numbers into a
pool and schedule something to shuffle the bits at a later point.

The point is to make collection of randomness as cheap as possible.
The cheaper it is to collect, the more of it we will collect.  And
collecting lots of bad randomness really cheaply may be a better
tradeoff than collecting a bit of good randomness with medium cost.
Hashing will ensure that any real randomness will overcome all
predictable data we may have collected alongside.

Jörn

--
Optimizations always bust things, because all optimizations are, in
the long haul, a form of cheating, and cheaters eventually get caught.
-- Larry Wall
--
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/