[lkml]   [2011]   [May]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [BUG] perf: bogus correlation of kernel symbols
On Fri, 2011-05-20 at 15:11 +0200, Ingo Molnar wrote:
> * Dan Rosenberg <> wrote:
> > On Fri, 2011-05-20 at 14:07 +0200, Ingo Molnar wrote:
> > > * Dan Rosenberg <> wrote:
> > >
> > > > I was able to boot a relocatable kernel with the decompression location at a
> > > > hard-coded offset without too much trouble. Everything seems to work fine.
> > >
> > > Nice!
> > >

A progress update, and a number of questions.

The randomization itself is working fine with the following hack in

movl %ebp, %ebx
shll $0x8, %eax
andl $0x3ffffff, %eax
addl %eax, %ebx
movl BP_kernel_alignment(%esi), %eax
decl %eax
addl %eax, %ebx
notl %eax
andl %eax

That brings me to my first two questions:

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?

2. The current default physical alignment is 16mb as a result of this

Having 16mb alignment greatly restricts the amount of usable entropy for
randomization. It seems an alternate solution to the problem the above
patch addresses is reverting back to 1mb alignment (or 2/4 mb if that
has performance benefits) and enforcing a 16mb minimum physical start
for relocatable kernels by bumping it up in the boot code if necessary.
Would this be possible? I'd like to avoid requiring distros to touch
CONFIG_PHYSICAL_ALIGN (and risk breaking things) in order to have more
useful randomization.

A few more questions arose during my efforts:

3. The current hack I'm using to determine the offset to reverse apply
to symbol output looks something like this:

unsigned long kptr_adjust = ((unsigned long)_text &

Is it safe to assume that kernel .text is the first thing in a
decompressed kernel image? If not, any other suggestions? It seemed
easier to compute this in the decompressed kernel at runtime rather than
try to figure out a way to pass the actual decompression address from
the boot stage to the main kernel.

4. What kind of behavior do people want with %pK and kptr_restrict? If
possible, I'd like to find a way that perf users can have the benefits
of this feature and still have usable symbol support. However, module
symbols are a bit tricky, since they're not being relocated with the
rest of the kernel, and it doesn't seem meaningful to reverse-apply the
same offset in module symbol output. Perhaps a separate format
specifier should be introduced to differentiate symbols that need to be

Basically, we've got kernel .text symbols, module symbols, and dynamic
kernel pointers, and I'm not sure with what granularity people are
interested in hiding them. It seems perf at least wants more than "all
or nothing".

5. I'd like some more opinions on moving the IDT. So far, the two
options are using a fixed mapping similar to the F00F bug fix, and
allocating it percpu at runtime.

Looking forward to feedback, criticism, disgust, etc.


 \ /
  Last update: 2011-05-22 20:47    [W:0.097 / U:2.632 seconds]
©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site