[lkml]   [2011]   [May]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [RFC][PATCH] Randomize kernel base address on boot
    On Tue, May 24, 2011 at 4:31 PM, 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.
    > Comments/Questions:
    > * Since RDRAND is relatively new, only the most recent version of
    > binutils supports assembling it.  To avoid breaking builds for people
    > who use older toolchains but want this feature, I hardcoded the opcodes.
    > If anyone has a better approach, please let me know.
    > * I chose to mimic the F00F bugfix behavior for moving the IDT, since it
    > required very little code and has the additional benefit of making the
    > IDT read-only. Ingo Molnar's suggestion of allocating per-cpu IDTs
    > instead is still on the table, and I'd like to get feedback on this.
    > * In order to increase the entropy for the randomized base, I changed
    > the default value of CONFIG_PHYSICAL_ALIGN back to 2mb.  It had
    > previously been raised to 16mb as a hack so that relocatable kernels
    > wouldn't load below that minimum.  I address this by changing the
    > meaning of CONFIG_PHYSICAL_START such that it now represents a minimum
    > address that relocatable kernels can be loaded at (rather than being
    > ignored by relocatable kernels).  So, if a relocatable kernel determines
    > it should be loaded at an address below CONFIG_PHYSICAL_START (which
    > defaults to 16mb), I just bump it up.
    > * I would appreciate guidance on safe values for the highest addresses
    > we can safely load the kernel at, on both 32-bit and 64-bit. This
    > version uses 64mb (0x4000000) for 32-bit, and worked well in testing.
    > * CONFIG_RANDOMIZE_BASE automatically sets the default value of
    > kptr_restrict and dmesg_restrict to 1, since it's nonsensical to use
    > this without the other two.  I considered removing
    > CONFIG_SECURITY_DMESG_RESTRICT altogether (it currently sets the default
    > value for dmesg_restrict), but just in case distros want to keep the
    > CONFIG as a toggle switch but don't want to use CONFIG_RANDOMIZE_BASE, I
    > kept it around.  So, now CONFIG_RANDOMIZE_BASE sets the default value
    > * x86-64 is still "to-do". Because it calculates the kernel text address
    > twice, this may be a little trickier.

    This trick doesn't work as you may expect on 64-bit. You are
    relocating the physical image of the kernel, but the kernel actually
    runs from a fixed virtual mapping. This would require adding the
    relocation code that 32-bit uses, so the virtual address can be

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

     \ /
      Last update: 2011-05-24 23:49    [W:0.026 / U:2.292 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site