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

From: Ingo Molnar
Date: Tue May 17 2011 - 08:18:12 EST

* Andi Kleen <andi@xxxxxxxxxxxxxx> wrote:

> > The x86 kernel is relocatable, so slightly randomizing the position of the
> > kernel would be feasible with no overhead on the vast majority of exising
> > distro installs, with just an updated kernel.
> Problem is that we don't have a source of secure randomness early on when the
> relocation would need to happen.

That's indeed a problem but not a fundamental one: we can read out the current
time (RTC CMOS is always available on most systems), mix it with the current
cycle counter value and PRNG mix it.

It could only be recovered if the attacker is local to that box, guesses the
precise cycle count on that specific hardware (and hardware has small thermal
variations) and knows the precise boot time to the second as present in the

Note that the amount of randomization would be small to begin with: if we have
only 3 bits of randomization and can thus make ~90% of kernel exploit attempts
crash statistically then we have most of the advantages already.

[ For the really paranoid we could add a new flag to the boot protocol and
embedd a random seed in the bzImage. This could be re-set upon installation
of a new kernel package, so on the next reboot the system gains a unique

Or we could add a boot parameter to seed things and cut this particular boot
parameter from all output like /proc/cmdline or the syslog command line
parameters printout. /etc/grub.conf is already inaccessible to unprivileged
userspace on most distros so the parameter is hidden. ]

So it's a solvable problem.

> You could either pass it as an option, but that option would be right now too
> exposed, or just use kexec and boot twice.
> But all of this has drawbacks.
> > When exposing randomized RIPs to user-space we could recalculate all RIPs back
> > to the 0xffffffff80000000 base, so oopses would have the usual non-randomized
> > form:
> This would be very confusing because the register and stack contents
> would have the non relocated addresses.

Well, kernel crashes can expose security relevant details anyway so they better
be hidden from unprivileged attackers anyway, the important thing is to
properly decode the symbols. We can keep the rest of the oops in its raw form
(and thus expose the seed to a privileged user - which we'd do anyway), being
dependable is important for oopses.

> I bet it would cause a lot of similar problems as the current %kP madness,
> just more subtle ones.

Well, did you expect me to react to your claim of 'subtle issues'?

If yes (which i assume) then why didn't you outline what you meant with that in
more detail, why are you forcing me to ask you what you mean precisely?


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at