x86, boot: kaslr cleanup and 64bit kaslr support

From: Yinghai Lu <[email protected]>

Firstly, current run_size is calculated via shell script arch/x86/tools/calc_run_size.sh. It gets file offset and mem size of section .bss and .brk in vmlinux, then add them as follows:

run_size=$(( $offsetA + $sizeA + $sizeB ))

However this is completely wrong. The offset is the starting address of section or segment in elf file. Below is a vmlinux I compiled:

[bhe@x1 linux]$ objdump -h vmlinux

vmlinux: file format elf64-x86-64

Sections:

Idx Name          Size      VMA               LMA               File off  Algn
 27 .bss          00170000  ffffffff81ec8000  0000000001ec8000  012c8000  2**12

ALLOC
28 .brk 00027000 ffffffff82038000 0000000002038000 012c8000 2**0
ALLOC

Here we can get run_size is 0x145f000.
0x012c8000 + 0x00170000 + 0x00027000 = 0x145f000

[bhe@x1 linux]$ readelf -l vmlinux

Elf file type is EXEC (Executable file) Entry point 0x1000000
There are 5 program headers, starting at offset 64

Program Headers:
Type Offset VirtAddr PhysAddr
FileSiz MemSiz Flags Align
LOAD 0x0000000000200000 0xffffffff81000000 0x0000000001000000

                 0x0000000000b5e000 0x0000000000b5e000  R E    200000
  LOAD           0x0000000000e00000 0xffffffff81c00000 0x0000000001c00000
                 0x0000000000145000 0x0000000000145000  RW     200000
  LOAD           0x0000000001000000 0x0000000000000000 0x0000000001d45000
                 0x0000000000018158 0x0000000000018158  RW     200000
  LOAD           0x000000000115e000 0xffffffff81d5e000 0x0000000001d5e000
                 0x000000000016a000 0x0000000000301000  RWE    200000
  NOTE           0x000000000099bcac 0xffffffff8179bcac 0x000000000179bcac
                 0x00000000000001bc 0x00000000000001bc         4

Section to Segment mapping:
Segment Sections...

   00     .text .notes __ex_table .rodata __bug_table .pci_fixup .tracedata __ksymtab __ksymtab_gpl __ksymtab_strings __init_rodata __param __modver
   01     .data .vvar
   02     .data..percpu
   03     .init.text .init.data .x86_cpu_dev.init .parainstructions .altinstructions .altinstr_replacement .iommu_table .apicdrivers .exit.text .smp_locks .bss .brk
   04     .notes

Here we can get the same value as current run_size if we add p_offset and p_memsz.
0x000000000115e000 + 0x0000000000301000 = 0x145f000

But is it right? Obviously not. We should calculate it using the last LOAD program segment like this:
run_size = phdr->p_paddr + phdr->p_memsz - physical load addr of kernel run_size = 0x0000000001d5e000 + 0x0000000000301000 - 0x0000000001000000 = 0x105f000

It's equal to VO_end-VO_text and certainly it's simpler to do. _end: 0xffffffff8205f000
_text:0xffffffff81000000
run_size = 0xffffffff8205f000 - 0xffffffff81000000 = 0x105f000

Secondly run_size is a simple constant, we don't need to pass it around and we already have voffset.h for that. We can share voffset.h between misc.c and header.S instead of getting run_size in other ways. Hence in this patch, we move voffset.h creation code to boot/compressed/Makefile.

Dependence was:
boot/header.S ==> boot/voffset.h ==> vmlinux
boot/header.S ==> compressed/vmlinux ==> compressed/misc.c
Now become:
boot/header.S ==> compressed/vmlinux ==> compressed/misc.c ==> boot/voffset.h ==> vmlinux

Use macro in misc.c to replace passed run_size.

Fixes e6023367d779 ("x86, kaslr: Prevent .bss from overlaping initrd")

Cc Junjie Mao <[email protected]>

Cc Kees Cook <[email protected]>

Cc Josh Triplett <[email protected]>

Cc Andrew Morton <[email protected]>

Signed-off-by Yinghai Lu <[email protected]>

Signed-off-by Baoquan He <[email protected]>

---
v2->v3:
Adjust the patch log.
v3->v4:
Correct calculation errors in patch log that Kees pointed out.

 arch/x86/boot/Makefile            | 11 +----------
 arch/x86/boot/compressed/Makefile | 12 ++++++++++++
 arch/x86/boot/compressed/misc.c   |  3 +++
 3 files changed, 16 insertions(+), 10 deletions(-)

arch/x86/boot/Makefile +1 -10

index bd021e5..40f0ae2 100644
@@ -78,15 +78,6 @@ $(obj)/vmlinux.bin: $(obj)/compressed/vmlinux FORCE
 
 SETUP_OBJS = $(addprefix $(obj)/,$(setup-y))
 
-sed-voffset := -e 's/^\([0-9a-fA-F]*\) [ABCDGRSTVW] \(_text\|_end\)$$/\#define VO_\2 0x\1/p'
-
-quiet_cmd_voffset = VOFFSET $@
-      cmd_voffset = $(NM) $< | sed -n $(sed-voffset) > $@
-
-targets += voffset.h
-$(obj)/voffset.h: vmlinux FORCE
-       $(call if_changed,voffset)
-
 sed-zoffset := -e 's/^\([0-9a-fA-F]*\) [ABCDGRSTVW] \(startup_32\|startup_64\|efi32_stub_entry\|efi64_stub_entry\|efi_pe_entry\|input_data\|_end\|_ehead\|_text\|z_.*\)$$/\#define ZO_\2 0x\1/p'
 
 quiet_cmd_zoffset = ZOFFSET $@

@@ -98,7 +89,7 @@ $(obj)/zoffset.h: $(obj)/compressed/vmlinux FORCE
 
 
 AFLAGS_header.o += -I$(obj)
-$(obj)/header.o: $(obj)/voffset.h $(obj)/zoffset.h
+$(obj)/header.o: $(obj)/zoffset.h
 
 LDFLAGS_setup.elf      := -T
 $(obj)/setup.elf: $(src)/setup.ld $(SETUP_OBJS) FORCE

arch/x86/boot/compressed/Makefile +12 -0

index f9ce75d..d9dedd9 100644
@@ -41,6 +41,18 @@ LDFLAGS_vmlinux := -T
 hostprogs-y    := mkpiggy
 HOST_EXTRACFLAGS += -I$(srctree)/tools/include
 
+sed-voffset := -e 's/^\([0-9a-fA-F]*\) [ABCDGRSTVW] \(_text\|_end\)$$/\#define VO_\2 _AC(0x\1,UL)/p'
+
+quiet_cmd_voffset = VOFFSET $@
+      cmd_voffset = $(NM) $< | sed -n $(sed-voffset) > $@
+
+targets += ../voffset.h
+
+$(obj)/../voffset.h: vmlinux FORCE
+       $(call if_changed,voffset)
+
+$(obj)/misc.o: $(obj)/../voffset.h
+
 vmlinux-objs-y := $(obj)/vmlinux.lds $(obj)/head_$(BITS).o $(obj)/misc.o \
        $(obj)/string.o $(obj)/cmdline.o \
        $(obj)/piggy.o $(obj)/cpuflags.o

arch/x86/boot/compressed/misc.c +3 -1

index e7c6fdf..4d317b7 100644
@@ -11,6 +11,7 @@
 
 #include "misc.h"
 #include "../string.h"
+#include "../voffset.h"
 
 /* WARNING!!
  * This code is compiled with -fPIC and it is relocated dynamically

@@ -415,6 +416,8 @@ asmlinkage __visible void *decompress_kernel(void *rmode, memptr heap,
        lines = real_mode->screen_info.orig_video_lines;
        cols = real_mode->screen_info.orig_video_cols;
 
+       run_size = VO__end - VO__text;
+
        console_init();
        debug_putstr("early console in decompress_kernel\n");
 
--

2.5.0

From: Yinghai Lu <[email protected]>

So now we use the formula below to get run_size.

run_size = VO__end - VO__text

Let's remove code for old run_size calculation and clean up the places where run_size need be passed in and out.

Cc "H. Peter Anvin" <[email protected]>

Cc Josh Triplett <[email protected]>

Cc Kees Cook <[email protected]>

Cc Andrew Morton <[email protected]>

Cc Ard Biesheuvel <[email protected]>

Cc Junjie Mao <[email protected]>

Signed-off-by Yinghai Lu <[email protected]>

Signed-off-by Baoquan He <[email protected]>

---
v2->v3:
Adjust the patch log.
v3->v4:
Kees suggested that change run_size as const in decompress_kernel()

 arch/x86/boot/compressed/Makefile  |  4 +---
 arch/x86/boot/compressed/head_32.S |  3 +--
 arch/x86/boot/compressed/head_64.S |  3 ---
 arch/x86/boot/compressed/misc.c    |  6 ++----
 arch/x86/boot/compressed/mkpiggy.c | 10 ++-------
 arch/x86/tools/calc_run_size.sh    | 42 --------------------------------------
 6 files changed, 6 insertions(+), 62 deletions(-)
 delete mode 100644 arch/x86/tools/calc_run_size.sh

arch/x86/boot/compressed/Makefile +1 -3

index d9dedd9..fef80fa 100644
@@ -105,10 +105,8 @@ suffix-$(CONFIG_KERNEL_XZ) := xz
 suffix-$(CONFIG_KERNEL_LZO)    := lzo
 suffix-$(CONFIG_KERNEL_LZ4)    := lz4
 
-RUN_SIZE = $(shell $(OBJDUMP) -h vmlinux | \
-            $(CONFIG_SHELL) $(srctree)/arch/x86/tools/calc_run_size.sh)
 quiet_cmd_mkpiggy = MKPIGGY $@
-      cmd_mkpiggy = $(obj)/mkpiggy $< $(RUN_SIZE) > $@ || ( rm -f $@ ; false )
+      cmd_mkpiggy = $(obj)/mkpiggy $< > $@ || ( rm -f $@ ; false )
 
 targets += piggy.S
 $(obj)/piggy.S: $(obj)/vmlinux.bin.$(suffix-y) $(obj)/mkpiggy FORCE

arch/x86/boot/compressed/head_32.S +1 -2

index 0c140f9..122b32f 100644
@@ -210,7 +210,6 @@ relocated:
  * Do the decompression, and jump to the new kernel..
  */
                                /* push arguments for decompress_kernel: */
