[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <6733.1306202368@localhost>
Date: Mon, 23 May 2011 21:59:28 -0400
From: Valdis.Kletnieks@...edu
To: Ingo Molnar <mingo@...e.hu>
Cc: Dan Rosenberg <drosenberg@...curity.com>,
Tony Luck <tony.luck@...il.com>, linux-kernel@...r.kernel.org,
davej@...hat.com, kees.cook@...onical.com, davem@...emloft.net,
eranian@...gle.com, torvalds@...ux-foundation.org,
adobriyan@...il.com, penberg@...nel.org, hpa@...or.com,
Arjan van de Ven <arjan@...radead.org>,
Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [BUG] perf: bogus correlation of kernel symbols
On Mon, 23 May 2011 12:49:02 +0200, Ingo Molnar said:
> Well, since entropy does not get reduced on addition of independent variables
> the right sequence is (pseudocode):
>
> rnd = entropy_cycles();
> rnd += entropy_rdrand();
> rnd += entropy_RTC();
> rnd += entropy_system();
I'm having trouble convincing myself that RTC and cycles are truly independent
variables.... ;)
Consider the case of a fixed-frequency CPU - if you know the time since boot,
and the current RTC, and the current cycle count, you can work backwards to
find the RTC and cycle count at boot. I'm not sure that a variable clockspeed
helps all that much - an attacker can perhaps find a way to force the highest/
lowest CPU speed - or the system may even helpfully do it for the attacker -
I've seen plenty of misconfigured laptops that force lowest supported CPU
clockspeed on battery rather than race-to-idle.
Having said that, the 13 bootup rdtsc values you list *seem* to have on the
order of 24-28 bits of entropy, and only the lowest-order bit seems to be
non-random (the low-order byte of the 13 values are 28, b6, 44, 54, dc, 78, 2c,
38, 02, 58, 76, 16, and be). So rdtsc appears to be good enough for what we
want here...
Content of type "application/pgp-signature" skipped
Powered by blists - more mailing lists