linux-kernel - Re: [PATCH 06/10] random: use the arch-specific rng in xfer_secondary

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:	Thu, 5 Jul 2012 11:49:44 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	"Theodore Ts'o" <tytso@....edu>
Cc:	Linux Kernel Developers List <linux-kernel@...r.kernel.org>,
	w@....eu, ewust@...ch.edu, zakir@...ch.edu, greg@...ah.com,
	mpm@...enic.com, nadiah@...ucsd.edu, jhalderm@...ch.edu,
	tglx@...utronix.de, davem@...emloft.net, stable@...nel.org
Subject: Re: [PATCH 06/10] random: use the arch-specific rng in xfer_secondary_pool

On Thu, Jul 5, 2012 at 11:12 AM, Theodore Ts'o <tytso@....edu> wrote:
> If the CPU supports a hardware random number generator, use it in
> xfer_secondary_pool(), where it will significantly improve things and
> where we can afford it.

Ok, this makes the other patch look much better, in that hopefully
"get_random_bytes()" at least is guaranteed to use the hw randomness.

HOWEVER, it does look a bit bogus. Why use "arch_get_random_int()",
when "arch_get_random_long()" gives you potentially twice the amount
at the same cost? Also, you already have a 128-byte array on the stack
(tmp[]), please don't make the stack cost of this thing even bigger.
Use a "union" to hold both tmp[] and hwrand[] without growing the
stack unnecessarily.

Also, you should not use "cycle_t cycles" - your changes to the struct
are not an improvement. The high bits of "cycles" have no actual
randomness in them, and you're just making things more expensive for
no reason.  At least on x86, the low 32 bits of the cycles are cheaper
than the whole 64-bit value. So using more bits guys you nothing, and
only makes the code slower.

                    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/