Re: [PATCH 2/5] x86, KASLR: Drop CONFIG_RANDOMIZE_BASE_MAX_OFFSET

From: Kees Cook
Date: Thu Apr 21 2016 - 14:14:02 EST


On Thu, Apr 21, 2016 at 10:44 AM, Borislav Petkov <bp@xxxxxxx> wrote:
> On Wed, Apr 20, 2016 at 01:55:43PM -0700, Kees Cook wrote:
>> From: Baoquan He <bhe@xxxxxxxxxx>
>>
>> Currently CONFIG_RANDOMIZE_BASE_MAX_OFFSET is used to limit the maximum
>> offset for kernel randomization. This limit doesn't need to be a CONFIG
>> since it is tied completely to KERNEL_IMAGE_SIZE, and will make no sense
>> once physical and virtual offsets are randomized separately. This patch
>> removes CONFIG_RANDOMIZE_BASE_MAX_OFFSET and consolidates the Kconfig
>> help text.
>>
>> Signed-off-by: Baoquan He <bhe@xxxxxxxxxx>
>> [kees: rewrote changelog, dropped KERNEL_IMAGE_SIZE_DEFAULT, rewrote help]
>> Signed-off-by: Kees Cook <keescook@xxxxxxxxxxxx>
>> ---
>> arch/x86/Kconfig | 72 ++++++++++++++----------------------
>> arch/x86/boot/compressed/kaslr.c | 12 +++---
>> arch/x86/include/asm/page_64_types.h | 8 ++--
>> arch/x86/mm/init_32.c | 3 --
>> 4 files changed, 36 insertions(+), 59 deletions(-)
>>
>> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
>> index 2dc18605831f..5892d549596d 100644
>> --- a/arch/x86/Kconfig
>> +++ b/arch/x86/Kconfig
>> @@ -1932,54 +1932,38 @@ config RELOCATABLE
>> (CONFIG_PHYSICAL_START) is used as the minimum location.
>>
>> config RANDOMIZE_BASE
>> - bool "Randomize the address of the kernel image"
>> + bool "Randomize the address of the kernel image (KASLR)"
>> depends on RELOCATABLE
>> default n
>> ---help---
>> - Randomizes the physical and virtual address at which the
>> - kernel image is decompressed, as a security feature that
>> - deters exploit attempts relying on knowledge of the location
>> - of kernel internals.
>> + In support of Kernel Address Space Layout Randomization (KASLR),
>> + this randomizes the physical address at which the kernel image
>> + is decompressed and the virtual address where the kernel
>
> Just say "loaded" here.

Okay, works for me. This will get some changes after the phys/virt is split.

>
>> + image is mapped, as a security feature that deters exploit
>> + attempts relying on knowledge of the location of kernel
>> + code internals.
>> +
>> + The kernel physical and virtual address can be randomized
>> + from 16MB up to 1GB on 64-bit and 512MB on 32-bit. (Note that
>> + using RANDOMIZE_BASE reduces the memory space available to
>> + kernel modules from 1.5GB to 1GB.)
>> +
>> + Entropy is generated using the RDRAND instruction if it is
>> + supported. If RDTSC is supported, its value is mixed into
>> + the entropy pool as well. If neither RDRAND nor RDTSC are
>> + supported, then entropy is read from the i8254 timer.
>> +
>> + Since the kernel is built using 2GB addressing,
>
> Does that try to refer to the 1G kernel and 1G fixmap pagetable
> mappings? I.e., level2_kernel_pgt and level2_fixmap_pgt in
> arch/x86/kernel/head_64.S?

The "2GB addressing" part is in reference to:

-mcmodel=kernel
Generate code for the kernel code model. The kernel runs in the
negative 2 GB of the address space. This model has to be used for
Linux kernel code.

>
>> and
>> + PHYSICAL_ALIGN must be at a minimum of 2MB, only 10 bits of
>> + entropy is theoretically possible. Currently, with the
>> + default value for PHYSICAL_ALIGN and due to page table

This ("page table layouts") really means fixmap and (lack of) identity
mappings. I was trying to remove some level of jargon at Ingo's
request, so this area got a bit vague. I'm happy to rewrite this
however people think is best.

>> + layouts, 64-bit uses 9 bits of entropy and 32-bit uses 8 bits.
>> +
>> + If CONFIG_HIBERNATE is also enabled, KASLR is disabled at boot
>> + time. To enable it, boot with "kaslr" on the kernel command
>> + line (which will also disable hibernation).
>
> ...
>
> --
> Regards/Gruss,
> Boris.
>
> SUSE Linux GmbH, GF: Felix ImendÃrffer, Jane Smithard, Graham Norton, HRB 21284 (AG NÃrnberg)
> --

Thanks!

-Kees

--
Kees Cook
Chrome OS & Brillo Security