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