-       pushl   $z_run_size     /* size of kernel with .bss and .brk */
        pushl   $z_output_len   /* decompressed length, end of relocs */
 
        movl    BP_init_size(%esi), %eax

@@ -226,7 +225,7 @@ relocated:
        pushl   %eax            /* heap area */
        pushl   %esi            /* real mode pointer */
        call    decompress_kernel /* returns kernel location in %eax */
-       addl    $28, %esp
+       addl    $24, %esp
 
 /*
  * Jump to the decompressed kernel.

arch/x86/boot/compressed/head_64.S +0 -3

index 67dd8d3..3691451 100644
@@ -407,8 +407,6 @@ relocated:
  * Do the decompression, and jump to the new kernel..
  */
        pushq   %rsi                    /* Save the real mode argument */
-       movq    $z_run_size, %r9        /* size of kernel with .bss and .brk */
-       pushq   %r9
        movq    %rsi, %rdi              /* real mode address */
        leaq    boot_heap(%rip), %rsi   /* malloc area for uncompression */
        leaq    input_data(%rip), %rdx  /* input_data */

@@ -416,7 +414,6 @@ relocated:
        movq    %rbp, %r8               /* output target address */
        movq    $z_output_len, %r9      /* decompressed length, end of relocs */
        call    decompress_kernel       /* returns kernel location in %rax */
