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:	Sat, 30 Jul 2011 22:02:24 -0400
From:	Bryan Donlan <bdonlan@...il.com>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	George Spelvin <linux@...izon.com>, linux-kernel@...r.kernel.org,
	mpm@...enic.com, tytso@....edu
Subject: Re: [PATCH 1/2] random: Add support for architectural random hooks

On Sat, Jul 30, 2011 at 21:35, Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
> On Sat, Jul 30, 2011 at 3:02 PM, Bryan Donlan <bdonlan@...il.com> wrote:
>>
>> The problem, as you can see here, is we need to test for the existence
>> of an architecture-specific HWRNG once for _every word processed_.
>
> See the patch I sent out. Not only doesn't it check an
> architecture-specific flag on x86, IT COSTS NOTHING AT ALL on other
> architectures. Not per byte, not per call, not at all.

Certainly, on architectures which never support fast hwrngs, you can
avoid the overhead. I'm concerned about whether you're actually coming
out ahead in the case where there _is_ an arch hwrng.

> On x86, it does have the cost of:
>
>  - basically one conditional for the whole loop (branching out if
> there is no rdrand support at all). You cannot do much better than
> that, except of course if you statically say "compile for an x86 that
> doesn't have rdrand")
>
>  - a per-word cost of checking CF - which you are supposed to do
> anyway (ie the rdrand hardware will return with CF clear if the data
> isn't reliable).
>
> So at least on x86, I think you can get pretty close to "optimal
> behavior" with my approach.

Ah, I see - I wasn't aware RDRAND could fail. In that case, it's not
so bad, although it would be nicer to directly branch on the carry
flag, rather than emitting code that will, eventually, do a setcc ->
and -> test -> branch.

In any case though, what about my suggestion - don't mess with urandom
at all, and let udev replace the /dev/urandom device node with one
directed to a fast hwrng device if one is detected? This has zero
extra overhead - you have to pass through the character device layer
no matter what, and you can go straight from there to either the
standard hwrng wrapper code, or to your own special extra-fast
implementation of dev_read. It should also satisfy Mr. Spelvin's
paranoia - he can just instruct his udev to not replace /dev/urandom.
And so we don't need to introduce any new APIs to the kernel at all,
nor do we need to touch any core code.

The downside, of course, is that in-kernel users of entropy won't have
this fast API - do we have the kind of high-volume non-blocking
entropy consumers in the kernel that might care about this?
--
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/