-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Aloha!
Stephan Mueller wrote: > I am doing a lot of research in this area these days. If you imply > that main storage means RAM outside the caches, I think your > statement is not entirely correct. Yes, main store is RAM. >> From the first rounds of testing, I think I see the following: [...] What CPU is this? From your description it sounds to me like a x86, modern high performance CPU with instructions that has different cycle times and multiple levels of caches. On these types of CPUs, yes you don't need to hit main memory to get execution time variance. What I was trying to say is that Havege running on MCUs (AVR, AVR32, PIC, PIC32, ARM Cortex M0 etc) where instructions in general takes the same number of cycles to execute and where caches are few (few levels), have simple or even no replacement policy (it is done by SW control), the assumptions in Havege is not really present. And that this change in physical setup _should_ affect the variance measured. But again, I haven't tested it yet. > - disabling the caches completely introduces massive variations That is interesting. For a sequence of the same type of instructions? > ==> My current hunch is that the differences in the clock speeds that > drive the CPU versus the clock speed driving the memory locations > that you access (either for instruction or data fetches) are the key > driver of variations. It's more of a clock descynchronization effect? > I do not concur here, because even IF the VM host does some RDTSC > emulation, the emulation code is subject to the fundamental jitter > problem outlined above. Hence, I do not think that the jitter can be > eliminated by virtualization. I would say that Intel, Wind River would have a different opinion. It is in fact one of the things you can control. You can lock the RDTSC to provide all kinds of sequences in related to the CPU or clock or otherwise. This is actually what is being used to protect against timing side channel attacks between VMs, processes. > [1] http://www.chronox.de Very cool. How does [1] compare functionally to jytter? http://jytter.blogspot.se/ Side note, on [1] you state that it is "a non-physical true random number generator". I would say that it is a physical RNG. It measures physical events. But it does not measure events _outside_ the CPU. - -- Med vänlig hälsning, Yours Joachim Strömbergson - Alltid i harmonisk svängning. ======================================================================== -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlKYauUACgkQZoPr8HT30QFPwgCg3g4d/e/yUponwmstNu4v9Uor WtUAnRfKTjmorkvfwSsvvX+o/CO9apNq =HkI7 -----END PGP SIGNATURE----- _______________________________________________ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
