Messages in this thread | | | Subject | Re: [BUG] perf: bogus correlation of kernel symbols | From | Dan Rosenberg <> | Date | Sun, 22 May 2011 20:25:36 -0400 |
| |
On Sun, 2011-05-22 at 16:49 -0700, Tony Luck wrote: > > > On Sun, May 22, 2011 at 11:45 AM, Dan Rosenberg > <drosenberg@vsecurity.com> wrote: > 1. Is it ok to assume the existence of rdtsc? If not, what > are other > ways of gathering entropy early in the boot process? If this > is the > approach that's going to be taken, system uptime potentially > becomes > useful for attackers. Any thoughts on how to address this? > > There is a cpuid bit to tell you whether the processor supports rdtsc. >
This might be worth checking, but it also might just be easier to clearly document in the Kconfig that the feature requires rdtsc. I'll play with it a bit.
> In the cold boot case, I'd worry about whether rdtsc was all that > random, > it counts from zero when the processors come out of cold reset, and > things should be quite deterministic up to when the kernel loads; > especially if you have a solid state boot drive rather than the old > spinning kind. >
The question really becomes whether it's "good enough". It's certainly not cryptographic randomness, but it will produce different results on different boots depending on a variety of factors, including out-of-order instruction execution, multi-CPU systems, and differences in CPU models. Even though a single machine may be slightly more likely to produce certain offsets more often, it seems to me that it would still accomplish the goal, because it's highly unlikely that an attacker would be able to perform the statistical analysis necessary to figure that out.
> Sometime soon you'll have "rdrand" available (check a different cpuid > bit). >
This of course is highly preferable, but I'd rather implement a solution that's widely supported in hardware today. Perhaps further down the road it could be switched.
> -Tony > >
Thanks for the feedback.
-Dan
| |