Re: [RFC PATCH 0/5] CPU Jitter RNG

From: Stephan Mueller
Date: Tue Feb 04 2014 - 15:32:18 EST


Am Dienstag, 4. Februar 2014, 11:06:04 schrieb H. Peter Anvin:

Hi Peter,

>On 02/04/2014 09:08 AM, Theodore Ts'o wrote:
>> I really wish we could get someone inside Intel who has deep
>> knowledge
>> about CPU internals to render an opinion about this. My reaction to
>> "I can't explain where the entropy is coming from" seems very similar
>> to what my home grown attempts to create an encryption algoritm when
>> I
>> was much younger and much more foolish --- "it must be secure because
>> I can't break it".
>
>I think I have deep enough knowledge about CPU architectures in general
>(as opposed to specific Intel designs, which I wouldn't be able to
>comment on anyway) to comment. The more modern and high performance a
>design you have the more sources of unpredictability there are.
>However, there are very few, if any, (unintentional) sources of actual
>quantum noise in a synchronous CPU, which means that this is at its
>core a PRNG albeit with a large and rather obfuscated state space.
>
>The quantum noise sources there are in a system are generally two
>independent clocks running against each other. However, independent
>clocks are rare; instead, most clocks are in fact slaved against each
>other using PLLs and similar structures. When mixing spread spectrum
>clocks and non-spread-spectrum clocks that relationship can be very
>complex, but at least for some designs it is still at its core
>predictable.

But isn't there an additional clock? The clock used to drive the cache
and memory bus? When measuring memory accesses timings, larger
variations in the execution time are evident. This also applies when
hitting the caches (for L1, the variations are less than for L2 than for
L3). The variations in access timings would come from the CPU wait
states and their duration, would it not?

Ciao
Stephan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/