linux-kernel - Re: [PATCH] random: mix all saved registers into entropy pool

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: <20140519223943.GC14563@logfs.org>
Date:	Mon, 19 May 2014 18:39:43 -0400
From:	Jörn Engel <joern@...fs.org>
To:	"H. Peter Anvin" <hpa@...or.com>
Cc:	Theodore Ts'o <tytso@....edu>, lkml <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] random: mix all saved registers into entropy pool

On Mon, 19 May 2014 15:18:01 -0700, H. Peter Anvin wrote:
> 
> I think this is likely to be particularly valuable during boot.  I can
> see it becoming substantially less valuable after that point, but during
> boot is when the most critical.
> 
> What I do see as an issue is that the value is probably impossible to
> quantify, and so I feel more than a bit queasy about giving it
> /dev/random credit.  However, making sure the pool is well stirred
> during boot is really way more important.

I would feel fairly confident giving this .25 bits of entropy per
event.  With 40% unique hashes and assuming at most 1 bit of entropy
for a unique hash, that is a fairly conservative underestimate.

But as you can see from the patch, I feel less confident doing any
kind of entropy-guessing in general and have skipped that step.  By
the .25 bits metric, my patch should feed 128 bits of entropy into
both the non-blocking pool and the input pool within the first 5s or
so of boot time.  In reality it is likely more.

The other problem to solve is VM clones sharing the same state for the
various pools.  Assuming HZ=100 no external interrupts and .25 bits, we
would gather 128 bits in just above 5s.  That is not great, but okish.

What worries me is that much of those 5s may be spent inside the idle
loop and have rather predictable register content and we may run
tickless.  I have no great solution for that case.

We could change the ratelimiting to, say, 4 interrupts per jiffie.
But that would still not help much in the worst case scenario above,
so the benefits don't seem convincing.

Jörn

--
When you admit that some people are too important to prosecute, it's
just a few short steps to the obvious corollary – that everybody else
is unimportant enough to jail.
-- Matt Taibbi
--
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/