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]

Date:	Fri, 29 Jul 2011 23:20:40 -0700
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 Fri, Jul 29, 2011 at 2:16 PM, Matt Mackall <mpm@...enic.com> wrote:
>
> I have already NAKed this approach in no uncertain terms.

Doesn't matter.

Talking about "standard hardware random number drivers" is just crazy
talk, when the instruction is a single instruction that takes tens of
nanoseconds to run. Any driver overhead would be just crazy, and no
user would ever want that anyway.

User space would never use it, because they just want to use the
instruction directly.

And kernel space doesn't want it either, for the exact same reason.
There's no point in making it anything but a simple direct function
call, because the whole functionality is so cheap.

This is not like some stupid "behind PCI" crap. It's high bandwidth
and low latency.

If anything, I think Peter's approach perhaps doesn't tie it in close
enough. Instead of making it some indirect function you register, just
make it an inline function per architecture that just returns how many
bits of randomness it gives (default to just an inline function that
returns 0 for the case of no on-CPU rng).

On x86, choice between the different possible random number generators
(if somebody cares enough about the cyrix and whatever ones) could be
a an asm_alternate() thing.

If you don't trust the CPU rng, don't bother with stupid arguments
about electron microscopes.  Test it - or more reasonably - make it
just one small part of the entropy pool. But don't make it something
heavy-weight, when the whole *point* of having the hardware is to make
it light-weight.

                 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/