linux-kernel - Re: [BUG] perf: bogus correlation of kernel symbols

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:	Sun, 22 May 2011 20:25:36 -0400
From:	Dan Rosenberg <drosenberg@...curity.com>
To:	Tony Luck <tony.luck@...il.com>
Cc:	Ingo Molnar <mingo@...e.hu>, 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
Subject: Re: [BUG] perf: bogus correlation of kernel symbols

On Sun, 2011-05-22 at 16:49 -0700, Tony Luck wrote:
> 
> 
> On Sun, May 22, 2011 at 11:45 AM, Dan Rosenberg
> <drosenberg@...curity.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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/