lkml.org 
[lkml]   [2011]   [May]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [RFC][PATCH] Randomize kernel base address on boot
    From
    Date
    On Tue, 2011-05-24 at 16:31 -0400, Dan Rosenberg wrote:
    > This introduces CONFIG_RANDOMIZE_BASE, which randomizes the address at
    > which the kernel is decompressed at boot as a security feature that
    > deters exploit attempts relying on knowledge of the location of kernel
    > internals. The default values of the kptr_restrict and dmesg_restrict
    > sysctls are set to (1) when this is enabled, since hiding kernel
    > pointers is necessary to preserve the secrecy of the randomized base
    > address.
    >
    > This feature also uses a fixed mapping to move the IDT (if not already
    > done as a fix for the F00F bug), to avoid exposing the location of
    > kernel internals relative to the original IDT. This has the additional
    > security benefit of marking the new virtual address of the IDT
    > read-only.
    >
    > Entropy is generated using the RDRAND instruction if it is supported. If
    > not, then RDTSC is used, if supported. If neither RDRAND nor RDTSC are
    > supported, then no randomness is introduced. Support for the CPUID
    > instruction is required to check for the availability of these two
    > instructions.
    >
    > Thanks to everyone who contributed helpful suggestions and feedback so
    > far.
    >

    I wanted to send out an update email that consolidated the feedback and
    suggestions I've received so far:

    1. I'm nearly finished a first draft of code to parse the BIOS E820
    memory map to determine where it's safe to place the randomized kernel.
    This code accounts for overlapping regions, as well as potential
    conflicts in region types (free vs. reserved, etc.), in favor of
    non-free types. The end result is, I'll have a reasonable upper bound.

    2. I'll parse the kernel command line for crashkernel arguments and
    avoid placing a randomized kernel in any regions marked as reserved. A
    new command line argument for kdump might be a good idea as well
    (discussion on-going).

    3. I'll be introducing a new format specifier (perhaps %pk) that
    unconditionally de-randomizes kernel pointers, and switch callers where
    appropriate.

    4. The perf call chains that rely on kernel pointers will account for
    the randomization.

    5. I'll be switching to per-cpu IDTs, basing my work on the following
    patch:

    http://marc.info/?l=linux-kernel&m=112767117501231&w=2

    Any review or comments on the above patch would be helpful. I'm
    considering submitting this portion separately, as it may provide
    performance and scalability benefits regardless of randomization.

    6. As per H. Peter Anvin's suggestion, it seems there's some demand for
    a way to opt-out at the boot-loader level, possibly via a command-line
    option and boot protocol flag.

    7. Still need to figure out exactly what's ok and what's not regarding
    altering alignment and PHYSICAL_START. It seems there's some consensus
    on "don't do it", but perhaps it's ok to partially ignore the alignment
    config at runtime in favor of hard-coded, known-safe, finer-grained
    alternatives.

    8. Other pieces of feedback, such as comment suggestions, changes to
    kptr_restrict/dmesg_restrict defaults, etc. have been incorporated.

    8. x86-64 will present its own set of challenges. One thing at a time.

    Thanks for all the feedback and guidance so far. Let me know if
    anything above is objectionable, or if you have any more suggestions.
    There's lots to do, but I haven't given up yet. :)

    Regards,
    Dan



    \
     
     \ /
      Last update: 2011-05-26 22:41    [W:9.316 / U:0.008 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site