linux-kernel - Re: drivers/char/random.c: more ruminations

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: <20140611020835.GA23110@thunk.org>
Date:	Tue, 10 Jun 2014 22:08:35 -0400
From:	Theodore Ts'o <tytso@....edu>
To:	George Spelvin <linux@...izon.com>
Cc:	hpa@...ux.intel.com, linux-kernel@...r.kernel.org,
	mingo@...nel.org, price@....edu
Subject: Re: drivers/char/random.c: more ruminations

On Tue, Jun 10, 2014 at 08:10:03PM -0400, George Spelvin wrote:
> What I wanted to do was eliminate that huge tmp buffer from
> _xfer_secondary_pool.  There's no good reason why it needs to be there.
> and several reasons for getting rid of it.

So have you actually instrumented the kernel to demonstrate that in
fact we have super deep stack call paths where the 128 bytes worth of
stack actually matters?

Premature optimization being the root of all evil (not to mention
wasting a lot of time of kernel developers) and all that....

> I hadn't tested the patch when I mailed it to you (I prepared it in
> order to reply to your e-mail, and it's annoying to reboot the machine
> I'm composing an e-mail on), but I have since.  It works.

As an aside, I'd strongly suggest that you use kvm to do your kernel
testing.  It means you can do a lot more testing which is always a
good thing....

> The *fundamental* race, as I see it, is the one between modifying pools
> and crediting entropy.
> 
> As I noted, you can't safely do the credit either before *or* after modifying
> the pool; you will always end up with the wrong answer in some situation.

Actually, it's **fine**.  That's because RNDADDENTROPY adds the
entropy to the input pool, which is has the limit flag set.  So we
will never pull more entropy than the pool is credited as having.
This means that race can't happen.  It ***is*** safe.

1)  Assume the entropy count starts at 10 bytes.

2)  Random writer mixes in 20 bytes of entropy into the entropy pool.

3)  Random extractor tries to extract 32 bytes of entropy.  Since the
entropy count is still is 10, it will only get 10 bytes.  (And if we
started with the entropy count started at zero, we wouldn't extract
any entropy at all.)

4) Random writer credit the entropy counter with the 20 bytes mixed in
step #2.

See? no problems!

					- 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/