lkml.org 
[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
    From
    Date
    On Fri, 2011-05-20 at 15:11 +0200, Ingo Molnar wrote:
    > * Dan Rosenberg <drosenberg@vsecurity.com> wrote:
    >
    > > On Fri, 2011-05-20 at 14:07 +0200, Ingo Molnar wrote:
    > > > * Dan Rosenberg <drosenberg@vsecurity.com> 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
    arch/x86/boot/compressed/head_32.S:

    #ifdef CONFIG_RELOCATABLE
    movl %ebp, %ebx
    #ifdef CONFIG_RANDOMIZE_BASE
    rdtsc
    shll $0x8, %eax
    andl $0x3ffffff, %eax
    addl %eax, %ebx
    #endif
    movl BP_kernel_alignment(%esi), %eax
    decl %eax
    addl %eax, %ebx
    notl %eax
    andl %eax
    #endif

    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
    patch:

    http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=ceefccc93932b920a8ec6f35f596db05202a12fe

    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 &
    ~(CONFIG_PHYSICAL_ALIGN-1)) - (PAGE_OFFSET + CONFIG_PHYSICAL_START);

    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
    offset?

    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.

    Regards,
    Dan



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