[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.034 / U:10.720 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site