[lkml]   [2011]   [Jul]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 1/2] random: Add support for architectural random hooks
On 07/30/2011 06:13 PM, Linus Torvalds wrote:
> So here is my counter-suggestion
> NOTE NOTE NOTE! This is completely and utterly untested. I didn't
> actually check how big the "rdrand" and "setc" instructions are, so
> the ASM_NOP4 there is just a random "I guess two 'xor' instructions
> are four bytes shorter than the rdrand/setc instructions are".
> So please don't take this as a serious patch that should be applied,
> but instead take it as a serious alternative *approach*.
> Note that with the default inline function in <asm-generic/random.h>
> is designed so that architectures that use it (this patch does *not*
> contain the architecture glue to enable it) will compile the loop in
> random.c entirely away. No test, no nothing.
> Comments?
> (Btw, even on x86, assuming the concept works and the ASM_NOP4 is
> corrected to the right length, we'd need to support older assemblers
> that don't understand the "rdrand" instruction, so it would need to be
> done as a explicit byte sequence).
> Again, TOTALLY UNTESTED. Concept patch only!! There may be seriously
> stupid bugs here, but the point is that it should make it easy for an
> architecture to have a "get a word of random data quickly".

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.

The end result is a small loop, just over 20 bytes long; as a result I
left the implementation as a subroutine instead of inlining it in my v2

.byte 0x48, 0x0f, 0xc7, 0xf2 /* rdrand %rdx */
jnc 2f
mov %rdx, (%rdi)
dec %eax
jnz 1b

We can of course inline this loop with alternatives if you would prefer.
I'll do a v3 patchset with that implementation later today and we can
check out how it looks.

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().

As such, it seems cleaner to me to take the hit of going through a
function pointer.


H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.

 \ /
  Last update: 2011-07-31 03:35    [W:0.072 / U:0.032 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site