1. 06 Jan, 2019 1 commit
  2. 14 Oct, 2018 1 commit
    • Nathan Chancellor's avatar
      x86/boot: Add -Wno-pointer-sign to KBUILD_CFLAGS · dca5203e
      Nathan Chancellor authored
      When compiling the kernel with Clang, this warning appears even though
      it is disabled for the whole kernel because this folder has its own set
      of KBUILD_CFLAGS. It was disabled before the beginning of git history.
      In file included from arch/x86/boot/compressed/kaslr.c:29:
      In file included from arch/x86/boot/compressed/misc.h:21:
      In file included from ./include/linux/elf.h:5:
      In file included from ./arch/x86/include/asm/elf.h:77:
      In file included from ./arch/x86/include/asm/vdso.h:11:
      In file included from ./include/linux/mm_types.h:9:
      In file included from ./include/linux/spinlock.h:88:
      In file included from ./arch/x86/include/asm/spinlock.h:43:
      In file included from ./arch/x86/include/asm/qrwlock.h:6:
      ./include/asm-generic/qrwlock.h:101:53: warning: passing 'u32 *' (aka
      'unsigned int *') to parameter of type 'int *' converts between pointers
      to integer types with different sign [-Wpointer-sign]
              if (likely(atomic_try_cmpxchg_acquire(&lock->cnts, &cnts, _QW_LOCKED)))
      ./include/linux/compiler.h:76:40: note: expanded from macro 'likely'
      # define likely(x)      __builtin_expect(!!(x), 1)
      ./include/asm-generic/atomic-instrumented.h:69:66: note: passing
      argument to parameter 'old' here
      static __always_inline bool atomic_try_cmpxchg(atomic_t *v, int *old, int new)
      Signed-off-by: default avatarNathan Chancellor <natechancellor@gmail.com>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Nick Desaulniers <ndesaulniers@google.com>
      Link: https://lkml.kernel.org/r/20181013010713.6999-1-natechancellor@gmail.com
  3. 23 Aug, 2018 1 commit
  4. 25 Jul, 2018 1 commit
    • Kees Cook's avatar
      x86/boot: Fix if_changed build flip/flop bug · 92a47286
      Kees Cook authored
      Dirk Gouders reported that two consecutive "make" invocations on an
      already compiled tree will show alternating behaviors:
      $ make
        CALL    scripts/checksyscalls.sh
        DESCEND  objtool
        CHK     include/generated/compile.h
        DATAREL arch/x86/boot/compressed/vmlinux
      Kernel: arch/x86/boot/bzImage is ready  (#48)
        Building modules, stage 2.
        MODPOST 165 modules
      $ make
        CALL    scripts/checksyscalls.sh
        DESCEND  objtool
        CHK     include/generated/compile.h
        LD      arch/x86/boot/compressed/vmlinux
        ZOFFSET arch/x86/boot/zoffset.h
        AS      arch/x86/boot/header.o
        LD      arch/x86/boot/setup.elf
        OBJCOPY arch/x86/boot/setup.bin
        OBJCOPY arch/x86/boot/vmlinux.bin
        BUILD   arch/x86/boot/bzImage
      Setup is 15644 bytes (padded to 15872 bytes).
      System is 6663 kB
      CRC 3eb90f40
      Kernel: arch/x86/boot/bzImage is ready  (#48)
        Building modules, stage 2.
        MODPOST 165 modules
      He bisected it back to:
          commit 98f78525 ("x86/boot: Refuse to build with data relocations")
      The root cause was the use of the "if_changed" kbuild function multiple
      times for the same target. It was designed to only be used once per
      target, otherwise it will effectively always trigger, flipping back and
      forth between the two commands getting recorded by "if_changed". Instead,
      this patch merges the two commands into a single function to get stable
      build artifacts (i.e. .vmlinux.cmd), and a single build behavior.
      Bisected-and-Reported-by: default avatarDirk Gouders <dirk@gouders.net>
      Fix-Suggested-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      Reviewed-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.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/20180724230827.GA37823@beastSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
  5. 31 Mar, 2018 1 commit
  6. 11 Feb, 2018 1 commit
  7. 07 Dec, 2017 1 commit
  8. 07 Nov, 2017 1 commit
    • Tom Lendacky's avatar
      x86/boot: Add early boot support when running with SEV active · 1958b5fc
      Tom Lendacky authored
      Early in the boot process, add checks to determine if the kernel is
      running with Secure Encrypted Virtualization (SEV) active.
      Checking for SEV requires checking that the kernel is running under a
      hypervisor (CPUID 0x00000001, bit 31), that the SEV feature is available
      (CPUID 0x8000001f, bit 1) and then checking a non-interceptable SEV MSR
      (0xc0010131, bit 0).
      This check is required so that during early compressed kernel booting the
      pagetables (both the boot pagetables and KASLR pagetables (if enabled) are
      updated to include the encryption mask so that when the kernel is
      decompressed into encrypted memory, it can boot properly.
      After the kernel is decompressed and continues booting the same logic is
      used to check if SEV is active and set a flag indicating so.  This allows
      to distinguish between SME and SEV, each of which have unique differences
      in how certain things are handled: e.g. DMA (always bounce buffered with
      SEV) or EFI tables (always access decrypted with SME).
      Signed-off-by: default avatarTom Lendacky <thomas.lendacky@amd.com>
      Signed-off-by: default avatarBrijesh Singh <brijesh.singh@amd.com>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Reviewed-by: default avatarBorislav Petkov <bp@suse.de>
      Tested-by: default avatarBorislav Petkov <bp@suse.de>
      Cc: Laura Abbott <labbott@redhat.com>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: kvm@vger.kernel.org
      Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      Cc: Radim Krčmář <rkrcmar@redhat.com>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Paolo Bonzini <pbonzini@redhat.com>
      Cc: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
      Link: https://lkml.kernel.org/r/20171020143059.3291-13-brijesh.singh@amd.com
  9. 02 Nov, 2017 1 commit
    • Greg Kroah-Hartman's avatar
      License cleanup: add SPDX GPL-2.0 license identifier to files with no license · b2441318
      Greg Kroah-Hartman authored
      Many source files in the tree are missing licensing information, which
      makes it harder for compliance tools to determine the correct license.
      By default all files without license information are under the default
      license of the kernel, which is GPL version 2.
      Update the files which contain no license information with the 'GPL-2.0'
      SPDX license identifier.  The SPDX identifier is a legally binding
      shorthand, which can be used instead of the full boiler plate text.
      This patch is based on work done by Thomas Gleixner and Kate Stewart and
      Philippe Ombredanne.
      How this work was done:
      Patches were generated and checked against linux-4.14-rc6 for a subset of
      the use cases:
       - file had no licensing information it it.
       - file was a */uapi/* one with no licensing information in it,
       - file was a */uapi/* one with existing licensing information,
      Further patches will be generated in subsequent months to fix up cases
      where non-standard license headers were used, and references to license
      had to be inferred by heuristics based on keywords.
      The analysis to determine which SPDX License Identifier to be applied to
      a file was done in a spreadsheet of side by side results from of the
      output of two independent scanners (ScanCode & Windriver) producing SPDX
      tag:value files created by Philippe Ombredanne.  Philippe prepared the
      base worksheet, and did an initial spot review of a few 1000 files.
      The 4.13 kernel was the starting point of the analysis with 60,537 files
      assessed.  Kate Stewart did a file by file comparison of the scanner
      results in the spreadsheet to determine which SPDX license identifier(s)
      to be applied to the file. She confirmed any determination that was not
      immediately clear with lawyers working with the Linux Foundation.
      Criteria used to select files for SPDX license identifier tagging was:
       - Files considered eligible had to be source code files.
       - Make and config files were included as candidates if they contained >5
         lines of source
       - File already had some variant of a license header in it (even if <5
      All documentation files were explicitly excluded.
      The following heuristics were used to determine which SPDX license
      identifiers to apply.
       - when both scanners couldn't find any license traces, file was
         considered to have no license information in it, and the top level
         COPYING file license applied.
         For non */uapi/* files that summary was:
         SPDX license identifier                            # files
         GPL-2.0                                              11139
         and resulted in the first patch in this series.
         If that file was a */uapi/* path one, it was "GPL-2.0 WITH
         Linux-syscall-note" otherwise it was "GPL-2.0".  Results of that was:
         SPDX license identifier                            # files
         GPL-2.0 WITH Linux-syscall-note                        930
         and resulted in the second patch in this series.
       - if a file had some form of licensing information in it, and was one
         of the */uapi/* ones, it was denoted with the Linux-syscall-note if
         any GPL family license was found in the file or had no licensing in
         it (per prior point).  Results summary:
         SPDX license identifier                            # files
         GPL-2.0 WITH Linux-syscall-note                       270
         GPL-2.0+ WITH Linux-syscall-note                      169
         ((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause)    21
         ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause)    17
         LGPL-2.1+ WITH Linux-syscall-note                      15
         GPL-1.0+ WITH Linux-syscall-note                       14
         ((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause)    5
         LGPL-2.0+ WITH Linux-syscall-note                       4
         LGPL-2.1 WITH Linux-syscall-note                        3
         ((GPL-2.0 WITH Linux-syscall-note) OR MIT)              3
         ((GPL-2.0 WITH Linux-syscall-note) AND MIT)             1
         and that resulted in the third patch in this series.
       - when the two scanners agreed on the detected license(s), that became
         the concluded license(s).
       - when there was disagreement between the two scanners (one detected a
         license but the other didn't, or they both detected different
         licenses) a manual inspection of the file occurred.
       - In most cases a manual inspection of the information in the file
         resulted in a clear resolution of the license that should apply (and
         which scanner probably needed to revisit its heuristics).
       - When it was not immediately clear, the license identifier was
         confirmed with lawyers working with the Linux Foundation.
       - If there was any question as to the appropriate license identifier,
         the file was flagged for further research and to be revisited later
         in time.
      In total, over 70 hours of logged manual review was done on the
      spreadsheet to determine the SPDX license identifiers to apply to the
      source files by Kate, Philippe, Thomas and, in some cases, confirmation
      by lawyers working with the Linux Foundation.
      Kate also obtained a third independent scan of the 4.13 code base from
      FOSSology, and compared selected files where the other two scanners
      disagreed against that SPDX file, to see if there was new insights.  The
      Windriver scanner is based on an older version of FOSSology in part, so
      they are related.
      Thomas did random spot checks in about 500 files from the spreadsheets
      for the uapi headers and agreed with SPDX license identifier in the
      files he inspected. For the non-uapi files Thomas did random spot checks
      in about 15000 files.
      In initial set of patches against 4.14-rc6, 3 files were found to have
      copy/paste license identifier errors, and have been fixed to reflect the
      correct identifier.
      Additionally Philippe spent 10 hours this week doing a detailed manual
      inspection and review of the 12,461 patched files from the initial patch
      version early this week with:
       - a full scancode scan run, collecting the matched texts, detected
         license ids and scores
       - reviewing anything where there was a license detected (about 500+
         files) to ensure that the applied SPDX license was correct
       - reviewing anything where there was no detection but the patch license
         was not GPL-2.0 WITH Linux-syscall-note to ensure that the applied
         SPDX license was correct
      This produced a worksheet with 20 files needing minor correction.  This
      worksheet was then exported into 3 different .csv files for the
      different types of files to be modified.
      These .csv files were then reviewed by Greg.  Thomas wrote a script to
      parse the csv files and add the proper SPDX tag to the file, in the
      format that the file expected.  This script was further refined by Greg
      based on the output to detect more types of files automatically and to
      distinguish between header and source .c files (which need different
      comment types.)  Finally Greg ran the script using the .csv files to
      generate the patches.
      Reviewed-by: default avatarKate Stewart <kstewart@linuxfoundation.org>
      Reviewed-by: default avatarPhilippe Ombredanne <pombredanne@nexb.com>
      Reviewed-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
  10. 31 Oct, 2017 1 commit
  11. 28 Jul, 2017 1 commit
    • Matthias Kaehlcke's avatar
      x86/boot: Disable the address-of-packed-member compiler warning · 20c6c189
      Matthias Kaehlcke authored
      The clang warning 'address-of-packed-member' is disabled for the general
      kernel code, also disable it for the x86 boot code.
      This suppresses a bunch of warnings like this when building with clang:
      ./arch/x86/include/asm/processor.h:535:30: warning: taking address of
        packed member 'sp0' of class or structure 'x86_hw_tss' may result in an
        unaligned pointer value [-Waddress-of-packed-member]
          return this_cpu_read_stable(cpu_tss.x86_tss.sp0);
      ./arch/x86/include/asm/percpu.h:391:59: note: expanded from macro
          #define this_cpu_read_stable(var)       percpu_stable_op("mov", var)
      ./arch/x86/include/asm/percpu.h:228:16: note: expanded from macro
          : "p" (&(var)));
      Signed-off-by: default avatarMatthias Kaehlcke <mka@chromium.org>
      Cc: Doug Anderson <dianders@chromium.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Link: http://lkml.kernel.org/r/20170725215053.135586-1-mka@chromium.orgSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
  12. 21 May, 2017 1 commit
  13. 14 Dec, 2016 1 commit
    • Paul Bolle's avatar
      Remove references to dead make variable LINUX_INCLUDE · 846221cf
      Paul Bolle authored
      Commit 4fd06960 ("Use the new x86 setup code for i386") introduced a
      reference to the make variable LINUX_INCLUDE. That reference got moved
      around a bit and copied twice and now there are three references to it.
      There has never been a definition of that variable. (Presumably that is
      because it started out as a mistyped reference to LINUXINCLUDE.) So this
      reference has always been an empty string. Let's remove it before it
      spreads any further.
      Signed-off-by: default avatarPaul Bolle <pebolle@tiscali.nl>
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
  14. 21 Nov, 2016 1 commit
    • H.J. Lu's avatar
      x86/build: Build compressed x86 kernels as PIE when !CONFIG_RELOCATABLE as well · a980ce35
      H.J. Lu authored
      Since the bootloader may load the compressed x86 kernel at any address,
      it should always be built as PIE, not just when CONFIG_RELOCATABLE=y.
      Otherwise, linker in binutils 2.27 will optimize GOT load into the
      absolute address when building the compressed x86 kernel as a non-PIE
      Signed-off-by: default avatarH.J. Lu <hjl.tools@gmail.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: H. Peter Anvin <hpa@zytor.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: linux-kernel@vger.kernel.org
      [ Small wording changes. ]
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
  15. 26 Jun, 2016 1 commit
    • Kees Cook's avatar
      x86/boot: Refuse to build with data relocations · 98f78525
      Kees Cook authored
      The compressed kernel is built with -fPIC/-fPIE so that it can run in any
      location a bootloader happens to put it. However, since ELF relocation
      processing is not happening (and all the relocation information has
      already been stripped at link time), none of the code can use data
      relocations (e.g. static assignments of pointers). This is already noted
      in a warning comment at the top of misc.c, but this adds an explicit
      check for the condition during the linking stage to block any such bugs
      from appearing.
      If this was in place with the earlier bug in pagetable.c, the build
      would fail like this:
          CC      arch/x86/boot/compressed/pagetable.o
          DATAREL arch/x86/boot/compressed/vmlinux
        error: arch/x86/boot/compressed/pagetable.o has data relocations!
        make[2]: *** [arch/x86/boot/compressed/vmlinux] Error 1
      A clean build shows:
          CC      arch/x86/boot/compressed/pagetable.o
          DATAREL arch/x86/boot/compressed/vmlinux
          LD      arch/x86/boot/compressed/vmlinux
      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@kernel.org>
      Cc: Baoquan He <bhe@redhat.com>
      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-2-git-send-email-keescook@chromium.orgSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
  16. 07 May, 2016 1 commit
    • Kees Cook's avatar
      x86/KASLR: Build identity mappings on demand · 3a94707d
      Kees Cook authored
      Currently KASLR only supports relocation in a small physical range (from
      16M to 1G), due to using the initial kernel page table identity mapping.
      To support ranges above this, we need to have an identity mapping for the
      desired memory range before we can decompress (and later run) the kernel.
      32-bit kernels already have the needed identity mapping. This patch adds
      identity mappings for the needed memory ranges on 64-bit kernels. This
      happens in two possible boot paths:
      If loaded via startup_32(), we need to set up the needed identity map.
      If loaded from a 64-bit bootloader, the bootloader will have already
      set up an identity mapping, and we'll start via the compressed kernel's
      startup_64(). In this case, the bootloader's page tables need to be
      avoided while selecting the new uncompressed kernel location. If not,
      the decompressor could overwrite them during decompression.
      To accomplish this, we could walk the pagetable and find every page
      that is used, and add them to mem_avoid, but this needs extra code and
      will require increasing the size of the mem_avoid array.
      Instead, we can create a new set of page tables for our own identity
      mapping instead. The pages for the new page table will come from the
      _pagetable section of the compressed kernel, which means they are
      already contained by in mem_avoid array. To do this, we reuse the code
      from the uncompressed kernel's identity mapping routines.
      The _pgtable will be shared by both the 32-bit and 64-bit paths to reduce
      init_size, as now the compressed kernel's _rodata to _end will contribute
      to init_size.
      To handle the possible mappings, we need to increase the existing page
      table buffer size:
      When booting via startup_64(), we need to cover the old VO, params,
      cmdline and uncompressed kernel. In an extreme case we could have them
      all beyond the 512G boundary, which needs (2+2)*4 pages with 2M mappings.
      And we'll need 2 for first 2M for VGA RAM. One more is needed for level4.
      This gets us to 19 pages total.
      When booting via startup_32(), KASLR could move the uncompressed kernel
      above 4G, so we need to create extra identity mappings, which should only
      need (2+2) pages at most when it is beyond the 512G boundary. So 19
      pages is sufficient for this case as well.
      The resulting BOOT_*PGT_SIZE defines use the "_SIZE" suffix on their
      names to maintain logical consistency with the existing BOOT_HEAP_SIZE
      and BOOT_STACK_SIZE defines.
      This patch is based on earlier patches from Yinghai Lu and Baoquan He.
      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: Borislav Petkov <bp@suse.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: Jiri Kosina <jkosina@suse.cz>
      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: kernel-hardening@lists.openwall.com
      Cc: lasse.collin@tukaani.org
      Link: http://lkml.kernel.org/r/1462572095-11754-4-git-send-email-keescook@chromium.orgSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
  17. 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
      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>
  18. 29 Apr, 2016 3 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>
    • 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>
    • 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
       Idx Name    Size      VMA               LMA               File off  Algn
        27 .bss    00170000  ffffffff81ec8000  0000000001ec8000  012c8000  2**12
        28 .brk    00027000  ffffffff82038000  0000000002038000  012c8000  2**0
      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
         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
       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>
  19. 20 Apr, 2016 1 commit
  20. 19 Apr, 2016 1 commit
    • Kees Cook's avatar
      x86/KASLR: Rename aslr.c to kaslr.c · 9b238748
      Kees Cook authored
      In order to avoid confusion over what this file provides, rename it to
      kaslr.c since it is used exclusively for the kernel ASLR, not userspace
      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-2-git-send-email-keescook@chromium.orgSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
  21. 29 Mar, 2016 1 commit
    • H.J. Lu's avatar
      x86/build: Build compressed x86 kernels as PIE · 6d92bc9d
      H.J. Lu authored
      The 32-bit x86 assembler in binutils 2.26 will generate R_386_GOT32X
      relocation to get the symbol address in PIC.  When the compressed x86
      kernel isn't built as PIC, the linker optimizes R_386_GOT32X relocations
      to their fixed symbol addresses.  However, when the compressed x86
      kernel is loaded at a different address, it leads to the following
      load failure:
        Failed to allocate space for phdrs
      during the decompression stage.
      If the compressed x86 kernel is relocatable at run-time, it should be
      compiled with -fPIE, instead of -fPIC, if possible and should be built as
      Position Independent Executable (PIE) so that linker won't optimize
      R_386_GOT32X relocation to its fixed symbol address.
      Older linkers generate R_386_32 relocations against locally defined
      symbols, _bss, _ebss, _got and _egot, in PIE.  It isn't wrong, just less
      optimal than R_386_RELATIVE.  But the x86 kernel fails to properly handle
      R_386_32 relocations when relocating the kernel.  To generate
      R_386_RELATIVE relocations, we mark _bss, _ebss, _got and _egot as
      hidden in both 32-bit and 64-bit x86 kernels.
      To build a 64-bit compressed x86 kernel as PIE, we need to disable the
      relocation overflow check to avoid relocation overflow errors. We do
      this with a new linker command-line option, -z noreloc-overflow, which
      got added recently:
       commit 4c10bbaa0912742322f10d9d5bb630ba4e15dfa7
       Author: H.J. Lu <hjl.tools@gmail.com>
       Date:   Tue Mar 15 11:07:06 2016 -0700
          Add -z noreloc-overflow option to x86-64 ld
          Add -z noreloc-overflow command-line option to the x86-64 ELF linker to
          disable relocation overflow check.  This can be used to avoid relocation
          overflow check if there will be no dynamic relocation overflow at
      The 64-bit compressed x86 kernel is built as PIE only if the linker supports
      -z noreloc-overflow.  So far 64-bit relocatable compressed x86 kernel
      boots fine even when it is built as a normal executable.
      Signed-off-by: default avatarH.J. Lu <hjl.tools@gmail.com>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.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: linux-kernel@vger.kernel.org
      [ Edited the changelog and comments. ]
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
  22. 22 Mar, 2016 1 commit
    • Dmitry Vyukov's avatar
      kernel: add kcov code coverage · 5c9a8750
      Dmitry Vyukov authored
      kcov provides code coverage collection for coverage-guided fuzzing
      (randomized testing).  Coverage-guided fuzzing is a testing technique
      that uses coverage feedback to determine new interesting inputs to a
      system.  A notable user-space example is AFL
      (http://lcamtuf.coredump.cx/afl/).  However, this technique is not
      widely used for kernel testing due to missing compiler and kernel
      kcov does not aim to collect as much coverage as possible.  It aims to
      collect more or less stable coverage that is function of syscall inputs.
      To achieve this goal it does not collect coverage in soft/hard
      interrupts and instrumentation of some inherently non-deterministic or
      non-interesting parts of kernel is disbled (e.g.  scheduler, locking).
      Currently there is a single coverage collection mode (tracing), but the
      API anticipates additional collection modes.  Initially I also
      implemented a second mode which exposes coverage in a fixed-size hash
      table of counters (what Quentin used in his original patch).  I've
      dropped the second mode for simplicity.
      This patch adds the necessary support on kernel side.  The complimentary
      compiler support was added in gcc revision 231296.
      We've used this support to build syzkaller system call fuzzer, which has
      found 90 kernel bugs in just 2 months:
      We've also found 30+ bugs in our internal systems with syzkaller.
      Another (yet unexplored) direction where kcov coverage would greatly
      help is more traditional "blob mutation".  For example, mounting a
      random blob as a filesystem, or receiving a random blob over wire.
      Why not gcov.  Typical fuzzing loop looks as follows: (1) reset
      coverage, (2) execute a bit of code, (3) collect coverage, repeat.  A
      typical coverage can be just a dozen of basic blocks (e.g.  an invalid
      input).  In such context gcov becomes prohibitively expensive as
      reset/collect coverage steps depend on total number of basic
      blocks/edges in program (in case of kernel it is about 2M).  Cost of
      kcov depends only on number of executed basic blocks/edges.  On top of
      that, kernel requires per-thread coverage because there are always
      background threads and unrelated processes that also produce coverage.
      With inlined gcov instrumentation per-thread coverage is not possible.
      kcov exposes kernel PCs and control flow to user-space which is
      insecure.  But debugfs should not be mapped as user accessible.
      Based on a patch by Quentin Casasnovas.
      [akpm@linux-foundation.org: make task_struct.kcov_mode have type `enum kcov_mode']
      [akpm@linux-foundation.org: unbreak allmodconfig]
      [akpm@linux-foundation.org: follow x86 Makefile layout standards]
      Signed-off-by: default avatarDmitry Vyukov <dvyukov@google.com>
      Reviewed-by: default avatarKees Cook <keescook@chromium.org>
      Cc: syzkaller <syzkaller@googlegroups.com>
      Cc: Vegard Nossum <vegard.nossum@oracle.com>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Tavis Ormandy <taviso@google.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: Quentin Casasnovas <quentin.casasnovas@oracle.com>
      Cc: Kostya Serebryany <kcc@google.com>
      Cc: Eric Dumazet <edumazet@google.com>
      Cc: Alexander Potapenko <glider@google.com>
      Cc: Kees Cook <keescook@google.com>
      Cc: Bjorn Helgaas <bhelgaas@google.com>
      Cc: Sasha Levin <sasha.levin@oracle.com>
      Cc: David Drysdale <drysdale@google.com>
      Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
      Cc: Andrey Ryabinin <ryabinin.a.a@gmail.com>
      Cc: Kirill A. Shutemov <kirill@shutemov.name>
      Cc: Jiri Slaby <jslaby@suse.cz>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
  23. 29 Feb, 2016 1 commit
    • Josh Poimboeuf's avatar
      objtool: Mark non-standard object files and directories · c0dd6716
      Josh Poimboeuf authored
      Code which runs outside the kernel's normal mode of operation often does
      unusual things which can cause a static analysis tool like objtool to
      emit false positive warnings:
       - boot image
       - vdso image
       - relocation
       - realmode
       - efi
       - head
       - purgatory
       - modpost
      Set OBJECT_FILES_NON_STANDARD for their related files and directories,
      which will tell objtool to skip checking them.  It's ok to skip them
      because they don't affect runtime stack traces.
      Also skip the following code which does the right thing with respect to
      frame pointers, but is too "special" to be validated by a tool:
       - entry
       - mcount
      Also skip the test_nx module because it modifies its exception handling
      table at runtime, which objtool can't understand.  Fortunately it's
      just a test module so it doesn't matter much.
      Currently objtool is the only user of OBJECT_FILES_NON_STANDARD, but it
      might eventually be useful for other tools.
      Signed-off-by: default avatarJosh Poimboeuf <jpoimboe@redhat.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
      Cc: Bernd Petrovitsch <bernd@petrovitsch.priv.at>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Chris J Arges <chris.j.arges@canonical.com>
      Cc: Jiri Slaby <jslaby@suse.cz>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Michal Marek <mmarek@suse.cz>
      Cc: Namhyung Kim <namhyung@gmail.com>
      Cc: Pedro Alves <palves@redhat.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: live-patching@vger.kernel.org
      Link: http://lkml.kernel.org/r/366c080e3844e8a5b6a0327dc7e8c2b90ca3baeb.1456719558.git.jpoimboe@redhat.comSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
  24. 21 Jan, 2016 1 commit
  25. 14 Feb, 2015 1 commit
    • Andrey Ryabinin's avatar
      x86_64: add KASan support · ef7f0d6a
      Andrey Ryabinin authored
      This patch adds arch specific code for kernel address sanitizer.
      16TB of virtual addressed used for shadow memory.  It's located in range
      [ffffec0000000000 - fffffc0000000000] between vmemmap and %esp fixup
      At early stage we map whole shadow region with zero page.  Latter, after
      pages mapped to direct mapping address range we unmap zero pages from
      corresponding shadow (see kasan_map_shadow()) and allocate and map a real
      shadow memory reusing vmemmap_populate() function.
      Also replace __pa with __pa_nodebug before shadow initialized.  __pa with
      CONFIG_DEBUG_VIRTUAL=y make external function call (__phys_addr)
      __phys_addr is instrumented, so __asan_load could be called before shadow
      area initialized.
      Signed-off-by: default avatarAndrey Ryabinin <a.ryabinin@samsung.com>
      Cc: Dmitry Vyukov <dvyukov@google.com>
      Cc: Konstantin Serebryany <kcc@google.com>
      Cc: Dmitry Chernenkov <dmitryc@google.com>
      Signed-off-by: default avatarAndrey Konovalov <adech.fo@gmail.com>
      Cc: Yuri Gribov <tetra2005@gmail.com>
      Cc: Konstantin Khlebnikov <koct9i@gmail.com>
      Cc: Sasha Levin <sasha.levin@oracle.com>
      Cc: Christoph Lameter <cl@linux.com>
      Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
      Cc: Dave Hansen <dave.hansen@intel.com>
      Cc: Andi Kleen <andi@firstfloor.org>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Christoph Lameter <cl@linux.com>
      Cc: Pekka Enberg <penberg@kernel.org>
      Cc: David Rientjes <rientjes@google.com>
      Cc: Jim Davis <jim.epost@gmail.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
  26. 13 Feb, 2015 1 commit
    • Matt Fleming's avatar
      x86/efi: Avoid triple faults during EFI mixed mode calls · 96738c69
      Matt Fleming authored
      Andy pointed out that if an NMI or MCE is received while we're in the
      middle of an EFI mixed mode call a triple fault will occur. This can
      happen, for example, when issuing an EFI mixed mode call while running
      The reason for the triple fault is that we execute the mixed mode call
      in 32-bit mode with paging disabled but with 64-bit kernel IDT handlers
      installed throughout the call.
      At Andy's suggestion, stop playing the games we currently do at runtime,
      such as disabling paging and installing a 32-bit GDT for __KERNEL_CS. We
      can simply switch to the __KERNEL32_CS descriptor before invoking
      firmware services, and run in compatibility mode. This way, if an
      NMI/MCE does occur the kernel IDT handler will execute correctly, since
      it'll jump to __KERNEL_CS automatically.
      However, this change is only possible post-ExitBootServices(). Before
      then the firmware "owns" the machine and expects for its 32-bit IDT
      handlers to be left intact to service interrupts, etc.
      So, we now need to distinguish between early boot and runtime
      invocations of EFI services. During early boot, we need to restore the
      GDT that the firmware expects to be present. We can only jump to the
      __KERNEL32_CS code segment for mixed mode calls after ExitBootServices()
      has been invoked.
      A liberal sprinkling of comments in the thunking code should make the
      differences in early and late environments more apparent.
      Reported-by: default avatarAndy Lutomirski <luto@amacapital.net>
      Tested-by: default avatarBorislav Petkov <bp@suse.de>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarMatt Fleming <matt.fleming@intel.com>
  27. 26 Jan, 2015 1 commit
  28. 23 Nov, 2014 1 commit
  29. 11 Nov, 2014 1 commit
    • Ard Biesheuvel's avatar
      efi/x86: Move x86 back to libstub · 243b6754
      Ard Biesheuvel authored
      This reverts commit 84be8805, which itself reverted my original
      attempt to move x86 from #include'ing .c files from across the tree
      to using the EFI stub built as a static library.
      The issue that affected the original approach was that splitting
      the implementation into several .o files resulted in the variable
      'efi_early' becoming a global with external linkage, which under
      -fPIC implies that references to it must go through the GOT. However,
      dealing with this additional GOT entry turned out to be troublesome
      on some EFI implementations. (GCC's visibility=hidden attribute is
      supposed to lift this requirement, but it turned out not to work on
      the 32-bit build.)
      Instead, use a pure getter function to get a reference to efi_early.
      This approach results in no additional GOT entries being generated,
      so there is no need for any changes in the early GOT handling.
      Tested-by: default avatarMaarten Lankhorst <maarten.lankhorst@canonical.com>
      Signed-off-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: default avatarMatt Fleming <matt.fleming@intel.com>
  30. 01 Nov, 2014 2 commits
    • Kees Cook's avatar
      x86, boot: Document intermediates more clearly · fb7183ef
      Kees Cook authored
      This adds a comment detailing the various intermediate files used to build
      the bootable decompression image for the x86 kernel.
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      Reviewed-by: default avatarJosh Triplett <josh@joshtriplett.org>
      Cc: Matt Fleming <matt.fleming@intel.com>
      Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
      Cc: Junjie Mao <eternal.n08@gmail.com>
      Link: http://lkml.kernel.org/r/20141031162204.GA26268@www.outflux.netSigned-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
    • 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
      [    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
      [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>
  31. 23 Sep, 2014 1 commit
    • Matt Fleming's avatar
      Revert "efi/x86: efistub: Move shared dependencies to <asm/efi.h>" · 84be8805
      Matt Fleming authored
      This reverts commit f23cf8bd ("efi/x86: efistub: Move shared
      dependencies to <asm/efi.h>") as well as the x86 parts of commit
      f4f75ad5 ("efi: efistub: Convert into static library").
      The road leading to these two reverts is long and winding.
      The above two commits were merged during the v3.17 merge window and
      turned the common EFI boot stub code into a static library. This
      necessitated making some symbols global in the x86 boot stub which
      introduced new entries into the early boot GOT.
      The problem was that we weren't fixing up the newly created GOT entries
      before invoking the EFI boot stub, which sometimes resulted in hangs or
      resets. This failure was reported by Maarten on his Macbook pro.
      The proposed fix was commit 9cb0e394 ("x86/efi: Fixup GOT in all
      boot code paths"). However, that caused issues for Linus when booting
      his Sony Vaio Pro 11. It was subsequently reverted in commit
      So that leaves us back with Maarten's Macbook pro not booting.
      At this stage in the release cycle the least risky option is to revert
      the x86 EFI boot stub to the pre-merge window code structure where we
      explicitly #include efi-stub-helper.c instead of linking with the static
      library. The arm64 code remains unaffected.
      We can take another swing at the x86 parts for v3.18.
      Tested-by: default avatarJosh Boyer <jwboyer@fedoraproject.org>
      Tested-by: default avatarMaarten Lankhorst <maarten.lankhorst@canonical.com>
      Tested-by: Leif Lindholm <leif.lindholm@linaro.org> [arm64]
      Tested-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>,
      Cc: Ingo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarMatt Fleming <matt.fleming@intel.com>
  32. 17 Aug, 2014 3 commits
  33. 18 Jul, 2014 1 commit
    • Ard Biesheuvel's avatar
      efi: efistub: Convert into static library · f4f75ad5
      Ard Biesheuvel authored
      This patch changes both x86 and arm64 efistub implementations
      from #including shared .c files under drivers/firmware/efi to
      building shared code as a static library.
      The x86 code uses a stub built into the boot executable which
      uncompresses the kernel at boot time. In this case, the library is
      linked into the decompressor.
      In the arm64 case, the stub is part of the kernel proper so the library
      is linked into the kernel proper as well.
      Signed-off-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: default avatarMatt Fleming <matt.fleming@intel.com>
  34. 09 Dec, 2013 1 commit
    • H. Peter Anvin's avatar
      x86, build: Pass in additional -mno-mmx, -mno-sse options · 8b3b005d
      H. Peter Anvin authored
      In checkin
          5551a34e x86-64, build: Always pass in -mno-sse
      we unconditionally added -mno-sse to the main build, to keep newer
      compilers from generating SSE instructions from autovectorization.
      However, this did not extend to the special environments
      (arch/x86/boot, arch/x86/boot/compressed, and arch/x86/realmode/rm).
      Add -mno-sse to the compiler command line for these environments, and
      add -mno-mmx to all the environments as well, as we don't want a
      compiler to generate MMX code either.
      This patch also removes a $(cc-option) call for -m32, since we have
      long since stopped supporting compilers too old for the -m32 option,
      and in fact hardcode it in other places in the Makefiles.
      Reported-by: default avatarKevin B. Smith <kevin.b.smith@intel.com>
      Cc: Sunil K. Pandey <sunil.k.pandey@intel.com>
      Signed-off-by: default avatarH. Peter Anvin <hpa@linux.intel.com>
      Cc: H. J. Lu <hjl.tools@gmail.com>
      Link: http://lkml.kernel.org/n/tip-j21wzqv790q834n7yc6g80j1@git.kernel.org
      Cc: <stable@vger.kernel.org> # build fix only
  35. 13 Oct, 2013 1 commit