-       popq    %r9
        popq    %rsi
 
 /*

arch/x86/boot/compressed/misc.c +2 -4

index 4d317b7..def6207 100644
@@ -393,9 +393,9 @@ asmlinkage __visible void *decompress_kernel(void *rmode, memptr heap,
                                  unsigned char *input_data,
                                  unsigned long input_len,
                                  unsigned char *output,
-                                 unsigned long output_len,
-                                 unsigned long run_size)
+                                 unsigned long output_len)
 {
+       const unsigned long run_size = VO__end - VO__text;
        unsigned char *output_orig = output;
 
        real_mode = rmode;

@@ -416,8 +416,6 @@ asmlinkage __visible void *decompress_kernel(void *rmode, memptr heap,
        lines = real_mode->screen_info.orig_video_lines;
        cols = real_mode->screen_info.orig_video_cols;
 
-       run_size = VO__end - VO__text;
-
        console_init();
        debug_putstr("early console in decompress_kernel\n");
 

arch/x86/boot/compressed/mkpiggy.c +2 -8

index a613c84..c5148642 100644
@@ -34,13 +34,11 @@ int main(int argc, char *argv[])
 {
        uint32_t olen;
        long ilen;
-       unsigned long run_size;
        FILE *f = NULL;
        int retval = 1;
 
-       if (argc < 3) {
-               fprintf(stderr, "Usage: %s compressed_file run_size\n",
-                               argv[0]);
+       if (argc < 2) {
+               fprintf(stderr, "Usage: %s compressed_file\n", argv[0]);
                goto bail;
        }
 

@@ -65,15 +63,11 @@ int main(int argc, char *argv[])
        ilen = ftell(f);
        olen = get_unaligned_le32(&olen);
 
-       run_size = atoi(argv[2]);
-
        printf(".section \".rodata..compressed\",\"a\",@progbits\n");
        printf(".globl z_input_len\n");
        printf("z_input_len = %lu\n", ilen);
        printf(".globl z_output_len\n");
        printf("z_output_len = %lu\n", (unsigned long)olen);
-       printf(".globl z_run_size\n");
-       printf("z_run_size = %lu\n", run_size);
 
        printf(".globl input_data, input_data_end\n");
        printf("input_data:\n");

arch/x86/tools/calc_run_size.sh deleted +0 -43

deleted file mode 100644
index 1a4c17b..0000000
@@ -1,42 +0,0 @@
-#!/bin/sh
-#
-# Calculate the amount of space needed to run the kernel, including room for
-# the .bss and .brk sections.
-#
-# Usage:
-# objdump -h a.out | sh calc_run_size.sh
-
-NUM='\([0-9a-fA-F]*[ \t]*\)'
-OUT=$(sed -n 's/^[ \t0-9]*.b[sr][sk][ \t]*'"$NUM$NUM$NUM$NUM"'.*/\1\4/p')
-if [ -z "$OUT" ] ; then
-       echo "Never found .bss or .brk file offset" >&2
-       exit 1
-fi
-
-OUT=$(echo ${OUT# })
-sizeA=$(printf "%d" 0x${OUT%% *})
-OUT=${OUT#* }
-offsetA=$(printf "%d" 0x${OUT%% *})
-OUT=${OUT#* }
-sizeB=$(printf "%d" 0x${OUT%% *})
-OUT=${OUT#* }
-offsetB=$(printf "%d" 0x${OUT%% *})
-
-run_size=$(( $offsetA + $sizeA + $sizeB ))
-
-# BFD linker shows the same file offset in ELF.
-if [ "$offsetA" -ne "$offsetB" ] ; then
-       # Gold linker shows them as consecutive.
-       endB=$(( $offsetB + $sizeB ))
-       if [ "$endB" != "$run_size" ] ; then
-               printf "sizeA: 0x%x\n" $sizeA >&2
-               printf "offsetA: 0x%x\n" $offsetA >&2
-               printf "sizeB: 0x%x\n" $sizeB >&2
-               printf "offsetB: 0x%x\n" $offsetB >&2
-               echo ".bss and .brk are non-contiguous" >&2
-               exit 1
-       fi
-fi
-
-printf "%d\n" $run_size
-exit 0
--

2.5.0

From: Yinghai Lu <[email protected]>

Relocation handling performs bounds checking on the relocated addresses. The existing code uses output_len (VO size plus relocs size) as the max address. This is not right since the max_addr check should stop at the end of VO and exclude bss, brk, etc, which follows. The valid range should be VO [_text, __bss_start] in the loaded physical address space.

In this patch, add export for __bss_start to voffset.h and use it to get the correct max_addr.

Signed-off-by Yinghai Lu <[email protected]>

Cc Baoquan He <[email protected]>

---
v2->v3:
Adjust patch log.
v3->v4:
Kees help rewrite the patch log

 arch/x86/boot/compressed/Makefile | 2 +-
 arch/x86/boot/compressed/misc.c   | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

arch/x86/boot/compressed/Makefile +1 -1

index fef80fa..2e7c0ce 100644
@@ -41,7 +41,7 @@ LDFLAGS_vmlinux := -T
 hostprogs-y    := mkpiggy
 HOST_EXTRACFLAGS += -I$(srctree)/tools/include
 
-sed-voffset := -e 's/^\([0-9a-fA-F]*\) [ABCDGRSTVW] \(_text\|_end\)$$/\#define VO_\2 _AC(0x\1,UL)/p'
+sed-voffset := -e 's/^\([0-9a-fA-F]*\) [ABCDGRSTVW] \(_text\|__bss_start\|_end\)$$/\#define VO_\2 _AC(0x\1,UL)/p'
 
 quiet_cmd_voffset = VOFFSET $@
       cmd_voffset = $(NM) $< | sed -n $(sed-voffset) > $@

arch/x86/boot/compressed/misc.c +1 -2

index def6207..029f42f 100644
@@ -259,7 +259,7 @@ static void handle_relocations(void *output, unsigned long output_len)
        int *reloc;
        unsigned long delta, map, ptr;
        unsigned long min_addr = (unsigned long)output;
-       unsigned long max_addr = min_addr + output_len;
+       unsigned long max_addr = min_addr + (VO___bss_start - VO__text);
 
        /*
         * Calculate the delta between where vmlinux was linked to load
--

2.5.0

From: Yinghai Lu <[email protected]>

Current aslr only support random in small range, from 16M to 1G. And new range still use old mapping. Also it does not support new range above 4G.

We need to have ident mapping for the new range before we can do decompress to the new output, and later run them.

In this patch, we add ident mapping for all needed range.

At first, to support aslr to put random VO above 4G, we must set ident mapping for the new range when it come via startup_32 path.

Secondly, when boot from 64bit bootloader, bootloader set ident mapping, and boot via ZO (arch/x86/boot/compressed/vmlinux) startup_64. Those pages for pagetable need to be avoided when we select new random VO (vmlinux) base. Otherwise decompressor would overwrite them during decompressing.
First way would be: walk through pagetable and find out every page is used by pagetable for every mem_aovid checking but we will need extra code, and may need to increase mem_avoid array size to hold them.
Other way would be: We can create new ident mapping instead, and pages for pagetable will come from _pagetable section of ZO, and they are in mem_avoid array already. In this way, we can reuse the code for ident mapping.

The _pgtable will be shared by 32bit and 64bit path to reduce init_size, as now ZO _rodata to _end will contribute init_size.

We need to increase pgt buffer size.
When boot via startup_64, as we need to cover old VO, params, cmdline and new VO, in extreme case we could have them all cross 512G boundary, will need (2+2)*4 pages with 2M mapping. And need 2 for first 2M for vga ram. Plus one for level4. Total will be 19 pages.
When boot via startup_32, aslr would move new VO above 4G, we need set extra ident mapping for new VO, pgt buffer come from _pgtable offset 6 pages. Should only need (2+2) pages at most when it cross 512G boundary. So 19 pages could make both paths happy.

Current aslr only support random in small range, from 16M to 1G. And

From: Yinghai Lu <[email protected]>

Now new randomized output can only be chosen from regions above loaded address. In this case, for bootloaders like kexec which always loads kernel near the end of ram, it doesn't do randomization at all. Or kernel is loaded in a very big starting address, we should not give up that area is loaded in a very large address, then the area below the large loaded address will be given up. This is not reasonable.

With correct tracking in mem_avoid we can allow random output below loaded address. With this change, though kexec can get random ouput below its loaded address of kernel.

Now we just pick 512M as min_addr. If kernel loaded address is bigger than 512M, E.g 8G. Then [512M, 8G) can be added into random output candidate area.

Signed-off-by Yinghai Lu <[email protected]>

---
 arch/x86/boot/compressed/aslr.c | 10 ++++++++--
 1 file changed, 8 insertions(+), 2 deletions(-)

arch/x86/boot/compressed/aslr.c +2 -1

index ddfc3d0..d072ca7 100644
@@ -446,7 +446,8 @@ void choose_kernel_location(unsigned char *input,
                                unsigned long output_size,
                                unsigned char **virt_offset)
 {
-       unsigned long random;
+       unsigned long random, min_addr;
+
        *virt_offset = (unsigned char *)LOAD_PHYSICAL_ADDR;
 
 #ifdef CONFIG_HIBERNATION

arch/x86/boot/compressed/aslr.c +2 -2

+
        /* Walk e820 and find a random address. */
-       random = find_random_phy_addr((unsigned long)*output, output_size);
+       random = find_random_phy_addr(min_addr, output_size);
        if (!random)
                debug_putstr("KASLR could not find suitable E820 region...\n");
        else {
--

2.5.0

Quoted 36 lines · Baoquan He

From: Yinghai Lu <[email protected]>

Now new randomized output can only be chosen from regions above loaded address. In this case, for bootloaders like kexec which always loads kernel near the end of ram, it doesn't do randomization at all. Or kernel is loaded in a very big starting address, we should not give up that area is loaded in a very large address, then the area below the large loaded address will be given up. This is not reasonable.

With correct tracking in mem_avoid we can allow random output below loaded address. With this change, though kexec can get random ouput below its loaded address of kernel.

Now we just pick 512M as min_addr. If kernel loaded address is bigger than 512M, E.g 8G. Then [512M, 8G) can be added into random output candidate area.

Signed-off-by Yinghai Lu <[email protected]>

---
 arch/x86/boot/compressed/aslr.c | 10 ++++++++--
 1 file changed, 8 insertions(+), 2 deletions(-)

arch/x86/boot/compressed/aslr.c +2 -1

index ddfc3d0..d072ca7 100644
@@ -446,7 +446,8 @@ void choose_kernel_location(unsigned char *input,
                                unsigned long output_size,
                                unsigned char **virt_offset)
 {
-       unsigned long random;
+       unsigned long random, min_addr;
+
        *virt_offset = (unsigned char *)LOAD_PHYSICAL_ADDR;
 
 #ifdef CONFIG_HIBERNATION

arch/x86/boot/compressed/aslr.c void choose_kernel_location(unsigned char *input, · line 474

Quoted 7 lines

arch/x86/boot/compressed/aslr.c +4 -0

@@ -467,8 +468,13 @@ void choose_kernel_location(unsigned char *input,
        mem_avoid_init((unsigned long)input, input_size,
                       (unsigned long)*output);
 
+       /* start from 512M */
+       min_addr = (unsigned long)*output;
+       if (min_addr > (512UL<<20))
+               min_addr = 512UL<<20;

The goal is to find a minimum address? I'm not sure this comment makes sense. Shouldn't this be:

    /* Lower minimum to 512M. */

min_addr = min_t(unsigned long, *output, 512UL << 20);

Or something like that?

Quoted 11 lines

arch/x86/boot/compressed/aslr.c +2 -2

+
        /* Walk e820 and find a random address. */
-       random = find_random_phy_addr((unsigned long)*output, output_size);
+       random = find_random_phy_addr(min_addr, output_size);
        if (!random)
                debug_putstr("KASLR could not find suitable E820 region...\n");
        else {
--

2.5.0

-Kees

Signature · 2 lines

Kees Cook
Chrome OS & Brillo Security

The old code uses CONFIG_RANDOM_OFFSET_MAX to get the offset max for kernel virtual randomization, and CONFIG_RANDOM_OFFSET_MAX is a configurable value within the scope of [512M, 1G] on x86_64. Currently CONFIG_RANDOM_OFFSET_MAX always defaults to 1G, and seems no obvious benefit to make it configurable. So Kees suggested we should set KERNEL_IMAGE_SIZE 1G if RANDOMIZE_BASE is on, and use KERNEL_IMAGE_SIZE as offset max.

In this patch just do as Kees suggested. And with this change CONFIG_RANDOM_OFFSET_MAX is not needed any more, so clean it up now.

Signed-off-by Baoquan He <[email protected]>

---
v3->v4:
Added in v4.

 arch/x86/Kconfig                     | 57 +++++++++++++-----------------------
 arch/x86/boot/compressed/aslr.c      |  7 ++---
 arch/x86/include/asm/page_64_types.h |  5 ++--
 arch/x86/mm/init_32.c                |  3 --
 4 files changed, 26 insertions(+), 46 deletions(-)

arch/x86/Kconfig +21 -36

index b105105..fbe0bb0 100644
@@ -1908,51 +1908,36 @@ config RANDOMIZE_BASE
        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.
+          Randomizes the physical address at which the kernel image
+          is decompressed and the virtual address where the kernel
+          image is mapped, as a secrurity feature that deters exploit
+          attempts relying on knowledge of the location of kernel
+          internals.
+
+          The kernel physical address can be randomized from 16M to
+          64T at most. The kernel virtual address will be offset
+          by up to KERNEL_IMAGE_SIZE. On 32-bit KERNEL_IMAGE_SIZE is
+          512MiB. while on 64-bit this is limited by how the kernel
+          fixmap page table is positioned, so this cannot be larger
+          than 1GiB currently. Without RANDOMIZE_BASE there is a 512MiB
+          to 1.5GiB split between kernel and modules. When RANDOMIZE_BASE
+          is enabled, the modules area will shrink to compensate, up
+          to a 1GiB to 1GiB split, KERNEL_IMAGE_SIZE changes from 512MiB
+          to 1GiB.
 
           Entropy is generated using the RDRAND instruction if it is
           supported. If RDTSC is supported, it is used as well. If
           neither RDRAND nor RDTSC are supported, then randomness is
           read from the i8254 timer.
 
-          The kernel will be offset by up to RANDOMIZE_BASE_MAX_OFFSET,
-          and aligned according to PHYSICAL_ALIGN. Since the kernel is
-          built using 2GiB addressing, and PHYSICAL_ALGIN must be at a
-          minimum of 2MiB, only 10 bits of entropy is theoretically
-          possible. At best, due to page table layouts, 64-bit can use
-          9 bits of entropy and 32-bit uses 8 bits.
+          Since the kernel is built using 2GiB addressing, and
+          PHYSICAL_ALGIN must be at a minimum of 2MiB, only 10 bits of
+          entropy is theoretically possible. At best, due to page table
+          layouts, 64-bit can use 9 bits of entropy and 32-bit uses 8
+          bits.
 
           If unsure, say N.
 
-config RANDOMIZE_BASE_MAX_OFFSET
-       hex "Maximum kASLR offset allowed" if EXPERT
-       depends on RANDOMIZE_BASE
-       range 0x0 0x20000000 if X86_32
-       default "0x20000000" if X86_32
-       range 0x0 0x40000000 if X86_64
-       default "0x40000000" if X86_64
-       ---help---
-         The lesser of RANDOMIZE_BASE_MAX_OFFSET and available physical
-         memory is used to determine the maximal offset in bytes that will
-         be applied to the kernel when kernel Address Space Layout
-         Randomization (kASLR) is active. This must be a multiple of
-         PHYSICAL_ALIGN.
-
-         On 32-bit this is limited to 512MiB by page table layouts. The
-         default is 512MiB.
-
-         On 64-bit this is limited by how the kernel fixmap page table is
-         positioned, so this cannot be larger than 1GiB currently. Without
-         RANDOMIZE_BASE, there is a 512MiB to 1.5GiB split between kernel
-         and modules. When RANDOMIZE_BASE_MAX_OFFSET is above 512MiB, the
-         modules area will shrink to compensate, up to the current maximum
-         1GiB to 1GiB split. The default is 1GiB.
-
-         If unsure, leave at the default value.
-
 # Relocation on x86 needs some additional build support
 config X86_NEED_RELOCS
        def_bool y

arch/x86/boot/compressed/aslr.c +3 -4

index d072ca7..737643c 100644
@@ -428,11 +428,10 @@ static unsigned long find_random_virt_offset(unsigned long minimum,
        minimum = ALIGN(minimum, CONFIG_PHYSICAL_ALIGN);
 
        if (image_size <= CONFIG_PHYSICAL_ALIGN)
-               slot_num = (CONFIG_RANDOMIZE_BASE_MAX_OFFSET - minimum) /
+               slot_num = (KERNEL_IMAGE_SIZE - minimum) /
                                CONFIG_PHYSICAL_ALIGN;
        else
-               slot_num = (CONFIG_RANDOMIZE_BASE_MAX_OFFSET -
-                               minimum - image_size) /
+               slot_num = (KERNEL_IMAGE_SIZE - minimum - image_size) /
                                CONFIG_PHYSICAL_ALIGN + 1;
 
        random = get_random_long() % slot_num;

@@ -487,7 +486,7 @@ void choose_kernel_location(unsigned char *input,
 
        /*
         * Get a random address between LOAD_PHYSICAL_ADDR and
-        * CONFIG_RANDOMIZE_BASE_MAX_OFFSET
+        * KERNEL_IMAGE_SIZE
         */
        random = find_random_virt_offset(LOAD_PHYSICAL_ADDR, output_size);
        *virt_offset = (unsigned char *)random;

arch/x86/include/asm/page_64_types.h +2 -3

index 4928cf0..8775bec 100644
@@ -48,9 +48,8 @@
  * kernel page table mapping, reducing the size of the modules area.
  */
 #define KERNEL_IMAGE_SIZE_DEFAULT      (512 * 1024 * 1024)
-#if defined(CONFIG_RANDOMIZE_BASE) && \
-       CONFIG_RANDOMIZE_BASE_MAX_OFFSET > KERNEL_IMAGE_SIZE_DEFAULT
-#define KERNEL_IMAGE_SIZE   CONFIG_RANDOMIZE_BASE_MAX_OFFSET
+#if defined(CONFIG_RANDOMIZE_BASE)
+#define KERNEL_IMAGE_SIZE   (1024 * 1024 * 1024)
 #else
 #define KERNEL_IMAGE_SIZE      KERNEL_IMAGE_SIZE_DEFAULT
 #endif

arch/x86/mm/init_32.c +0 -4

index 2ebfbaf..c5ae958 100644
@@ -807,9 +807,6 @@ void __init mem_init(void)
        BUILD_BUG_ON(VMALLOC_START                      >= VMALLOC_END);
 #undef high_memory
 #undef __FIXADDR_TOP
-#ifdef CONFIG_RANDOMIZE_BASE
-       BUILD_BUG_ON(CONFIG_RANDOMIZE_BASE_MAX_OFFSET > KERNEL_IMAGE_SIZE);
-#endif
 
 #ifdef CONFIG_HIGHMEM
        BUG_ON(PKMAP_BASE + LAST_PKMAP*PAGE_SIZE        > FIXADDR_START);
--

2.5.0

***Background:
Previously a bug is reported that kdump didn't work when kaslr is enabled. During discussing that bug fix, we found current kaslr has a limilation that it can only randomize in 1GB region.

This is because in curent kaslr implementaion only physical address of kernel loading is randomized. Then calculate the delta of physical address where vmlinux was linked to load and where it is finally loaded. If delta is not equal to 0, namely there's a new physical address where kernel is actually decompressed, relocation handling need be done. Then delta is added to offset of kernel symbol relocation, this makes the address of kernel text mapping move delta long. Though in principle kernel can be randomized to any physical address, kernel text mapping address space is limited and only 1G, namely as follows on x86_64:

        [0xffffffff80000000, 0xffffffffc0000000)

In one word, kernel text physical address and virtual address randomization is coupled. This causes the limitation.

Then hpa and Vivek suggested we should change this. To decouple the physical address and virtual address randomization of kernel text and let them work separately. Then kernel text physical address can be randomized in region [16M, 64T), and kernel text virtual address can be randomized in region [0xffffffff80000000, 0xffffffffc0000000).

***Problems we need solved:
- For kernel boot from startup_32 case, only 0~4G identity mapping is built. If kernel will be randomly put anywhere from 16M to 64T at most, the price to build all region of identity mapping is too high. We need build the identity mapping on demand, not covering all physical address space.

- Decouple the physical address and virtual address randomization of kernel text and let them work separately.

***Parts:
- The 1st part is Yinghai's identity mapping building on demand patches. This is used to solve the first problem mentioned above. (Patch 09-10/19)
- The 2nd part is decoupling the physical address and virtual address randomization of kernel text and letting them work separately patches based on Yinghai's ident mapping patches.
(Patch 12-19/19)
- The 3rd part is some clean up patches which Yinghai found when he reviewed my patches and the related code around.
(Patch 01-08/19)

***Patch status:
This patchset went through several rounds of review.

v1:
- The first round can be found here:
https://lwn.net/Articles/637115/

v1->v2:
- In 2nd round Yinghai made a big patchset including this kaslr fix and another setup_data related fix. The link is here:
http://lists-archives.com/linux-kernel/28346903-x86-updated-patches-for-kaslr-and-setup_data-etc-for-v4-3.html
You can get the code from Yinghai's git branch:
git://git.kernel.org/pub/scm/linux/kernel/git/yinghai/linux-yinghai.git for-x86-v4.3-next

v2->v3:
- It only takes care of the kaslr related patches.
For reviewers it's better to discuss only one issue in one thread.
* I take off one patch as follows from Yinghai's because I think it's unnecessay.
- Patch 05/19 x86, kaslr: rename output_size to output_run_size output_size is enough to represen the value:
output_len > run_size ? output_len : run_size

* I add Patch 04/19, it's a comment update patch. For other patches, I just adjust patch log and do several places of change comparing with 2nd round. Please check the change log under patch log of each patch for details.

* Adjust sequence of several patches to make review easier. It doesn't affect codes.

v3->v4:
- Made changes according to Kees's comments.
Add one patch 20/20 as Kees suggested to use KERNEL_IMAGE_SIZE as offset max of virtual random, meanwhile clean up useless CONFIG_RANDOM_OFFSET_MAX

x86, kaslr: Use KERNEL_IMAGE_SIZE as the offset max for kernel virtual randomization

You can also get this patchset from my github:
https://github.com/baoquan-he/linux.git kaslr-above-4G

Any comments about code changes, code comments, patch logs are welcome and appreciated.

Baoquan He (9):
x86, kaslr: Fix a bug that relocation can not be handled when kernel
is loaded above 2G
x86, kaskr: Update the description for decompressor worst case x86, kaslr: Introduce struct slot_area to manage randomization slot
info
x86, kaslr: Add two functions which will be used later x86, kaslr: Introduce fetch_random_virt_offset to randomize the kernel
text mapping address
x86, kaslr: Randomize physical and virtual address of kernel
separately
x86, kaslr: Add support of kernel physical address randomization above

    4G

x86, kaslr: Remove useless codes
x86, kaslr: Use KERNEL_IMAGE_SIZE as the offset max for kernel virtual
randomization

Yinghai Lu (11):
x86, kaslr: Remove not needed parameter for choose_kernel_location x86, boot: Move compressed kernel to end of buffer before
decompressing
x86, boot: Move z_extract_offset calculation to header.S x86, boot: Fix run_size calculation
x86, kaslr: Clean up useless code related to run_size. x86, kaslr: Get correct max_addr for relocs pointer x86, kaslr: Consolidate mem_avoid array filling
x86, boot: Split kernel_ident_mapping_init to another file x86, 64bit: Set ident_mapping for kaslr
x86, boot: Add checking for memcpy
x86, kaslr: Allow random address to be below loaded address

 arch/x86/Kconfig                       |  57 +++----
 arch/x86/boot/Makefile                 |  13 +-
 arch/x86/boot/compressed/Makefile      |  19 ++-
 arch/x86/boot/compressed/aslr.c        | 300 +++++++++++++++++++++++++--------
 arch/x86/boot/compressed/head_32.S     |  14 +-
 arch/x86/boot/compressed/head_64.S     |  15 +-
 arch/x86/boot/compressed/misc.c        |  89 +++++-----
 arch/x86/boot/compressed/misc.h        |  34 ++--
 arch/x86/boot/compressed/misc_pgt.c    |  93 ++++++++++
 arch/x86/boot/compressed/mkpiggy.c     |  28 +--
 arch/x86/boot/compressed/string.c      |  29 +++-
 arch/x86/boot/compressed/vmlinux.lds.S |   1 +
 arch/x86/boot/header.S                 |  22 ++-
 arch/x86/include/asm/boot.h            |  19 +++
 arch/x86/include/asm/page.h            |   5 +
 arch/x86/include/asm/page_64_types.h   |   5 +-
 arch/x86/kernel/asm-offsets.c          |   1 +
 arch/x86/kernel/vmlinux.lds.S          |   1 +
 arch/x86/mm/ident_map.c                |  74 ++++++++
 arch/x86/mm/init_32.c                  |   3 -
 arch/x86/mm/init_64.c                  |  74 +-------
 arch/x86/tools/calc_run_size.sh        |  42 -----
 22 files changed, 605 insertions(+), 333 deletions(-)
 create mode 100644 arch/x86/boot/compressed/misc_pgt.c
 create mode 100644 arch/x86/mm/ident_map.c
 delete mode 100644 arch/x86/tools/calc_run_size.sh

--
2.5.0

Quoted 80 lines · Baoquan He

***Background:
Previously a bug is reported that kdump didn't work when kaslr is enabled. During discussing that bug fix, we found current kaslr has a limilation that it can only randomize in 1GB region.

This is because in curent kaslr implementaion only physical address of kernel loading is randomized. Then calculate the delta of physical address where vmlinux was linked to load and where it is finally loaded. If delta is not equal to 0, namely there's a new physical address where kernel is actually decompressed, relocation handling need be done. Then delta is added to offset of kernel symbol relocation, this makes the address of kernel text mapping move delta long. Though in principle kernel can be randomized to any physical address, kernel text mapping address space is limited and only 1G, namely as follows on x86_64:

        [0xffffffff80000000, 0xffffffffc0000000)

In one word, kernel text physical address and virtual address randomization is coupled. This causes the limitation.

Then hpa and Vivek suggested we should change this. To decouple the physical address and virtual address randomization of kernel text and let them work separately. Then kernel text physical address can be randomized in region [16M, 64T), and kernel text virtual address can be randomized in region [0xffffffff80000000, 0xffffffffc0000000).

***Problems we need solved:
- For kernel boot from startup_32 case, only 0~4G identity mapping is built. If kernel will be randomly put anywhere from 16M to 64T at most, the price to build all region of identity mapping is too high. We need build the identity mapping on demand, not covering all physical address space.

- Decouple the physical address and virtual address randomization of kernel text and let them work separately.

***Parts:
- The 1st part is Yinghai's identity mapping building on demand patches. This is used to solve the first problem mentioned above. (Patch 09-10/19)
- The 2nd part is decoupling the physical address and virtual address randomization of kernel text and letting them work separately patches based on Yinghai's ident mapping patches.
(Patch 12-19/19)
- The 3rd part is some clean up patches which Yinghai found when he reviewed my patches and the related code around.
(Patch 01-08/19)

***Patch status:
This patchset went through several rounds of review.

v1:
- The first round can be found here:
https://lwn.net/Articles/637115/

v1->v2:
- In 2nd round Yinghai made a big patchset including this kaslr fix and another setup_data related fix. The link is here:
http://lists-archives.com/linux-kernel/28346903-x86-updated-patches-for-kaslr-and-setup_data-etc-for-v4-3.html
You can get the code from Yinghai's git branch:
git://git.kernel.org/pub/scm/linux/kernel/git/yinghai/linux-yinghai.git for-x86-v4.3-next

v2->v3:
- It only takes care of the kaslr related patches.
For reviewers it's better to discuss only one issue in one thread.
* I take off one patch as follows from Yinghai's because I think it's unnecessay.
- Patch 05/19 x86, kaslr: rename output_size to output_run_size output_size is enough to represen the value:
output_len > run_size ? output_len : run_size

* I add Patch 04/19, it's a comment update patch. For other patches, I just adjust patch log and do several places of change comparing with 2nd round. Please check the change log under patch log of each patch for details.

* Adjust sequence of several patches to make review easier. It doesn't affect codes.

v3->v4:
- Made changes according to Kees's comments.
Add one patch 20/20 as Kees suggested to use KERNEL_IMAGE_SIZE as offset max of virtual random, meanwhile clean up useless CONFIG_RANDOM_OFFSET_MAX

Quoted 1 line

x86, kaslr: Use KERNEL_IMAGE_SIZE as the offset max for kernel virtual randomization

This series is looking good to me. I'm running tests under qemu now, and things appear to work as advertised. :) I'll report back once I've booted a few hundred times.

Ingo, what do you think of getting this into the x86 tree for some testing in -next? For stuff I haven't already Acked, consider the whole series as:

Reviewed-by Kees Cook <[email protected]>

***Background:
Previously a bug is reported that kdump didn't work when kaslr is enabled. During discussing that bug fix, we found current kaslr has a limilation that it can only randomize in 1GB region.

This is because in curent kaslr implementaion only physical address of kernel loading is randomized. Then calculate the delta of physical address where vmlinux was linked to load and where it is finally loaded. If delta is not equal to 0, namely there's a new physical address where kernel is actually decompressed, relocation handling need be done. Then delta is added to offset of kernel symbol relocation, this makes the address of kernel text mapping move delta long. Though in principle kernel can be randomized to any physical address, kernel text mapping address space is limited and only 1G, namely as follows on x86_64:

	[0xffffffff80000000, 0xffffffffc0000000)

In one word, kernel text physical address and virtual address randomization is coupled. This causes the limitation.

Then hpa and Vivek suggested we should change this. To decouple the physical address and virtual address randomization of kernel text and let them work separately. Then kernel text physical address can be randomized in region [16M, 64T), and kernel text virtual address can be randomized in region [0xffffffff80000000, 0xffffffffc0000000).

***Problems we need solved:
- For kernel boot from startup_32 case, only 0~4G identity mapping is built. If kernel will be randomly put anywhere from 16M to 64T at most, the price to build all region of identity mapping is too high. We need build the identity mapping on demand, not covering all physical address space.

- Decouple the physical address and virtual address randomization of kernel text and let them work separately.

***Parts:
- The 1st part is Yinghai's identity mapping building on demand patches. This is used to solve the first problem mentioned above. (Patch 09-10/19)
- The 2nd part is decoupling the physical address and virtual address randomization of kernel text and letting them work separately patches based on Yinghai's ident mapping patches.
(Patch 12-19/19)
- The 3rd part is some clean up patches which Yinghai found when he reviewed my patches and the related code around.
(Patch 01-08/19)

***Patch status:
This patchset went through several rounds of review.

v1:
- The first round can be found here:
https://lwn.net/Articles/637115/

v1->v2:
- In 2nd round Yinghai made a big patchset including this kaslr fix and another setup_data related fix. The link is here:
http://lists-archives.com/linux-kernel/28346903-x86-updated-patches-for-kaslr-and-setup_data-etc-for-v4-3.html
You can get the code from Yinghai's git branch:
git://git.kernel.org/pub/scm/linux/kernel/git/yinghai/linux-yinghai.git for-x86-v4.3-next

v2->v3:
- It only takes care of the kaslr related patches.
For reviewers it's better to discuss only one issue in one thread.
* I take off one patch as follows from Yinghai's because I think it's unnecessay.
- Patch 05/19 x86, kaslr: rename output_size to output_run_size output_size is enough to represen the value:
output_len > run_size ? output_len : run_size

* I add Patch 04/19, it's a comment update patch. For other patches, I just adjust patch log and do several places of change comparing with 2nd round. Please check the change log under patch log of each patch for details.

* Adjust sequence of several patches to make review easier. It doesn't affect codes.

v3->v4:
- Made changes according to Kees's comments.
Add one patch 20/20 as Kees suggested to use KERNEL_IMAGE_SIZE as offset max of virtual random, meanwhile clean up useless CONFIG_RANDOM_OFFSET_MAX

x86, kaslr: Use KERNEL_IMAGE_SIZE as the offset max for kernel virtual randomization

You can also get this patchset from my github:
https://github.com/baoquan-he/linux.git kaslr-above-4G

Any comments about code changes, code comments, patch logs are welcome and appreciated.

Baoquan He (9):
x86, kaslr: Fix a bug that relocation can not be handled when kernel
is loaded above 2G
x86, kaskr: Update the description for decompressor worst case x86, kaslr: Introduce struct slot_area to manage randomization slot
info
x86, kaslr: Add two functions which will be used later x86, kaslr: Introduce fetch_random_virt_offset to randomize the kernel
text mapping address
x86, kaslr: Randomize physical and virtual address of kernel
separately
x86, kaslr: Add support of kernel physical address randomization above

    4G

x86, kaslr: Remove useless codes
x86, kaslr: Use KERNEL_IMAGE_SIZE as the offset max for kernel virtual
randomization

Yinghai Lu (11):
x86, kaslr: Remove not needed parameter for choose_kernel_location x86, boot: Move compressed kernel to end of buffer before
decompressing
x86, boot: Move z_extract_offset calculation to header.S x86, boot: Fix run_size calculation
x86, kaslr: Clean up useless code related to run_size. x86, kaslr: Get correct max_addr for relocs pointer x86, kaslr: Consolidate mem_avoid array filling
x86, boot: Split kernel_ident_mapping_init to another file x86, 64bit: Set ident_mapping for kaslr
x86, boot: Add checking for memcpy
x86, kaslr: Allow random address to be below loaded address

 arch/x86/Kconfig                       |  57 +++----
 arch/x86/boot/Makefile                 |  13 +-
 arch/x86/boot/compressed/Makefile      |  19 ++-
 arch/x86/boot/compressed/aslr.c        | 300 +++++++++++++++++++++++++--------
 arch/x86/boot/compressed/head_32.S     |  14 +-
 arch/x86/boot/compressed/head_64.S     |  15 +-
 arch/x86/boot/compressed/misc.c        |  89 +++++-----
 arch/x86/boot/compressed/misc.h        |  34 ++--
 arch/x86/boot/compressed/misc_pgt.c    |  93 ++++++++++
 arch/x86/boot/compressed/mkpiggy.c     |  28 +--
 arch/x86/boot/compressed/string.c      |  29 +++-
 arch/x86/boot/compressed/vmlinux.lds.S |   1 +
 arch/x86/boot/header.S                 |  22 ++-
 arch/x86/include/asm/boot.h            |  19 +++
 arch/x86/include/asm/page.h            |   5 +
 arch/x86/include/asm/page_64_types.h   |   5 +-
 arch/x86/kernel/asm-offsets.c          |   1 +
 arch/x86/kernel/vmlinux.lds.S          |   1 +
 arch/x86/mm/ident_map.c                |  74 ++++++++
 arch/x86/mm/init_32.c                  |   3 -
 arch/x86/mm/init_64.c                  |  74 +-------
 arch/x86/tools/calc_run_size.sh        |  42 -----
 22 files changed, 605 insertions(+), 333 deletions(-)
 create mode 100644 arch/x86/boot/compressed/misc_pgt.c
 create mode 100644 arch/x86/mm/ident_map.c
 delete mode 100644 arch/x86/tools/calc_run_size.sh

Signature · 1 line

2.5.0

Quoted 137 lines · Baoquan He

***Background:
Previously a bug is reported that kdump didn't work when kaslr is enabled. During discussing that bug fix, we found current kaslr has a limilation that it can only randomize in 1GB region.

This is because in curent kaslr implementaion only physical address of kernel loading is randomized. Then calculate the delta of physical address where vmlinux was linked to load and where it is finally loaded. If delta is not equal to 0, namely there's a new physical address where kernel is actually decompressed, relocation handling need be done. Then delta is added to offset of kernel symbol relocation, this makes the address of kernel text mapping move delta long. Though in principle kernel can be randomized to any physical address, kernel text mapping address space is limited and only 1G, namely as follows on x86_64:

      [0xffffffff80000000, 0xffffffffc0000000)

In one word, kernel text physical address and virtual address randomization is coupled. This causes the limitation.

Then hpa and Vivek suggested we should change this. To decouple the physical address and virtual address randomization of kernel text and let them work separately. Then kernel text physical address can be randomized in region [16M, 64T), and kernel text virtual address can be randomized in region [0xffffffff80000000, 0xffffffffc0000000).

***Problems we need solved:
- For kernel boot from startup_32 case, only 0~4G identity mapping is built. If kernel will be randomly put anywhere from 16M to 64T at most, the price to build all region of identity mapping is too high. We need build the identity mapping on demand, not covering all physical address space.

- Decouple the physical address and virtual address randomization of kernel text and let them work separately.

***Parts:
- The 1st part is Yinghai's identity mapping building on demand patches. This is used to solve the first problem mentioned above. (Patch 09-10/19)
- The 2nd part is decoupling the physical address and virtual address randomization of kernel text and letting them work separately patches based on Yinghai's ident mapping patches.
(Patch 12-19/19)
- The 3rd part is some clean up patches which Yinghai found when he reviewed my patches and the related code around.
(Patch 01-08/19)

***Patch status:
This patchset went through several rounds of review.

v1:
- The first round can be found here:
https://lwn.net/Articles/637115/

v1->v2:
- In 2nd round Yinghai made a big patchset including this kaslr fix and another setup_data related fix. The link is here:
http://lists-archives.com/linux-kernel/28346903-x86-updated-patches-for-kaslr-and-setup_data-etc-for-v4-3.html
You can get the code from Yinghai's git branch:
git://git.kernel.org/pub/scm/linux/kernel/git/yinghai/linux-yinghai.git for-x86-v4.3-next

v2->v3:
- It only takes care of the kaslr related patches.
For reviewers it's better to discuss only one issue in one thread.
* I take off one patch as follows from Yinghai's because I think it's unnecessay.
- Patch 05/19 x86, kaslr: rename output_size to output_run_size output_size is enough to represen the value:
output_len > run_size ? output_len : run_size

* I add Patch 04/19, it's a comment update patch. For other patches, I just adjust patch log and do several places of change comparing with 2nd round. Please check the change log under patch log of each patch for details.

* Adjust sequence of several patches to make review easier. It doesn't affect codes.

v3->v4:
- Made changes according to Kees's comments.
Add one patch 20/20 as Kees suggested to use KERNEL_IMAGE_SIZE as offset max of virtual random, meanwhile clean up useless CONFIG_RANDOM_OFFSET_MAX

x86, kaslr: Use KERNEL_IMAGE_SIZE as the offset max for kernel virtual randomization

You can also get this patchset from my github:
https://github.com/baoquan-he/linux.git kaslr-above-4G

Any comments about code changes, code comments, patch logs are welcome and appreciated.

Baoquan He (9):
x86, kaslr: Fix a bug that relocation can not be handled when kernel
is loaded above 2G
x86, kaskr: Update the description for decompressor worst case x86, kaslr: Introduce struct slot_area to manage randomization slot
info
x86, kaslr: Add two functions which will be used later x86, kaslr: Introduce fetch_random_virt_offset to randomize the kernel
text mapping address
x86, kaslr: Randomize physical and virtual address of kernel
separately
x86, kaslr: Add support of kernel physical address randomization above

    4G

x86, kaslr: Remove useless codes
x86, kaslr: Use KERNEL_IMAGE_SIZE as the offset max for kernel virtual
randomization

Yinghai Lu (11):
x86, kaslr: Remove not needed parameter for choose_kernel_location x86, boot: Move compressed kernel to end of buffer before
decompressing
x86, boot: Move z_extract_offset calculation to header.S x86, boot: Fix run_size calculation
x86, kaslr: Clean up useless code related to run_size. x86, kaslr: Get correct max_addr for relocs pointer x86, kaslr: Consolidate mem_avoid array filling
x86, boot: Split kernel_ident_mapping_init to another file x86, 64bit: Set ident_mapping for kaslr
x86, boot: Add checking for memcpy
x86, kaslr: Allow random address to be below loaded address

 arch/x86/Kconfig                       |  57 +++----
 arch/x86/boot/Makefile                 |  13 +-
 arch/x86/boot/compressed/Makefile      |  19 ++-
 arch/x86/boot/compressed/aslr.c        | 300 +++++++++++++++++++++++++--------
 arch/x86/boot/compressed/head_32.S     |  14 +-
 arch/x86/boot/compressed/head_64.S     |  15 +-
 arch/x86/boot/compressed/misc.c        |  89 +++++-----
 arch/x86/boot/compressed/misc.h        |  34 ++--
 arch/x86/boot/compressed/misc_pgt.c    |  93 ++++++++++
 arch/x86/boot/compressed/mkpiggy.c     |  28 +--
 arch/x86/boot/compressed/string.c      |  29 +++-
 arch/x86/boot/compressed/vmlinux.lds.S |   1 +
 arch/x86/boot/header.S                 |  22 ++-
 arch/x86/include/asm/boot.h            |  19 +++
 arch/x86/include/asm/page.h            |   5 +
 arch/x86/include/asm/page_64_types.h   |   5 +-
 arch/x86/kernel/asm-offsets.c          |   1 +
 arch/x86/kernel/vmlinux.lds.S          |   1 +

Quoted 9 lines

 arch/x86/mm/ident_map.c                |  74 ++++++++
 arch/x86/mm/init_32.c                  |   3 -
 arch/x86/mm/init_64.c                  |  74 +-------
 arch/x86/tools/calc_run_size.sh        |  42 -----
 22 files changed, 605 insertions(+), 333 deletions(-)
 create mode 100644 arch/x86/boot/compressed/misc_pgt.c
 create mode 100644 arch/x86/mm/ident_map.c
 delete mode 100644 arch/x86/tools/calc_run_size.sh

Hi Ingo,

Ping.

Do you have any suggestions or comments for this patchset? As you suggested for Yinghai's earlier post, I re-check the whole patchset and try to understand them all, and try to re-write patch logs with my own understanding. I hope this patch logs can help people who are interested in this issue can understand what the patch is doing. Meanwhile Kees is very kind to help review the code change and patch log, help adjust or re-write some of them.

If still there's something you don't like, your suggestions, ideas and comments are welcome and appreciated. I will continue making changes until it's satisfactory.

FWIW, I've also had this tree up in my git branches, and the 0day tester hasn't complained at all about it in the last two weeks. I'd really like to see this in -next to fix the >4G (mainly kexec) issues and get us to feature parity with the arm64 kASLR work (randomized virtual address).

Current z_extract_offset is calculated in boot/compressed/mkpiggy.c. The problem is in mkpiggy.c we don't know the detail of decompressor. Then we just get a rough z_extract_offset according to extra_bytes. As we know extra_bytes can only promise a safety margin when decompressing. In fact this brings some risks:

Currently z_extract_offset is calculated during kernel build time. The problem with that method is that at this stage we don't yet know the decompression buffer sizes - we only know that during bootup.

Effects of this are that when we calculate z_extract_offset during the build we don't know the precise decompression details, we'll only get a rough estimation of z_extract_offset.

Instead of that we want to calculate it during bootup.

Quoted 5 lines · Kees Cook

FWIW, I've also had this tree up in my git branches, and the 0day tester hasn't complained at all about it in the last two weeks. I'd really like to see this in -next to fix the >4G (mainly kexec) issues and get us to feature parity with the arm64 kASLR work (randomized virtual address).

So I started applying the patches, started fixing up changelogs and gave up on patch #3.

Changelogs of such non-trivial code need to be proper English and need to be understandable.

For example patch #3 starts with:

Quoted 4 lines

Current z_extract_offset is calculated in boot/compressed/mkpiggy.c. The problem is in mkpiggy.c we don't know the detail of decompressor. Then we just get a rough z_extract_offset according to extra_bytes. As we know extra_bytes can only promise a safety margin when decompressing. In fact this brings some risks:

Beyond the bad grammar of the _first word_ of the changelog, this is not a proper high level description of the change. A _real_ high level description would be something like:

Quoted 9 lines

Currently z_extract_offset is calculated during kernel build time. The problem with that method is that at this stage we don't yet know the decompression buffer sizes - we only know that during bootup.

Effects of this are that when we calculate z_extract_offset during the build we don't know the precise decompression details, we'll only get a rough estimation of z_extract_offset.

Instead of that we want to calculate it during bootup.

etc. etc. - the whole series is _full_ of such crappy changelogs that make it difficult for me and others to see whether the author actually _understands_ the existing code or is hacking away on it. It's also much harder to review and validate.

This is totally unacceptable.

Please make sure every changelog starts with a proper high level description that tells the story and convinces the reader about what the problem is and what the change should be.

And part of that are the patch titles. Things like:

Subject: [PATCH v3 03/19] x86, boot: Move z_extract_offset calculation to header.S

are absolutely mindless titles. A better title would be:

x86/boot: Calculate precise decompressor parameters during bootup, not build time

... or something like that. Even having read the changelog 3 times I'm unsure what the change really is about.

Quoted 8 lines · Ingo Molnar

Quoted 5 lines · Kees Cook

FWIW, I've also had this tree up in my git branches, and the 0day tester hasn't complained at all about it in the last two weeks. I'd really like to see this in -next to fix the >4G (mainly kexec) issues and get us to feature parity with the arm64 kASLR work (randomized virtual address).

Quoted 9 lines · Kees Cook

Quoted 8 lines · Ingo Molnar

Quoted 5 lines · Kees Cook

FWIW, I've also had this tree up in my git branches, and the 0day tester hasn't complained at all about it in the last two weeks. I'd really like to see this in -next to fix the >4G (mainly kexec) issues and get us to feature parity with the arm64 kASLR work (randomized virtual address).

So, I've done this and suddenly realized I hadn't boot-tested i386. It doesn't work, unfortunately. (Which I find strange: I'd expect 0day to have noticed...)

Baoquan, have you tested this on 32-bit systems? I get a variety of failures. Either it boots okay, it reboots, or I get tons of pte errors like this:

[    0.000000] clearing pte for ram above max_low_pfn: pfn: 37dcc pmd:

f9144f7c pmd phys: 39144f7c pte: f9a1b730 pte phys: 39a1b730

Can you confirm? I suspect relocation problems, but ran out of time today to debug it.

I have the entire series with cleaned up changelogs and various other refactorings up here now:

http://git.kernel.org/cgit/linux/kernel/git/kees/linux.git/log/?h=kaslr/highmem

Thanks!

-Kees

Signature · 2 lines

Kees Cook
Chrome OS & Brillo Security

Quoted 9 lines · Kees Cook

Quoted 8 lines · Ingo Molnar

Quoted 5 lines · Kees Cook

FWIW, I've also had this tree up in my git branches, and the 0day tester hasn't complained at all about it in the last two weeks. I'd really like to see this in -next to fix the >4G (mainly kexec) issues and get us to feature parity with the arm64 kASLR work (randomized virtual address).

So, I've done this and suddenly realized I hadn't boot-tested i386. It doesn't work, unfortunately. (Which I find strange: I'd expect 0day to have noticed...)

Baoquan, have you tested this on 32-bit systems? I get a variety of failures. Either it boots okay, it reboots, or I get tons of pte errors like this:

[    0.000000] clearing pte for ram above max_low_pfn: pfn: 37dcc pmd:

f9144f7c pmd phys: 39144f7c pte: f9a1b730 pte phys: 39a1b730

Can you confirm? I suspect relocation problems, but ran out of time today to debug it.

I have the entire series with cleaned up changelogs and various other refactorings up here now:

http://git.kernel.org/cgit/linux/kernel/git/kees/linux.git/log/?h=kaslr/highmem

Thanks!

-Kees

Signature · 2 lines

Kees Cook
Chrome OS & Brillo Security

Quoted 11 lines · Kees Cook

Quoted 9 lines · Kees Cook

Quoted 8 lines · Ingo Molnar

Quoted 5 lines · Kees Cook

FWIW, I've also had this tree up in my git branches, and the 0day tester hasn't complained at all about it in the last two weeks. I'd really like to see this in -next to fix the >4G (mainly kexec) issues and get us to feature parity with the arm64 kASLR work (randomized virtual address).

Quoted 7 lines

So, I've done this and suddenly realized I hadn't boot-tested i386. It doesn't work, unfortunately. (Which I find strange: I'd expect 0day to have noticed...)

Baoquan, have you tested this on 32-bit systems? I get a variety of failures. Either it boots okay, it reboots, or I get tons of pte errors like this:

Hi Kees,

I am sorry I didn't notice the change impacts i386. I got a i386 machine and had tests. Found i386 can't take separate randomzation since there's difference between i386 and x86_64.

x86_64 has phys_base and can translate virt addr and phys addr according to below formula:

paddr = vaddr - __START_KERNEL_map + phys_base;

However i386 can only do like this:

paddr = vaddr - PAGE_OFFSET;

Besides i386 has to reserve 128M for VMALLOC at the end of kernel virtual address. So for i386 area 768M is the upper limit for randomization. But I am fine with the KERNEL_IMAGE_SIZE, the old default value. What do you say about this?

So the plan should be keeping the old style of randomization for i386 system:

1) Disable virtual address randomization in i386 case because it's useless. This should be done in patch:
x86, KASLR: Randomize virtual address separately

2) Add an upper limit for physical randomization if it's i386 system. x86, KASLR: Add physical address randomization >4G

I just got a test machine in office, and haven't had time to change code. You can change it directly, or I will do it tomorrow.

Thanks

Quoted 19 lines

[    0.000000] clearing pte for ram above max_low_pfn: pfn: 37dcc pmd:

f9144f7c pmd phys: 39144f7c pte: f9a1b730 pte phys: 39a1b730

Can you confirm? I suspect relocation problems, but ran out of time today to debug it.

I have the entire series with cleaned up changelogs and various other refactorings up here now:

http://git.kernel.org/cgit/linux/kernel/git/kees/linux.git/log/?h=kaslr/highmem

Thanks!

-Kees

--
Kees Cook
Chrome OS & Brillo Security

Quoted 47 lines · Baoquan He

Quoted 11 lines · Kees Cook

Quoted 9 lines · Kees Cook

Quoted 8 lines · Ingo Molnar

Quoted 5 lines · Kees Cook

FWIW, I've also had this tree up in my git branches, and the 0day tester hasn't complained at all about it in the last two weeks. I'd really like to see this in -next to fix the >4G (mainly kexec) issues and get us to feature parity with the arm64 kASLR work (randomized virtual address).

Quoted 7 lines

So, I've done this and suddenly realized I hadn't boot-tested i386. It doesn't work, unfortunately. (Which I find strange: I'd expect 0day to have noticed...)

Baoquan, have you tested this on 32-bit systems? I get a variety of failures. Either it boots okay, it reboots, or I get tons of pte errors like this:

Hi Kees,

I am sorry I didn't notice the change impacts i386. I got a i386 machine and had tests. Found i386 can't take separate randomzation since there's difference between i386 and x86_64.

x86_64 has phys_base and can translate virt addr and phys addr according to below formula:

paddr = vaddr - __START_KERNEL_map + phys_base;

However i386 can only do like this:

paddr = vaddr - PAGE_OFFSET;

Besides i386 has to reserve 128M for VMALLOC at the end of kernel virtual address. So for i386 area 768M is the upper limit for randomization. But I am fine with the KERNEL_IMAGE_SIZE, the old default value. What do you say about this?

So the plan should be keeping the old style of randomization for i386 system:

1) Disable virtual address randomization in i386 case because it's useless. This should be done in patch:
x86, KASLR: Randomize virtual address separately

Quoted 5 lines

2) Add an upper limit for physical randomization if it's i386 system. x86, KASLR: Add physical address randomization >4G

I just got a test machine in office, and haven't had time to change code. You can change it directly, or I will do it tomorrow.

I was thinking about the physical vs virtual on i386 as I woke up today. :) Thanks for confirming! These changes appear to make the series boot reliably on i386 (pardon any gmail-induced whitespace damage...):

arch/x86/boot/compressed/aslr.c +12 -1

index 5bae54b50d4c..3a58fe8acb8e 100644
@@ -347,6 +347,10 @@ static void process_e820_entry(struct e820entry *entry,
        if (entry->type != E820_RAM)
                return;
 
+       /* On 32-bit, ignore entries entirely above our maximum. */
+       if (IS_ENABLED(CONFIG_X86_32) && entry->addr >= KERNEL_IMAGE_SIZE)
+               return;
+
        /* Ignore entries entirely below our minimum. */
        if (entry->addr + entry->size < minimum)
                return;

@@ -372,6 +376,11 @@ static void process_e820_entry(struct e820entry *entry,
                /* Reduce size by any delta from the original address. */
                region.size -= region.start - start_orig;
 
+               /* On 32-bit, reduce region size to fit within max size. */
+               if (IS_ENABLED(CONFIG_X86_32) &&
+                   region.start + region.size > KERNEL_IMAGE_SIZE)
+                       region.size = KERNEL_IMAGE_SIZE - region.start;
+
                /* Return if region can't contain decompressed kernel */
                if (region.size < image_size)
                        return;

@@ -488,6 +497,8 @@ void choose_kernel_location(unsigned char *input,
        }
 
        /* Pick random virtual address starting from LOAD_PHYSICAL_ADDR. */
-       random = find_random_virt_offset(LOAD_PHYSICAL_ADDR, output_size);
+       if (IS_ENABLED(CONFIG_X86_64))
+               random = find_random_virt_offset(LOAD_PHYSICAL_ADDR,
+                                                output_size);
        *virt_offset = (unsigned char *)random;
 }

I will split these chunks up into the correct patches and resend the series. If you get a chance, can you double-check this?

Quoted 98 lines · Kees Cook

Quoted 47 lines · Baoquan He

Quoted 11 lines · Kees Cook

Quoted 9 lines · Kees Cook

Quoted 8 lines · Ingo Molnar

Quoted 5 lines · Kees Cook

FWIW, I've also had this tree up in my git branches, and the 0day tester hasn't complained at all about it in the last two weeks. I'd really like to see this in -next to fix the >4G (mainly kexec) issues and get us to feature parity with the arm64 kASLR work (randomized virtual address).

Quoted 7 lines

So, I've done this and suddenly realized I hadn't boot-tested i386. It doesn't work, unfortunately. (Which I find strange: I'd expect 0day to have noticed...)

Baoquan, have you tested this on 32-bit systems? I get a variety of failures. Either it boots okay, it reboots, or I get tons of pte errors like this:

Hi Kees,

I am sorry I didn't notice the change impacts i386. I got a i386 machine and had tests. Found i386 can't take separate randomzation since there's difference between i386 and x86_64.

x86_64 has phys_base and can translate virt addr and phys addr according to below formula:

paddr = vaddr - __START_KERNEL_map + phys_base;

However i386 can only do like this:

paddr = vaddr - PAGE_OFFSET;

Besides i386 has to reserve 128M for VMALLOC at the end of kernel virtual address. So for i386 area 768M is the upper limit for randomization. But I am fine with the KERNEL_IMAGE_SIZE, the old default value. What do you say about this?

So the plan should be keeping the old style of randomization for i386 system:

1) Disable virtual address randomization in i386 case because it's useless. This should be done in patch:
x86, KASLR: Randomize virtual address separately

Quoted 5 lines

2) Add an upper limit for physical randomization if it's i386 system. x86, KASLR: Add physical address randomization >4G

I just got a test machine in office, and haven't had time to change code. You can change it directly, or I will do it tomorrow.

I was thinking about the physical vs virtual on i386 as I woke up today. :) Thanks for confirming! These changes appear to make the series boot reliably on i386 (pardon any gmail-induced whitespace damage...):

