linux-kernel - Re: [PATCH 1/2] random: Add support for architectural random hooks

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: <CA+55aFy5iRjCigmK-eddkP8Wqy_qFDZRd6PV5d0XFE3p8ws1Bg@mail.gmail.com>
Date:	Sat, 30 Jul 2011 15:43:42 -1000
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	"H. Peter Anvin" <hpa@...or.com>
Cc:	"H. Peter Anvin" <hpa@...ux.intel.com>,
	Ingo Molnar <mingo@...e.hu>,
	Thomas Gleixner <tglx@...utronix.de>,
	Fenghua Yu <fenghua.yu@...el.com>,
	Matt Mackall <mpm@...enic.com>,
	Herbert Xu <herbert@...dor.hengli.com.au>,
	"Theodore Ts'o" <tytso@....edu>, Jeff Garzik <jgarzik@...ox.com>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/2] random: Add support for architectural random hooks

On Sat, Jul 30, 2011 at 3:32 PM, H. Peter Anvin <hpa@...or.com> wrote:
>
> The only minor issue with this is that RDRAND can, at least in theory,
> return a failure condition transiently ("the entropy buffer is empty")
> or permanently ("the random number generator is broken.")  Although we
> have never actually observed the former under anything approaching
> realistic conditions, the recommendation is to loop for 10 iterations.

So I don't care too deeply, we could easily make the
"alternative_io()" thing just do a "call" to an out-of-line thing
instead.

That said, I seriously suggest that we shouldn't even care.

Why?

Because the high-level code needs to handle the failure case *anyway*,
so if there is some "in theory, CF might be clear and we don't get any
data" under certain odd an unusual circumstances, I think we might as
well just opt out for braking out early. So I don't think we really
should necessarily at all do the intel-recommended "loop at least ten
times", because quite frankly, we're probably better off just falling
back to our old sw fallback anyway.

So at this point, I'd much rather go for "really simple,
straightforward and small" than anything else.

> What makes that more than a bit ugly is that extract_entropy() and
> extract_entropy_user() take their randomness type ("perfect/blocking"
> versus "PRNG degrade OK/nonblocking") from a pointer to the pool, which
> means that some kind of indirection or policy information is going to be
> necessary there anyway, in order to enable get_random_bytes() and its
> friends -- as opposed to get_random_int().

Why?

WHY SHOULD WE CARE?

Nobody is ever going to complain about being better than necessary,
and the whole point of rdrand should be that it's (a) fast enough and
(b) good enough that the whole "blocking/degraded" thing is a total
nonissue.

In other words, we should consider rdrand to be "perfect +
nonblocking", which is acceptable to everybody. Those nonblocking
users aren't going to complain about good randomness, even if they
might *accept* less than perfect randomness.

IOW, I really want to aim for simple and straightforward. Don't make
it more complicated than it is.

Aim to make my patch *smaller* rather than trying to find ways to make
it bigger.

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