From: Stephan Mueller <smueller@chronox.de>
To: "H. Peter Anvin" <hpa@zytor.com>
Cc: "Theodore Ts'o" <tytso@mit.edu>, "Jörn Engel" <joern@logfs.org>,
"Linux Kernel Developers List" <linux-kernel@vger.kernel.org>,
macro@linux-mips.org, ralf@linux-mips.org, dave.taht@gmail.com,
blogic@openwrt.org, andrewmcgr@gmail.com, geert@linux-m68k.org,
tg@mirbsd.de, sandyinchina@gmail.com
Subject: Re: [RFC PATCH 0/5] CPU Jitter RNG
Date: Tue, 04 Feb 2014 21:31:59 +0100 [thread overview]
Message-ID: <1874855.zG4mP2DzbB@tauon> (raw)
In-Reply-To: <52F13A1C.3040003@zytor.com>
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
next prev parent reply other threads:[~2014-02-04 20:32 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-02-04 12:36 Stephan Mueller
2014-02-04 12:39 ` [PATCH 1/5] " Stephan Mueller
2014-02-04 12:40 ` [PATCH 2/5] CPU Jitter RNG: Enable compilation Stephan Mueller
2014-02-04 13:39 ` Geert Uytterhoeven
2014-02-04 16:19 ` Stephan Mueller
2014-02-04 16:39 ` Hannes Frederic Sowa
2014-02-04 16:50 ` Hannes Frederic Sowa
2014-02-04 16:53 ` Stephan Mueller
2014-02-04 17:15 ` Hannes Frederic Sowa
2014-02-04 12:40 ` [PATCH 3/5] CPU Jitter RNG: integration with /dev/random Stephan Mueller
2014-02-04 12:41 ` [PATCH 4/5] CPU Jitter RNG: provide status proc files Stephan Mueller
2014-02-04 12:42 ` [PATCH 5/5] CPU Jitter RNG: add read/write sysctls Stephan Mueller
2014-02-04 17:08 ` [RFC PATCH 0/5] CPU Jitter RNG Theodore Ts'o
2014-02-04 19:06 ` H. Peter Anvin
2014-02-04 19:23 ` tytso
2014-02-04 19:39 ` Geert Uytterhoeven
2014-02-04 20:39 ` H. Peter Anvin
2014-02-04 21:46 ` Geert Uytterhoeven
2014-02-04 21:47 ` H. Peter Anvin
2014-02-10 21:07 ` Jörn Engel
2014-02-04 20:31 ` Stephan Mueller [this message]
2014-02-04 21:34 ` H. Peter Anvin
2014-02-04 21:43 ` Geert Uytterhoeven
2014-02-04 20:25 ` Stephan Mueller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1874855.zG4mP2DzbB@tauon \
--to=smueller@chronox.de \
--cc=andrewmcgr@gmail.com \
--cc=blogic@openwrt.org \
--cc=dave.taht@gmail.com \
--cc=geert@linux-m68k.org \
--cc=hpa@zytor.com \
--cc=joern@logfs.org \
--cc=linux-kernel@vger.kernel.org \
--cc=macro@linux-mips.org \
--cc=ralf@linux-mips.org \
--cc=sandyinchina@gmail.com \
--cc=tg@mirbsd.de \
--cc=tytso@mit.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome