linux-kernel - Re: [PATCH 2/5] x86, KASLR: Drop CONFIG_RANDOMIZE_BASE_MAX

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAGXu5j+n3GdKV9xHHTa1siD=C_+63oUm5Rby-qXCvVAD1Og9Fw@mail.gmail.com>
Date:	Thu, 21 Apr 2016 11:13:36 -0700
From:	Kees Cook <keescook@...omium.org>
To:	Borislav Petkov <bp@...e.de>
Cc:	Ingo Molnar <mingo@...nel.org>, Baoquan He <bhe@...hat.com>,
	Yinghai Lu <yinghai@...nel.org>,
	Ingo Molnar <mingo@...hat.com>,
	"x86@...nel.org" <x86@...nel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Andrey Ryabinin <aryabinin@...tuozzo.com>,
	Dmitry Vyukov <dvyukov@...gle.com>,
	"H.J. Lu" <hjl.tools@...il.com>,
	Josh Poimboeuf <jpoimboe@...hat.com>,
	Andy Lutomirski <luto@...nel.org>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 2/5] x86, KASLR: Drop CONFIG_RANDOMIZE_BASE_MAX_OFFSET

On Thu, Apr 21, 2016 at 10:44 AM, Borislav Petkov <bp@...e.de> wrote:
> On Wed, Apr 20, 2016 at 01:55:43PM -0700, Kees Cook wrote:
>> From: Baoquan He <bhe@...hat.com>
>>
>> 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@...hat.com>
>> [kees: rewrote changelog, dropped KERNEL_IMAGE_SIZE_DEFAULT, rewrote help]
>> Signed-off-by: Kees Cook <keescook@...omium.org>
>> ---
>>  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