An error occurred fetching the project authors.
  1. 05 Jul, 2017 1 commit
  2. 26 Jun, 2016 1 commit
    • Baoquan He's avatar
      x86/KASLR: Randomize virtual address separately · 8391c73c
      Baoquan He authored
      The current KASLR implementation randomizes the physical and virtual
      addresses of the kernel together (both are offset by the same amount). It
      calculates the delta of the physical address where vmlinux was linked
      to load and where it is finally loaded. If the delta is not equal to 0
      (i.e. the kernel was relocated), relocation handling needs be done.
      
      On 64-bit, this patch randomizes both the physical address where kernel
      is decompressed and the virtual address where kernel text is mapped and
      will execute from. We now have two values being chosen, so the function
      arguments are reorganized to pass by pointer so they can be directly
      updated. Since relocation handling only depends on the virtual address,
      we must check the virtual delta, not the physical delta for processing
      kernel relocations. This also populates the page table for the new
      virtual address range. 32-bit does not support a separate virtual address,
      so it continues to use the physical offset for its virtual offset.
      
      Additionally updates the sanity checks done on the resulting kernel
      addresses since they are potentially separate now.
      
      [kees: rewrote changelog, limited virtual split to 64-bit only, update checks]
      [kees: fix CONFIG_RANDOMIZE_BASE=n boot failure]
      Signed-off-by: default avatarBaoquan He <bhe@redhat.com>
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: Dmitry Vyukov <dvyukov@google.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: H.J. Lu <hjl.tools@gmail.com>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Link: http://lkml.kernel.org/r/1464216334-17200-4-git-send-email-keescook@chromium.orgSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      8391c73c
  3. 07 May, 2016 1 commit
  4. 03 May, 2016 1 commit
    • Kees Cook's avatar
      x86/boot: Extract error reporting functions · dc425a6e
      Kees Cook authored
      Currently to use warn(), a caller would need to include misc.h. However,
      this means they would get the (unavailable during compressed boot)
      gcc built-in memcpy family of functions. But since string.c is defining
      these memcpy functions for use by misc.c, we end up in a weird circular
      dependency.
      
      To break this loop, move the error reporting functions outside of misc.c
      with their own header so that they can be independently included by
      other sources. Since the screen-writing routines use memmove(), keep the
      low-level *_putstr() functions in misc.c.
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Baoquan He <bhe@redhat.com>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Borislav Petkov <bp@suse.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Lasse Collin <lasse.collin@tukaani.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Link: http://lkml.kernel.org/r/1462229461-3370-2-git-send-email-keescook@chromium.orgSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      dc425a6e
  5. 29 Apr, 2016 5 commits
    • Yinghai Lu's avatar
      x86/boot: Correctly bounds-check relocations · 4abf061b
      Yinghai Lu authored
      Relocation handling performs bounds checking on the resulting calculated
      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.
      
      This patch adds an export for __bss_start in voffset.h and uses it to
      set the correct limit for max_addr.
      Signed-off-by: default avatarYinghai Lu <yinghai@kernel.org>
      [ Rewrote the changelog. ]
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Baoquan He <bhe@redhat.com>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Dave Young <dyoung@redhat.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Vivek Goyal <vgoyal@redhat.com>
      Cc: lasse.collin@tukaani.org
      Link: http://lkml.kernel.org/r/1461888548-32439-7-git-send-email-keescook@chromium.orgSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      4abf061b
    • Yinghai Lu's avatar
      x86/KASLR: Clean up unused code from old 'run_size' and rename it to 'kernel_total_size' · 4d2d5424
      Yinghai Lu authored
      Since 'run_size' is now calculated in misc.c, the old script and associated
      argument passing is no longer needed. This patch removes them, and renames
      'run_size' to the more descriptive 'kernel_total_size'.
      Signed-off-by: default avatarYinghai Lu <yinghai@kernel.org>
      Signed-off-by: default avatarBaoquan He <bhe@redhat.com>
      [ Rewrote the changelog, renamed 'run_size' to 'kernel_total_size' ]
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Dave Young <dyoung@redhat.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Josh Triplett <josh@joshtriplett.org>
      Cc: Junjie Mao <eternal.n08@gmail.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Vivek Goyal <vgoyal@redhat.com>
      Cc: lasse.collin@tukaani.org
      Link: http://lkml.kernel.org/r/1461888548-32439-6-git-send-email-keescook@chromium.orgSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      4d2d5424
    • Yinghai Lu's avatar
      x86/boot: Fix "run_size" calculation · 67b66625
      Yinghai Lu authored
      Currently, the "run_size" variable holds the total kernel size
      (size of code plus brk and bss) and is calculated via the shell script
      arch/x86/tools/calc_run_size.sh. It gets the file offset and mem size
      of the .bss and .brk sections from the vmlinux, and adds them as follows:
      
        run_size = $(( $offsetA + $sizeA + $sizeB ))
      
      However, this is not correct (it is too large). To illustrate, here's
      a walk-through of the script's calculation, compared to the correct way
      to find it.
      
      First, offsetA is found as the starting address of the first .bss or
      .brk section seen in the ELF file. The sizeA and sizeB values are the
      respective section sizes.
      
       [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, offsetA is 0x012c8000, with sizeA at 0x00170000 and sizeB at
      0x00027000. The resulting run_size is 0x145f000:
      
       0x012c8000 + 0x00170000 + 0x00027000 = 0x145f000
      
      However, if we instead examine the ELF LOAD program headers, we see a
      different picture.
      
       [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
      
      As mentioned, run_size needs to be the size of the running kernel
      including .bss and .brk. We can see from the Section/Segment mapping
      above that .bss and .brk are included in segment 03 (which corresponds
      to the final LOAD program header). To find the run_size, we calculate
      the end of the LOAD segment from its PhysAddr start (0x0000000001d5e000)
      and its MemSiz (0x0000000000301000), minus the physical load address of
      the kernel (the first LOAD segment's PhysAddr: 0x0000000001000000). The
      resulting run_size is 0x105f000:
      
       0x0000000001d5e000 + 0x0000000000301000 - 0x0000000001000000 = 0x105f000
      
      So, from this we can see that the existing run_size calculation is
      0x400000 too high. And, as it turns out, the correct run_size is
      actually equal to VO_end - VO_text, which is certainly easier to calculate.
      _end: 0xffffffff8205f000
      _text:0xffffffff81000000
      
       0xffffffff8205f000 - 0xffffffff81000000 = 0x105f000
      
      As a result, run_size is a simple constant, so we don't need to pass it
      around; we already have voffset.h for such things. We can share voffset.h
      between misc.c and header.S instead of getting run_size in other ways.
      This patch moves voffset.h creation code to boot/compressed/Makefile,
      and switches misc.c to use the VO_end - VO_text calculation for run_size.
      
      Dependence before:
      
       boot/header.S ==> boot/voffset.h ==> vmlinux
       boot/header.S ==> compressed/vmlinux ==> compressed/misc.c
      
      Dependence after:
      
       boot/header.S ==> compressed/vmlinux ==> compressed/misc.c ==> boot/voffset.h ==> vmlinux
      Signed-off-by: default avatarYinghai Lu <yinghai@kernel.org>
      Signed-off-by: default avatarBaoquan He <bhe@redhat.com>
      [ Rewrote the changelog. ]
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Dave Young <dyoung@redhat.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Josh Triplett <josh@joshtriplett.org>
      Cc: Junjie Mao <eternal.n08@gmail.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Vivek Goyal <vgoyal@redhat.com>
      Cc: lasse.collin@tukaani.org
      Fixes: e6023367 ("x86, kaslr: Prevent .bss from overlaping initrd")
      Link: http://lkml.kernel.org/r/1461888548-32439-5-git-send-email-keescook@chromium.orgSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      67b66625
    • Yinghai Lu's avatar
      x86/boot: Move compressed kernel to the end of the decompression buffer · 974f221c
      Yinghai Lu authored
      This change makes later calculations about where the kernel is located
      easier to reason about. To better understand this change, we must first
      clarify what 'VO' and 'ZO' are. These values were introduced in commits
      by hpa:
      
        77d1a499 ("x86, boot: make symbols from the main vmlinux available")
        37ba7ab5 ("x86, boot: make kernel_alignment adjustable; new bzImage fields")
      
      Specifically:
      
      All names prefixed with 'VO_':
      
       - relate to the uncompressed kernel image
      
       - the size of the VO image is: VO__end-VO__text ("VO_INIT_SIZE" define)
      
      All names prefixed with 'ZO_':
      
       - relate to the bootable compressed kernel image (boot/compressed/vmlinux),
         which is composed of the following memory areas:
           - head text
           - compressed kernel (VO image and relocs table)
           - decompressor code
      
       - the size of the ZO image is: ZO__end - ZO_startup_32 ("ZO_INIT_SIZE" define, though see below)
      
      The 'INIT_SIZE' value is used to find the larger of the two image sizes:
      
       #define ZO_INIT_SIZE    (ZO__end - ZO_startup_32 + ZO_z_extract_offset)
       #define VO_INIT_SIZE    (VO__end - VO__text)
      
       #if ZO_INIT_SIZE > VO_INIT_SIZE
       # define INIT_SIZE ZO_INIT_SIZE
       #else
       # define INIT_SIZE VO_INIT_SIZE
       #endif
      
      The current code uses extract_offset to decide where to position the
      copied ZO (i.e. ZO starts at extract_offset). (This is why ZO_INIT_SIZE
      currently includes the extract_offset.)
      
      Why does z_extract_offset exist? It's needed because we are trying to minimize
      the amount of RAM used for the whole act of creating an uncompressed, executable,
      properly relocation-linked kernel image in system memory. We do this so that
      kernels can be booted on even very small systems.
      
      To achieve the goal of minimal memory consumption we have implemented an in-place
      decompression strategy: instead of cleanly separating the VO and ZO images and
      also allocating some memory for the decompression code's runtime needs, we instead
      create this elaborate layout of memory buffers where the output (decompressed)
      stream, as it progresses, overlaps with and destroys the input (compressed)
      stream. This can only be done safely if the ZO image is placed to the end of the
      VO range, plus a certain amount of safety distance to make sure that when the last
      bytes of the VO range are decompressed, the compressed stream pointer is safely
      beyond the end of the VO range.
      
      z_extract_offset is calculated in arch/x86/boot/compressed/mkpiggy.c during
      the build process, at a point when we know the exact compressed and
      uncompressed size of the kernel images and can calculate this safe minimum
      offset value. (Note that the mkpiggy.c calculation is not perfect, because
      we don't know the decompressor used at that stage, so the z_extract_offset
      calculation is necessarily imprecise and is mostly based on gzip internals -
      we'll improve that in the next patch.)
      
      When INIT_SIZE is bigger than VO_INIT_SIZE (uncommon but possible),
      the copied ZO occupies the memory from extract_offset to the end of
      decompression buffer. It overlaps with the soon-to-be-uncompressed kernel
      like this:
      
                                  |-----compressed kernel image------|
                                  V                                  V
      0                       extract_offset                      +INIT_SIZE
      |-----------|---------------|-------------------------|--------|
                  |               |                         |        |
                VO__text      startup_32 of ZO          VO__end    ZO__end
                  ^                                         ^
                  |-------uncompressed kernel image---------|
      
      When INIT_SIZE is equal to VO_INIT_SIZE (likely) there's still space
      left from end of ZO to the end of decompressing buffer, like below.
      
                                  |-compressed kernel image-|
                                  V                         V
      0                       extract_offset                      +INIT_SIZE
      |-----------|---------------|-------------------------|--------|
                  |               |                         |        |
                VO__text      startup_32 of ZO          ZO__end    VO__end
                  ^                                                  ^
                  |------------uncompressed kernel image-------------|
      
      To simplify calculations and avoid special cases, it is cleaner to
      always place the compressed kernel image in memory so that ZO__end
      is at the end of the decompression buffer, instead of placing t at
      the start of extract_offset as is currently done.
      
      This patch adds BP_init_size (which is the INIT_SIZE as passed in from
      the boot_params) into asm-offsets.c to make it visible to the assembly
      code.
      
      Then when moving the ZO, it calculates the starting position of
      the copied ZO (via BP_init_size and the ZO run size) so that the VO__end
      will be at the end of the decompression buffer. To make the position
      calculation safe, the end of ZO is page aligned (and a comment is added
      to the existing VO alignment for good measure).
      Signed-off-by: default avatarYinghai Lu <yinghai@kernel.org>
      [ Rewrote changelog and comments. ]
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Baoquan He <bhe@redhat.com>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Dave Young <dyoung@redhat.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Vivek Goyal <vgoyal@redhat.com>
      Cc: lasse.collin@tukaani.org
      Link: http://lkml.kernel.org/r/1461888548-32439-3-git-send-email-keescook@chromium.org
      [ Rewrote the changelog some more. ]
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      974f221c
    • Baoquan He's avatar
      x86/KASLR: Handle kernel relocations above 2G correctly · 6f9af75f
      Baoquan He authored
      When processing the relocation table, the offset used to calculate the
      relocation is an 'int'. This is sufficient for calculating the physical
      address of the relocs entry on 32-bit systems and on 64-bit systems when
      the relocation is under 2G.
      
      To handle relocations above 2G (seen in situations like kexec, netboot, etc),
      this offset needs to be calculated using a 'long' to avoid wrapping and
      miscalculating the relocation.
      Signed-off-by: default avatarBaoquan He <bhe@redhat.com>
      [ Rewrote the changelog. ]
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Dave Young <dyoung@redhat.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Vivek Goyal <vgoyal@redhat.com>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Cc: lasse.collin@tukaani.org
      Link: http://lkml.kernel.org/r/1461888548-32439-2-git-send-email-keescook@chromium.orgSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      6f9af75f
  6. 28 Apr, 2016 1 commit
    • Kees Cook's avatar
      x86/boot: Rename overlapping memcpy() to memmove() · 81b785f3
      Kees Cook authored
      Instead of having non-standard memcpy() behavior, explicitly call the new
      function memmove(), make it available to the decompressors, and switch
      the two overlap cases (screen scrolling and ELF parsing) to use memmove().
      Additionally documents the purpose of compressed/string.c.
      Suggested-by: default avatarLasse Collin <lasse.collin@tukaani.org>
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Baoquan He <bhe@redhat.com>
      Cc: Borislav Petkov <bp@suse.de>
      Cc: Dmitry Vyukov <dvyukov@google.com>
      Cc: H.J. Lu <hjl.tools@gmail.com>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Link: http://lkml.kernel.org/r/20160426214606.GA5758@www.outflux.netSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      81b785f3
  7. 22 Apr, 2016 4 commits
    • Kees Cook's avatar
      x86/KASLR: Warn when KASLR is disabled · 0f8ede1b
      Kees Cook authored
      If KASLR is built in but not available at run-time (either due to the
      current conflict with hibernation, command-line request, or e820 parsing
      failures), announce the state explicitly. To support this, a new "warn"
      function is created, based on the existing "error" function.
      Suggested-by: default avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Baoquan He <bhe@redhat.com>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Borislav Petkov <bp@suse.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: Dmitry Vyukov <dvyukov@google.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: H.J. Lu <hjl.tools@gmail.com>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Link: http://lkml.kernel.org/r/1461185746-8017-6-git-send-email-keescook@chromium.orgSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      0f8ede1b
    • Kees Cook's avatar
      x86/boot: Make memcpy() handle overlaps · bf0118db
      Kees Cook authored
      Two uses of memcpy() (screen scrolling and ELF parsing) were handling
      overlapping memory areas. While there were no explicitly noticed bugs
      here (yet), it is best to fix this so that the copying will always be
      safe.
      
      Instead of making a new memmove() function that might collide with other
      memmove() definitions in the decompressors, this just makes the compressed
      boot code's copy of memcpy() overlap-safe.
      Suggested-by: default avatarLasse Collin <lasse.collin@tukaani.org>
      Reported-by: default avatarYinghai Lu <yinghai@kernel.org>
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Baoquan He <bhe@redhat.com>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Borislav Petkov <bp@suse.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: Dmitry Vyukov <dvyukov@google.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: H.J. Lu <hjl.tools@gmail.com>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Link: http://lkml.kernel.org/r/1461185746-8017-5-git-send-email-keescook@chromium.orgSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      bf0118db
    • Kees Cook's avatar
      x86/boot: Clean up things used by decompressors · 1f208de3
      Kees Cook authored
      This rearranges the pieces needed to include the decompressor code
      in misc.c. It wasn't obvious why things were there, so a comment was
      added and definitions consolidated.
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Baoquan He <bhe@redhat.com>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Borislav Petkov <bp@suse.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: Dmitry Vyukov <dvyukov@google.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: H.J. Lu <hjl.tools@gmail.com>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Link: http://lkml.kernel.org/r/1461185746-8017-4-git-send-email-keescook@chromium.orgSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      1f208de3
    • Baoquan He's avatar
      x86/KASLR: Update description for decompressor worst case size · 4252db10
      Baoquan He authored
      The comment that describes the analysis for the size of the decompressor
      code only took gzip into account (there are currently 6 other decompressors
      that could be used). The actual z_extract_offset calculation in code was
      already handling the correct maximum size, but this documentation hadn't
      been updated. This updates the documentation, fixes several typos, moves
      the comment to header.S, updates references, and adds a note at the end
      of the decompressor include list to remind us about updating the comment
      in the future.
      
      (Instead of moving the comment to mkpiggy.c, where the calculation
      is currently happening, it is being moved to header.S because
      the calculations in mkpiggy.c will be removed in favor of header.S
      calculations in a following patch, and it seemed like overkill to move
      the giant comment twice, especially when there's already reference to
      z_extract_offset in header.S.)
      Signed-off-by: default avatarBaoquan He <bhe@redhat.com>
      [ Rewrote changelog, cleaned up comment style, moved comments around. ]
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Borislav Petkov <bp@suse.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: Dmitry Vyukov <dvyukov@google.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: H.J. Lu <hjl.tools@gmail.com>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Link: http://lkml.kernel.org/r/1461185746-8017-2-git-send-email-keescook@chromium.orgSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      4252db10
  8. 19 Apr, 2016 4 commits
    • Kees Cook's avatar
      x86/KASLR: Clarify purpose of kaslr.c · 7de828df
      Kees Cook authored
      The name "choose_kernel_location" isn't specific enough, and doesn't
      describe the primary thing it does: choosing a random location. This
      patch renames it to "choose_random_location", and clarifies the what
      routines are contained in the kaslr.c source file.
      Suggested-by: default avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Baoquan He <bhe@redhat.com>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Borislav Petkov <bp@suse.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: Dmitry Vyukov <dvyukov@google.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: H.J. Lu <hjl.tools@gmail.com>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Link: http://lkml.kernel.org/r/1460997735-24785-6-git-send-email-keescook@chromium.orgSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      7de828df
    • Kees Cook's avatar
      x86/boot: Clarify purpose of functions in misc.c · c0402881
      Kees Cook authored
      The function "decompress_kernel" now performs many more duties, so this
      patch renames it to "extract_kernel" and updates callers and comments.
      Additionally the file header comment for misc.c is improved to actually
      describe what is contained.
      Suggested-by: default avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Baoquan He <bhe@redhat.com>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Borislav Petkov <bp@suse.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: Dmitry Vyukov <dvyukov@google.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: H.J. Lu <hjl.tools@gmail.com>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Link: http://lkml.kernel.org/r/1460997735-24785-5-git-send-email-keescook@chromium.orgSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      c0402881
    • Kees Cook's avatar
      x86/boot: Rename "real_mode" to "boot_params" · 6655e0aa
      Kees Cook authored
      The non-compressed boot code uses the (much more obvious) name
      "boot_params" for the global pointer to the x86 boot parameters. The
      compressed kernel loader code, though, was using the legacy name
      "real_mode". There is no need to have a different name, and changing it
      improves readability.
      Suggested-by: default avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Baoquan He <bhe@redhat.com>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Borislav Petkov <bp@suse.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: Dmitry Vyukov <dvyukov@google.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: H.J. Lu <hjl.tools@gmail.com>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Link: http://lkml.kernel.org/r/1460997735-24785-4-git-send-email-keescook@chromium.orgSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      6655e0aa
    • Yinghai Lu's avatar
      x86/KASLR: Remove unneeded boot_params argument · 206f25a8
      Yinghai Lu authored
      Since the boot_params can be found using the real_mode global variable,
      there is no need to pass around a pointer to it. This slightly simplifies
      the choose_kernel_location function and its callers.
      
      [kees: rewrote changelog, tracked file rename]
      Signed-off-by: default avatarYinghai Lu <yinghai@kernel.org>
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Baoquan He <bhe@redhat.com>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Borislav Petkov <bp@suse.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: Dmitry Vyukov <dvyukov@google.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: H.J. Lu <hjl.tools@gmail.com>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Link: http://lkml.kernel.org/r/1460997735-24785-3-git-send-email-keescook@chromium.orgSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      206f25a8
  9. 10 Sep, 2015 1 commit
    • Yinghai Lu's avatar
      lib/decompressors: use real out buf size for gunzip with kernel · 2d3862d2
      Yinghai Lu authored
      When loading x86 64bit kernel above 4GiB with patched grub2, got kernel
      gunzip error.
      
      | early console in decompress_kernel
      | decompress_kernel:
      |       input: [0x807f2143b4-0x807ff61aee]
      |      output: [0x807cc00000-0x807f3ea29b] 0x027ea29c: output_len
      | boot via startup_64
      | KASLR using RDTSC...
      |  new output: [0x46fe000000-0x470138cfff] 0x0338d000: output_run_size
      |  decompress: [0x46fe000000-0x47007ea29b] <=== [0x807f2143b4-0x807ff61aee]
      |
      | Decompressing Linux... gz...
      |
      | uncompression error
      |
      | -- System halted
      
      the new buffer is at 0x46fe000000ULL, decompressor_gzip is using
      0xffffffb901ffffff as out_len.  gunzip in lib/zlib_inflate/inflate.c cap
      that len to 0x01ffffff and decompress fails later.
      
      We could hit this problem with crashkernel booting that uses kexec loading
      kernel above 4GiB.
      
      We have decompress_* support:
          1. inbuf[]/outbuf[] for kernel preboot.
          2. inbuf[]/flush() for initramfs
          3. fill()/flush() for initrd.
      This bug only affect kernel preboot path that use outbuf[].
      
      Add __decompress and take real out_buf_len for gunzip instead of guessing
      wrong buf size.
      
      Fixes: 1431574a (lib/decompressors: fix "no limit" output buffer length)
      Signed-off-by: default avatarYinghai Lu <yinghai@kernel.org>
      Cc: Alexandre Courbot <acourbot@nvidia.com>
      Cc: Jon Medhurst <tixy@linaro.org>
      Cc: Stephen Warren <swarren@wwwdotorg.org>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      2d3862d2
  10. 07 Jul, 2015 1 commit
    • Kees Cook's avatar
      x86/boot: Add hex output for debugging · 79063a7c
      Kees Cook authored
      This is useful for reporting various addresses or other values
      while debugging early boot, for example, the recent kernel image
      size vs kernel run size. For example, when
      CONFIG_X86_VERBOSE_BOOTUP is set, this is now visible at boot
      time:
      
      	early console in setup code
      	early console in decompress_kernel
      	input_data: 0x0000000001e1526e
      	input_len: 0x0000000000732236
      	output: 0x0000000001000000
      	output_len: 0x0000000001535640
      	run_size: 0x00000000021fb000
      	KASLR using RDTSC...
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      Cc: Andrey Ryabinin <a.ryabinin@samsung.com>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Borislav Petkov <bp@suse.de>
      Cc: Jan Beulich <JBeulich@suse.com>
      Cc: Jiri Kosina <jkosina@suse.cz>
      Cc: Joe Perches <joe@perches.com>
      Cc: Josh Triplett <josh@joshtriplett.org>
      Cc: Junjie Mao <eternal.n08@gmail.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Vivek Goyal <vgoyal@redhat.com>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Link: http://lkml.kernel.org/r/20150706230620.GA17501@www.outflux.netSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      79063a7c
  11. 03 Apr, 2015 1 commit
    • Borislav Petkov's avatar
      x86/mm/KASLR: Propagate KASLR status to kernel proper · 78cac48c
      Borislav Petkov authored
      Commit:
      
        e2b32e67 ("x86, kaslr: randomize module base load address")
      
      made module base address randomization unconditional and didn't regard
      disabled KKASLR due to CONFIG_HIBERNATION and command line option
      "nokaslr". For more info see (now reverted) commit:
      
        f47233c2 ("x86/mm/ASLR: Propagate base load address calculation")
      
      In order to propagate KASLR status to kernel proper, we need a single bit
      in boot_params.hdr.loadflags and we've chosen bit 1 thus leaving the
      top-down allocated bits for bits supposed to be used by the bootloader.
      
      Originally-From: Jiri Kosina <jkosina@suse.cz>
      Suggested-by: default avatarH. Peter Anvin <hpa@zytor.com>
      Signed-off-by: default avatarBorislav Petkov <bp@suse.de>
      Cc: Kees Cook <keescook@chromium.org>
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      78cac48c
  12. 16 Mar, 2015 1 commit
    • Borislav Petkov's avatar
      Revert "x86/mm/ASLR: Propagate base load address calculation" · 69797daf
      Borislav Petkov authored
      This reverts commit:
      
        f47233c2 ("x86/mm/ASLR: Propagate base load address calculation")
      
      The main reason for the revert is that the new boot flag does not work
      at all currently, and in order to make this work, we need non-trivial
      changes to the x86 boot code which we didn't manage to get done in
      time for merging.
      
      And even if we did, they would've been too risky so instead of
      rushing things and break booting 4.1 on boxes left and right, we
      will be very strict and conservative and will take our time with
      this to fix and test it properly.
      Reported-by: default avatarYinghai Lu <yinghai@kernel.org>
      Signed-off-by: default avatarBorislav Petkov <bp@suse.de>
      Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
      Cc: Baoquan He <bhe@redhat.com>
      Cc: H. Peter Anvin <hpa@linux.intel.com
      Cc: Jiri Kosina <jkosina@suse.cz>
      Cc: Josh Triplett <josh@joshtriplett.org>
      Cc: Junjie Mao <eternal.n08@gmail.com>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Matt Fleming <matt.fleming@intel.com>
      Link: http://lkml.kernel.org/r/20150316100628.GD22995@pd.tnicSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      69797daf
  13. 19 Feb, 2015 1 commit
    • Jiri Kosina's avatar
      x86/mm/ASLR: Propagate base load address calculation · f47233c2
      Jiri Kosina authored
      Commit:
      
        e2b32e67 ("x86, kaslr: randomize module base load address")
      
      makes the base address for module to be unconditionally randomized in
      case when CONFIG_RANDOMIZE_BASE is defined and "nokaslr" option isn't
      present on the commandline.
      
      This is not consistent with how choose_kernel_location() decides whether
      it will randomize kernel load base.
      
      Namely, CONFIG_HIBERNATION disables kASLR (unless "kaslr" option is
      explicitly specified on kernel commandline), which makes the state space
      larger than what module loader is looking at. IOW CONFIG_HIBERNATION &&
      CONFIG_RANDOMIZE_BASE is a valid config option, kASLR wouldn't be applied
      by default in that case, but module loader is not aware of that.
      
      Instead of fixing the logic in module.c, this patch takes more generic
      aproach. It introduces a new bootparam setup data_type SETUP_KASLR and
      uses that to pass the information whether kaslr has been applied during
      kernel decompression, and sets a global 'kaslr_enabled' variable
      accordingly, so that any kernel code (module loading, livepatching, ...)
      can make decisions based on its value.
      
      x86 module loader is converted to make use of this flag.
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      Acked-by: default avatarKees Cook <keescook@chromium.org>
      Cc: "H. Peter Anvin" <hpa@linux.intel.com>
      Link: https://lkml.kernel.org/r/alpine.LNX.2.00.1502101411280.10719@pobox.suse.cz
      [ Always dump correct kaslr status when panicking ]
      Signed-off-by: default avatarBorislav Petkov <bp@suse.de>
      f47233c2
  14. 20 Jan, 2015 1 commit
  15. 04 Nov, 2014 1 commit
  16. 01 Nov, 2014 1 commit
    • Junjie Mao's avatar
      x86, kaslr: Prevent .bss from overlaping initrd · e6023367
      Junjie Mao authored
      When choosing a random address, the current implementation does not take into
      account the reversed space for .bss and .brk sections. Thus the relocated kernel
      may overlap other components in memory. Here is an example of the overlap from a
      x86_64 kernel in qemu (the ranges of physical addresses are presented):
      
       Physical Address
      
          0x0fe00000                  --+--------------------+  <-- randomized base
                                     /  |  relocated kernel  |
                         vmlinux.bin    | (from vmlinux.bin) |
          0x1336d000    (an ELF file)   +--------------------+--
                                     \  |                    |  \
          0x1376d870                  --+--------------------+   |
                                        |    relocs table    |   |
          0x13c1c2a8                    +--------------------+   .bss and .brk
                                        |                    |   |
          0x13ce6000                    +--------------------+   |
                                        |                    |  /
          0x13f77000                    |       initrd       |--
                                        |                    |
          0x13fef374                    +--------------------+
      
      The initrd image will then be overwritten by the memset during early
      initialization:
      
      [    1.655204] Unpacking initramfs...
      [    1.662831] Initramfs unpacking failed: junk in compressed archive
      
      This patch prevents the above situation by requiring a larger space when looking
      for a random kernel base, so that existing logic can effectively avoids the
      overlap.
      
      [kees: switched to perl to avoid hex translation pain in mawk vs gawk]
      [kees: calculated overlap without relocs table]
      
      Fixes: 82fa9637 ("x86, kaslr: Select random position from e820 maps")
      Reported-by: default avatarFengguang Wu <fengguang.wu@intel.com>
      Signed-off-by: default avatarJunjie Mao <eternal.n08@gmail.com>
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      Cc: Josh Triplett <josh@joshtriplett.org>
      Cc: Matt Fleming <matt.fleming@intel.com>
      Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
      Cc: Vivek Goyal <vgoyal@redhat.com>
      Cc: Andi Kleen <ak@linux.intel.com>
      Cc: stable@vger.kernel.org
      Link: http://lkml.kernel.org/r/1414762838-13067-1-git-send-email-eternal.n08@gmail.comSigned-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      e6023367
  17. 05 May, 2014 1 commit
  18. 19 Mar, 2014 2 commits
  19. 13 Oct, 2013 2 commits
  20. 08 Aug, 2013 1 commit
  21. 09 Jul, 2013 1 commit
  22. 29 Jan, 2013 1 commit
  23. 21 Jul, 2012 5 commits
  24. 26 Jan, 2012 1 commit