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+55aFwjx=E5fpO=gfx0ugPE2Cgd_NOtw1Kx52pbg4aQEgshRg@mail.gmail.com>
Date:	Sat, 30 Jul 2011 09:29:18 -1000
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Matt Mackall <mpm@...enic.com>
Cc:	"H. Peter Anvin" <hpa@...ux.intel.com>,
	"H. Peter Anvin" <hpa@...or.com>, Ingo Molnar <mingo@...e.hu>,
	Thomas Gleixner <tglx@...utronix.de>,
	Fenghua Yu <fenghua.yu@...el.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 9:13 AM, Matt Mackall <mpm@...enic.com> wrote:
>
> Well then rather than saying my NAK doesn't matter, you should say you
> also NAK it.

No, I don't think your NAK matters because your arguments were so insane.

Talking about electron microscopes and *expanding* on the patch just
makes me go "that NAK is not worth worrying about".

You comparing the rdrand to 'rdtsc' is more realistic, but it still
dismisses how powerful rdrand is.

The fact is, even if you worry about some back door for the NSA, or
some theoretical lack of perfect 32-bit randomness, we can pretty much
depend on it. We still do our own hashing on top of whatever entropy
we get out of rdrand, and we would still have all our other stuff.
Plus the instruction is public and testable - if Intel did something
wrong, they'll be *very* embarrassed.

In other words, there's absolutely no reason not to use it, and allow
us to get away from /dev/random running out of entropy. We absolutely
should use it for bootup randomness (where we currently are somewhat
weak), and I absolutely disagree that it should be made into more of a
driver abstraction.

I'd be willing to take Peter's patch *without* the abstraction, and
then just expect to cut it down.

But I'd be even more willing to just take something that just
introduces a per-arch interface to get a "unsigned long *" that is
random, and returning the number of bits of expected entropy in that
thing.  And for x86 CPU's with the RDRAND capability bit, I'd give
Intel the benefit of the doubt and just make it do a single "rdrand"
and return the full 64 bit (or is it a 32-bit interface? I should
know, but I didn't look it up).

Of course, if there are other known random interfaces that might give
more random bits, maybe "void *"+size is actually the right thing.
Probably a single word is the most reasonable and simple interface in
the absence of examples to the contrary, though.

                       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/