On Tue, Aug 15, 2017 at 07:37:05PM +0200, Thomas Gleixner wrote:
> That exploits the fact that the CPU and caches run at a different non
> synchronized clock than the memory controller and therefore the execution
> time for both the wbinvd() and the memchr_inv() measured in TSC cycles is
> non constant and random enough for the early boot randomization.
Um, can we guarantee that is always true for all systems? Even, say,
for Silermont, Goldmont and Goldmont Plus (Intel's SOC designs) where
the memory may be located in the same chip package as the CPU/caches?
And even if this is true today, can we be sure that it will be true
for the forseeable future? Using multiple clocks takes more power, so
I would think that on a SOC there would be a strong pressure to use a
single oscillator for the whole package.
If we really want to do this, I'd much rather *not* have code calling
tsc_early_random(). We're better off having the code call
get_random_bytes() and/or get_random_u32(), and having these systems
use RDRAND if available, and if not, falling back to
tsc_early_random() and then mixing it with whatever unpredictability
we may have been able to gather so far if the CRNG hasn't been
initialized yet.
That way something like tsc_early_random() can help, but it can't make
things worse than what we have today (excepting the performance delay
caused by adding whatever random shite that we hope is enough to
introduce unpredictability to the TSC --- for which I still remain
very skeptical).
- Ted
P.S. As I recall hpa@ has talked to some Intel architects internally
about how much unpredictability we could really get, and how much of
it is just because there's complex state that we can't see (which if
we could see, might make it much more predictable), and as I recall
they didn't say anyhing definitively; but they were nervous. I'm
pretty sure that for Intel architects, the right answer from their
perspective is to use RDRAND, and not to play games with the TSC.
The other thing to note here is that because Intel has RDRAND, I'm
actually not that worried about Intel; all of the
drivers/char/random.c will mix in inputs from RDRAND or RDSEED if
available. I'm actually much more worried about architectures that
don't have a hardware random number generator (e.g., some ARM
subarchitectures and MIPS). So while you might be able to come up
with something that could work on x86, the real question is it safely
generalizable to other, non-x86 architectures. And that's where it
gets much more scary.
