On Fri, 24 May 2013 23:58:00 +0200
Andy Polyakov <[email protected]> wrote:
Hi Andy,
> >>> - the root cause of entropy
> >> Consider following snippet:
> >>
> >> static inline unsigned int rdtsc()
> >> { int eax;
> >> asm volatile("rdtsc":"=a"(eax)::"edx");
> >> return eax;
> >
> > Unfortuately I am not an assembler wizzard, but I guess you only
> > try to return parts of the rdtsc instruction?
> >> }
> >> main()
> >> { int i;
> >> unsigned int diff1, diff0 = rdtsc() - rdtsc();
> >>
> >> for (i=0;i<10000000;i++)
> >> if ((diff1 = rdtsc() - rdtsc()) != diff0)
> >> printf("%u\n",-diff0), diff0=diff1;
> >> }
> >>
> >> How many lines do you think it would print? If I compile it with
> >> optimization on, my Sandy Bridge system prints ... ~100 lines.
> >> Hundred
> >
> > Without optimization:
> >
> > $ gcc -o test test.c
> > $ ./test > test.out
> > cat test.out | wc
> > 128886 128886 386814
> >
> > Test with optimizations:
> >
> > $ gcc -O2 -o test test.c
> > ./test > test.out
> > $ cat test.out | wc
> > 270876 270876 812741
> >
> > So, where is the problem?
>
> Once thread is scheduled for execution, it effectively gets execution
> core for exclusive use. On idle system for whole timer quantum. How
> many instructions would it execute then? On 3GHz processor with 250Hz
> system timer (as on my system) it will have 12.000.000, twelve
> million, clock cycles to spend. Whatever variations that are caused
> by TLB and cache misses, branch misprediction, are all settled in
> first several hundred cycles or in less than 0.001% of time. After
> that execution of pure computational code is very deterministic.
> Differences between rdtsc readings don't have to be constant,
> depending on how instructions interacts with pipeline they can form
> complex yet periodic structure, which bares no entropy. I could have
> emphasize "pure computational", but it doesn't seem to concern you.
> Assertion seems to be that *any* instruction sequence is subject to
> timing variations. Even if normal memory references are involved, one
> should remember that cache's purpose is to amortize and effectively
> mask variations in references to external memory. Yes, you can talk
> about hardware interrupts and shared caches, but then it would mean
> that you're *dependent* on system being busy with other tasks. But
> then you can't value on entropy without knowing the momentary load.
> If you don't know load, then you have to assume the worst, i.e. that
> system is completely idle and code executes for whole timer quantum
> without interruptions (go to beginning of paragraph and reiterate on
> how [un]predictable would be scheduler behaviour and return from
> interrupt).
You would think that you are correct since the system should be
deterministic. But it does not show such deterministic behavior. And
when you say that after a few hundred cycles all should be settled, why
do I see some 200,000 outputs from the code of yours on an otherwise
idle system?
>
> >> out of 10 million tries. Of the hundred half of values is 28 and
> >> half is thousands and up, obviously timer interrupts. Thousands
> >> and up is something you suggest to disregard, so all we have is
> >> single value of 28. What "miniscule variations" of which
> >> "instruction" are we talking
> >
> > All values I see fluctuate according to the values in the graph in
> > chapter 2.
> >
> > By any chance, did you disable your TSC (you could do that on a
> > per-process basis)?
> >
> > Bottom line, with the code you suggest, I still see the same
> > fluctuations I used to draw the graphs in chapter 2. Note, this is
> > just a visual inspection of the values I see in test.out.
> >
> >> about? What I'm trying to say is that I can't see that you managed
> >> to actually formulate what is "the root cause of entropy". "CPU
> >> execution time jitter" does not describe it. I'd argue that
> >> variations originate
> >
> > Very interesting that you have a different reaction on your system.
>
> You can't judge *all* the systems by yours, so why does it come as
> surprise? What's likely to be "special" [and relevant in the context]
> about my system is that I disable TurboBoost and HyperThreading. If
> TSC was disabled executable wouldn't work at all or most common
> difference between readings wouldn't be 28.
I totally understand that the noise source I am using is not present.
Hence, the code implements an initialization function that checks
whether the core problem is present. If it is not, you shall not use
the RNG.
So, what is so wrong to try to harvest the entropy on systems where it
is available? You try to smack down the entire approach because some or
even a large number of systems do not show that behavior. But still a
large number of systems DO show this behavior. And on those systems, we
should harvest it because all OSes are starved of entropy.
>
> > All tests I did so far on different CPUs show the expected results.
> >
> > Can you tell me more about your system? Can you please execute
> > jent_entropy_init() all by itself?
>
> jent_enropy_init returns success on my system. But does it manage to
> detect my system specifics? No, it simply assumes that it's running
> on your system. This is the problem.
Then we need to work on this issue.
>
> > All your system shows implies that the root cause is not present.
> > Hence, the code requires to execute jent_entropy_init() and only
> > continue when this function returns without an error.
>
> Once again, I fail to see that you managed to explain what is the
> root cause. And without understanding you can't put value on it and
> make such broad statements.
> ______________________________________________________________________
> OpenSSL Project http://www.openssl.org
> Development Mailing List [email protected]
> Automated List Manager [email protected]
--
| Cui bono? |
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [email protected]
Automated List Manager [email protected]