arch/x86/boot/compressed/aslr.c +12 -1

index 5bae54b50d4c..3a58fe8acb8e 100644
@@ -347,6 +347,10 @@ static void process_e820_entry(struct e820entry *entry,
        if (entry->type != E820_RAM)
                return;
 
+       /* On 32-bit, ignore entries entirely above our maximum. */
+       if (IS_ENABLED(CONFIG_X86_32) && entry->addr >= KERNEL_IMAGE_SIZE)
+               return;
+
        /* Ignore entries entirely below our minimum. */
        if (entry->addr + entry->size < minimum)
                return;

@@ -372,6 +376,11 @@ static void process_e820_entry(struct e820entry *entry,
                /* Reduce size by any delta from the original address. */
                region.size -= region.start - start_orig;
 
+               /* On 32-bit, reduce region size to fit within max size. */
+               if (IS_ENABLED(CONFIG_X86_32) &&
+                   region.start + region.size > KERNEL_IMAGE_SIZE)
+                       region.size = KERNEL_IMAGE_SIZE - region.start;
+
                /* Return if region can't contain decompressed kernel */
                if (region.size < image_size)
                        return;

@@ -488,6 +497,8 @@ void choose_kernel_location(unsigned char *input,
        }
 
        /* Pick random virtual address starting from LOAD_PHYSICAL_ADDR. */
-       random = find_random_virt_offset(LOAD_PHYSICAL_ADDR, output_size);
+       if (IS_ENABLED(CONFIG_X86_64))
+               random = find_random_virt_offset(LOAD_PHYSICAL_ADDR,
+                                                output_size);
        *virt_offset = (unsigned char *)random;
 }

Quoted 2 lines

I will split these chunks up into the correct patches and resend the series. If you get a chance, can you double-check this?

Yes, these changes sounds great. I checked the series you posted, and have to say you make them look much better. The change logs are perfect and great code refactoring. Just one little bit thing, here:

[kees: rewrote changelog, refactored goto into while, limit 32-bit to 1G] in patch [PATCH v5 19/21] x86, KASLR: Add physical address randomization >4G

In i386 KERNEL_IMAGE_SIZE is kept to be 0x20000000, namely 512M, w/o kaslr enabled. So here I guess it's a typo, should be "limit 32-bit to 1G". And what I said is wrong about upper limit yesterday, in fact i386 can put kernel in [16M, 896M), not 768M. But KERNEL_IMAGE_SIZE is good enough for i386 for now.

Quoted 10 lines · Baoquan He

Quoted 2 lines

I will split these chunks up into the correct patches and resend the series. If you get a chance, can you double-check this?

Yes, these changes sounds great. I checked the series you posted, and have to say you make them look much better. The change logs are perfect and great code refactoring. Just one little bit thing, here:

[kees: rewrote changelog, refactored goto into while, limit 32-bit to 1G] in patch [PATCH v5 19/21] x86, KASLR: Add physical address randomization >4G

Quoted 4 lines

In i386 KERNEL_IMAGE_SIZE is kept to be 0x20000000, namely 512M, w/o kaslr enabled. So here I guess it's a typo, should be "limit 32-bit to 1G". And what I said is wrong about upper limit yesterday, in fact i386 can put kernel in [16M, 896M), not 768M. But KERNEL_IMAGE_SIZE is good enough for i386 for now.

Ah yeah, thanks. If we do a v6, I'll update the typo. I was going to say "limit 32-bit to KERNEL_IMAGE_SIZE" but it was going to line-wrap.
:P