1. 23 Nov, 2017 1 commit
  2. 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
         lines).
      
      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>
      b2441318
  3. 31 Aug, 2017 1 commit
    • Naoya Horiguchi's avatar
      x86/boot/KASLR: Work around firmware bugs by excluding EFI_BOOT_SERVICES_* and... · 0982adc7
      Naoya Horiguchi authored
      x86/boot/KASLR: Work around firmware bugs by excluding EFI_BOOT_SERVICES_* and EFI_LOADER_* from KASLR's choice
      
      There's a potential bug in how we select the KASLR kernel address n
      the early boot code.
      
      The KASLR boot code currently chooses the kernel image's physical memory
      location from E820_TYPE_RAM regions by walking over all e820 entries.
      
      E820_TYPE_RAM includes EFI_BOOT_SERVICES_CODE and EFI_BOOT_SERVICES_DATA
      as well, so those regions can end up hosting the kernel image. According to
      the UEFI spec, all memory regions marked as EfiBootServicesCode and
      EfiBootServicesData are available as free memory after the first call
      to ExitBootServices(). I.e. so such regions should be usable for the
      kernel, per spec.
      
      In real life however, we have workarounds for broken x86 firmware,
      where we keep such regions reserved until SetVirtualAddressMap() is done.
      
      See the following code in should_map_region():
      
      	static bool should_map_region(efi_memory_desc_t *md)
      	{
      		...
      		/*
      		 * Map boot services regions as a workaround for buggy
      		 * firmware that accesses them even when they shouldn't.
      		 *
      		 * See efi_{reserve,free}_boot_services().
      		 */
      		if (md->type =3D=3D EFI_BOOT_SERVICES_CODE ||
      			md->type =3D=3D EFI_BOOT_SERVICES_DATA)
      				return false;
      
      This workaround suppressed a boot crash, but potential issues still
      remain because no one prevents the regions from overlapping with kernel
      image by KASLR.
      
      So let's make sure that EFI_BOOT_SERVICES_{CODE|DATA} regions are never
      chosen as kernel memory for the workaround to work fine.
      
      Furthermore, EFI_LOADER_{CODE|DATA} regions are also excluded because
      they can be used after ExitBootServices() as defined in EFI spec.
      
      As a result, we choose kernel address only from EFI_CONVENTIONAL_MEMORY
      which is the only memory type we know to be safely free.
      Signed-off-by: default avatarNaoya Horiguchi <n-horiguchi@ah.jp.nec.com>
      Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
      Cc: Baoquan He <bhe@redhat.com>
      Cc: Junichi Nomura <j-nomura@ce.jp.nec.com>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Matt Fleming <matt@codeblueprint.co.uk>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Garnier <thgarnie@google.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: fanc.fnst@cn.fujitsu.com
      Cc: izumi.taku@jp.fujitsu.com
      Link: http://lkml.kernel.org/r/20170828074444.GC23181@hori1.linux.bs1.fc.nec.co.jp
      [ Rewrote/fixed/clarified the changelog and the in code comments. ]
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      0982adc7
  4. 17 Aug, 2017 1 commit
    • Baoquan He's avatar
      x86/boot/KASLR: Prefer mirrored memory regions for the kernel physical address · c05cd797
      Baoquan He authored
      Currently KASLR will parse all e820 entries of RAM type and add all
      candidate positions into the slots array. After that we choose one slot
      randomly as the new position which the kernel will be decompressed into
      and run at.
      
      On systems with EFI enabled, e820 memory regions are coming from EFI
      memory regions by combining adjacent regions.
      
      These EFI memory regions have various attributes, and the "mirrored"
      attribute is one of them. The physical memory region whose descriptors
      in EFI memory map has EFI_MEMORY_MORE_RELIABLE attribute (bit: 16) are
      mirrored. The address range mirroring feature of the kernel arranges such
      mirrored regions into normal zones and other regions into movable zones.
      
      With the mirroring feature enabled, the code and data of the kernel can only
      be located in the more reliable mirrored regions. However, the current KASLR
      code doesn't check EFI memory entries, and could choose a new kernel position
      in non-mirrored regions. This will break the intended functionality of the
      address range mirroring feature.
      
      To fix this, if EFI is detected, iterate EFI memory map and pick the mirrored
      region to process for adding candidate of randomization slot. If EFI is disabled
      or no mirrored region found, still process the e820 memory map.
      Signed-off-by: default avatarBaoquan He <bhe@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: ard.biesheuvel@linaro.org
      Cc: fanc.fnst@cn.fujitsu.com
      Cc: izumi.taku@jp.fujitsu.com
      Cc: keescook@chromium.org
      Cc: linux-efi@vger.kernel.org
      Cc: matt@codeblueprint.co.uk
      Cc: n-horiguchi@ah.jp.nec.com
      Cc: thgarnie@google.com
      Link: http://lkml.kernel.org/r/1502722464-20614-3-git-send-email-bhe@redhat.com
      [ Rewrote most of the text. ]
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      c05cd797
  5. 18 Jul, 2017 3 commits
  6. 30 Jun, 2017 1 commit
  7. 31 May, 2017 1 commit
    • Arnd Bergmann's avatar
      x86/KASLR: Use the right memcpy() implementation · 5b8b9cf7
      Arnd Bergmann authored
      The decompressor has its own implementation of the string functions,
      but has to include the right header to get those, while implicitly
      including linux/string.h may result in a link error:
      
        arch/x86/boot/compressed/kaslr.o: In function `choose_random_location':
        kaslr.c:(.text+0xf51): undefined reference to `_mmx_memcpy'
      
      This has appeared now as KASLR started using memcpy(), via:
      
      	d52e7d5a ("x86/KASLR: Parse all 'memmap=' boot option entries")
      
      Other files in the decompressor already do the same thing.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Acked-by: default avatarBaoquan He <bhe@redhat.com>
      Cc: Dave Jiang <dave.jiang@intel.com>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Garnier <thgarnie@google.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Link: http://lkml.kernel.org/r/20170530091446.1000183-1-arnd@arndb.deSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      5b8b9cf7
  8. 24 May, 2017 2 commits
  9. 28 Apr, 2017 1 commit
    • Baoquan He's avatar
      x86/KASLR: Fix kexec kernel boot crash when KASLR randomization fails · da63b6b2
      Baoquan He authored
      Dave found that a kdump kernel with KASLR enabled will reset to the BIOS
      immediately if physical randomization failed to find a new position for
      the kernel. A kernel with the 'nokaslr' option works in this case.
      
      The reason is that KASLR will install a new page table for the identity
      mapping, while it missed building it for the original kernel location
      if KASLR physical randomization fails.
      
      This only happens in the kexec/kdump kernel, because the identity mapping
      has been built for kexec/kdump in the 1st kernel for the whole memory by
      calling init_pgtable(). Here if physical randomizaiton fails, it won't build
      the identity mapping for the original area of the kernel but change to a
      new page table '_pgtable'. Then the kernel will triple fault immediately
      caused by no identity mappings.
      
      The normal kernel won't see this bug, because it comes here via startup_32()
      and CR3 will be set to _pgtable already. In startup_32() the identity
      mapping is built for the 0~4G area. In KASLR we just append to the existing
      area instead of entirely overwriting it for on-demand identity mapping
      building. So the identity mapping for the original area of kernel is still
      there.
      
      To fix it we just switch to the new identity mapping page table when physical
      KASLR succeeds. Otherwise we keep the old page table unchanged just like
      "nokaslr" does.
      Signed-off-by: default avatarBaoquan He <bhe@redhat.com>
      Signed-off-by: default avatarDave Young <dyoung@redhat.com>
      Acked-by: default avatarKees Cook <keescook@chromium.org>
      Cc: Borislav Petkov <bp@suse.de>
      Cc: Dave Jiang <dave.jiang@intel.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Garnier <thgarnie@google.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Link: http://lkml.kernel.org/r/1493278940-5885-1-git-send-email-bhe@redhat.comSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      da63b6b2
  10. 29 Jan, 2017 1 commit
    • Ingo Molnar's avatar
      x86/boot/e820: Separate the E820 ABI structures from the in-kernel structures · 7410aa1c
      Ingo Molnar authored
      Linus pointed out that relying on the compiler to pack structures with
      enums is fragile not just for the kernel, but for external tooling as
      well which might rely on our UAPI headers.
      
      So separate the two from each other: introduce 'struct boot_e820_entry',
      which is the boot protocol entry format.
      
      This actually simplifies the code, as e820__update_table() is now never
      called directly with boot protocol table entries - we can rely on
      append_e820_table() and do a e820__update_table() call afterwards.
      
      ( This will allow further simplifications of __e820__update_table(),
        but that will be done in a separate patch. )
      
      This change also has the side effect of not modifying the bootparams structure
      anymore - which might be useful for debugging. In theory we could even constify
      the boot_params structure - at least from the E820 code's point of view.
      
      Remove the uapi/asm/e820/types.h file, as it's not used anymore - all
      kernel side E820 types are defined in asm/e820/types.h.
      Reported-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Cc: Alex Thorlton <athorlton@sgi.com>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Dan Williams <dan.j.williams@intel.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Huang, Ying <ying.huang@intel.com>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Juergen Gross <jgross@suse.com>
      Cc: Paul Jackson <pj@sgi.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Rafael J. Wysocki <rjw@sisk.pl>
      Cc: Tejun Heo <tj@kernel.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Wei Yang <richard.weiyang@gmail.com>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Cc: linux-kernel@vger.kernel.org
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      7410aa1c
  11. 28 Jan, 2017 4 commits
    • Ingo Molnar's avatar
      x86/boot/e820: Prefix the E820_* type names with "E820_TYPE_" · 09821ff1
      Ingo Molnar authored
      So there's a number of constants that start with "E820" but which
      are not types - these create a confusing mixture when seen together
      with 'enum e820_type' values:
      
      	E820MAP
      	E820NR
      	E820_X_MAX
      	E820MAX
      
      To better differentiate the 'enum e820_type' values prefix them
      with E820_TYPE_.
      
      No change in functionality.
      
      Cc: Alex Thorlton <athorlton@sgi.com>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Dan Williams <dan.j.williams@intel.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Huang, Ying <ying.huang@intel.com>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Juergen Gross <jgross@suse.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Paul Jackson <pj@sgi.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Rafael J. Wysocki <rjw@sisk.pl>
      Cc: Tejun Heo <tj@kernel.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Wei Yang <richard.weiyang@gmail.com>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Cc: linux-kernel@vger.kernel.org
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      09821ff1
    • Ingo Molnar's avatar
      x86/boot/e820: Rename everything to e820_table · 61a50101
      Ingo Molnar authored
      No change in functionality.
      
      Cc: Alex Thorlton <athorlton@sgi.com>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Dan Williams <dan.j.williams@intel.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Huang, Ying <ying.huang@intel.com>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Juergen Gross <jgross@suse.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Paul Jackson <pj@sgi.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Rafael J. Wysocki <rjw@sisk.pl>
      Cc: Tejun Heo <tj@kernel.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Wei Yang <richard.weiyang@gmail.com>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Cc: linux-kernel@vger.kernel.org
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      61a50101
    • Ingo Molnar's avatar
      x86/boot/e820: Rename 'e820_map' variables to 'e820_array' · acd4c048
      Ingo Molnar authored
      In line with the rename to 'struct e820_array', harmonize the naming of common e820
      table variable names as well:
      
       e820          =>  e820_array
       e820_saved    =>  e820_array_saved
       e820_map      =>  e820_array
       initial_e820  =>  e820_array_init
      
      This makes the variable names more consistent  and easier to grep for.
      
      No change in functionality.
      
      Cc: Alex Thorlton <athorlton@sgi.com>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Dan Williams <dan.j.williams@intel.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Huang, Ying <ying.huang@intel.com>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Juergen Gross <jgross@suse.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Paul Jackson <pj@sgi.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Rafael J. Wysocki <rjw@sisk.pl>
      Cc: Tejun Heo <tj@kernel.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Wei Yang <richard.weiyang@gmail.com>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Cc: linux-kernel@vger.kernel.org
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      acd4c048
    • Ingo Molnar's avatar
      x86/boot/e820: Rename the basic e820 data types to 'struct e820_entry' and 'struct e820_array' · 8ec67d97
      Ingo Molnar authored
      The 'e820entry' and 'e820map' names have various annoyances:
      
       - the missing underscore departs from the usual kernel style
         and makes the code look weird,
      
       - in the past I kept confusing the 'map' with the 'entry', because
         a 'map' is ambiguous in that regard,
      
       - it's not really clear from the 'e820map' that this is a regular
         C array.
      
      Rename them to 'struct e820_entry' and 'struct e820_array' accordingly.
      
      ( Leave the legacy UAPI header alone but do the rename in the bootparam.h
        and e820/types.h file - outside tools relying on these defines should
        either adjust their code, or should use the legacy header, or should
        create their private copies for the definitions. )
      
      No change in functionality.
      
      Cc: Alex Thorlton <athorlton@sgi.com>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Dan Williams <dan.j.williams@intel.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Huang, Ying <ying.huang@intel.com>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Juergen Gross <jgross@suse.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Paul Jackson <pj@sgi.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Rafael J. Wysocki <rjw@sisk.pl>
      Cc: Tejun Heo <tj@kernel.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Wei Yang <richard.weiyang@gmail.com>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Cc: linux-kernel@vger.kernel.org
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      8ec67d97
  12. 25 Jan, 2017 1 commit
    • Dave Jiang's avatar
      x86/boot: Fix KASLR and memmap= collision · f2844249
      Dave Jiang authored
      CONFIG_RANDOMIZE_BASE=y relocates the kernel to a random base address.
      
      However it does not take into account the memmap= parameter passed in from
      the kernel command line. This results in the kernel sometimes being put in
      the middle of memmap.
      
      Teach KASLR to not insert the kernel in memmap defined regions. We support
      up to 4 memmap regions: any additional regions will cause KASLR to disable.
      
      The mem_avoid set has been augmented to add up to 4 unusable regions of
      memmaps provided by the user to exclude those regions from the set of valid
      address range to insert the uncompressed kernel image.
      
      The nn@ss ranges will be skipped by the mem_avoid set since it indicates
      that memory is useable.
      Signed-off-by: default avatarDave Jiang <dave.jiang@intel.com>
      Reviewed-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Acked-by: default avatarKees Cook <keescook@chromium.org>
      Acked-by: default avatarBaoquan He <bhe@redhat.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: dan.j.williams@intel.com
      Cc: david@fromorbit.com
      Cc: linux-nvdimm@lists.01.org
      Link: http://lkml.kernel.org/r/148417664156.131935.2248592164852799738.stgit@djiang5-desk3.ch.intel.comSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      f2844249
  13. 08 Jul, 2016 2 commits
    • Thomas Garnier's avatar
      x86/mm: Refactor KASLR entropy functions · d899a7d1
      Thomas Garnier authored
      Move the KASLR entropy functions into arch/x86/lib to be used in early
      kernel boot for KASLR memory randomization.
      Signed-off-by: default avatarThomas Garnier <thgarnie@google.com>
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      Cc: Alexander Kuleshov <kuleshovmail@gmail.com>
      Cc: Alexander Popov <alpopov@ptsecurity.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
      Cc: Baoquan He <bhe@redhat.com>
      Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Borislav Petkov <bp@suse.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Christian Borntraeger <borntraeger@de.ibm.com>
      Cc: Dan Williams <dan.j.williams@intel.com>
      Cc: Dave Hansen <dave.hansen@linux.intel.com>
      Cc: Dave Young <dyoung@redhat.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: Dmitry Vyukov <dvyukov@google.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Jan Beulich <JBeulich@suse.com>
      Cc: Joerg Roedel <jroedel@suse.de>
      Cc: Jonathan Corbet <corbet@lwn.net>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Juergen Gross <jgross@suse.com>
      Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Lv Zheng <lv.zheng@intel.com>
      Cc: Mark Salter <msalter@redhat.com>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: Matt Fleming <matt@codeblueprint.co.uk>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Stephen Smalley <sds@tycho.nsa.gov>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Toshi Kani <toshi.kani@hpe.com>
      Cc: Xiao Guangrong <guangrong.xiao@linux.intel.com>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Cc: kernel-hardening@lists.openwall.com
      Cc: linux-doc@vger.kernel.org
      Link: http://lkml.kernel.org/r/1466556426-32664-2-git-send-email-keescook@chromium.orgSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      d899a7d1
    • Baoquan He's avatar
      x86/KASLR: Fix boot crash with certain memory configurations · 6daa2ec0
      Baoquan He authored
      Ye Xiaolong reported this boot crash:
      
      |
      |  XZ-compressed data is corrupt
      |
      |   -- System halted
      |
      
      Fix the bug in mem_avoid_overlap() of finding the earliest overlap.
      Reported-and-tested-by: default avatarYe Xiaolong <xiaolong.ye@intel.com>
      Signed-off-by: default avatarBaoquan He <bhe@redhat.com>
      Cc: Kees Cook <keescook@chromium.org>
      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
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      6daa2ec0
  14. 26 Jun, 2016 5 commits
    • Yinghai Lu's avatar
      x86/KASLR: Allow randomization below the load address · e066cc47
      Yinghai Lu authored
      Currently the kernel image physical address randomization's lower
      boundary is the original kernel load address.
      
      For bootloaders that load kernels into very high memory (e.g. kexec),
      this means randomization takes place in a very small window at the
      top of memory, ignoring the large region of physical memory below
      the load address.
      
      Since mem_avoid[] is already correctly tracking the regions that must be
      avoided, this patch changes the minimum address to whatever is less:
      512M (to conservatively avoid unknown things in lower memory) or the
      load address. Now, for example, if the kernel is loaded at 8G, [512M,
      8G) will be added to the list of possible physical memory positions.
      Signed-off-by: default avatarYinghai Lu <yinghai@kernel.org>
      [ Rewrote the changelog, refactored the code to use min(). ]
      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>
      Link: http://lkml.kernel.org/r/1464216334-17200-6-git-send-email-keescook@chromium.org
      [ Edited the changelog some more, plus the code comment as well. ]
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      e066cc47
    • Kees Cook's avatar
      x86/KASLR: Extend kernel image physical address randomization to addresses larger than 4G · ed9f007e
      Kees Cook authored
      We want the physical address to be randomized anywhere between
      16MB and the top of physical memory (up to 64TB).
      
      This patch exchanges the prior slots[] array for the new slot_areas[]
      array, and lifts the limitation of KERNEL_IMAGE_SIZE on the physical
      address offset for 64-bit. As before, process_e820_entry() walks
      memory and populates slot_areas[], splitting on any detected mem_avoid
      collisions.
      
      Finally, since the slots[] array and its associated functions are not
      needed any more, so they are removed.
      
      Based on earlier patches by Baoquan He.
      
      Originally-from: Baoquan 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: 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-5-git-send-email-keescook@chromium.orgSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      ed9f007e
    • 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
    • Kees Cook's avatar
      x86/KASLR: Clarify identity map interface · 11fdf97a
      Kees Cook authored
      This extracts the call to prepare_level4() into a top-level function
      that the user of the pagetable.c interface must call to initialize
      the new page tables. For clarity and to match the "finalize" function,
      it has been renamed to initialize_identity_maps(). This function also
      gains the initialization of mapping_info so we don't have to do it each
      time in add_identity_map().
      
      Additionally add copyright notice to the top, to make it clear that the
      bulk of the pagetable.c code was written by Yinghai, and that I just
      added bugs later. :)
      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-3-git-send-email-keescook@chromium.orgSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      11fdf97a
    • Kees Cook's avatar
      x86/KASLR, x86/power: Remove x86 hibernation restrictions · 65fe935d
      Kees Cook authored
      With the following fix:
      
        70595b479ce1 ("x86/power/64: Fix crash whan the hibernation code passes control to the image kernel")
      
      ... there is no longer a problem with hibernation resuming a
      KASLR-booted kernel image, so remove the restriction.
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      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: H. Peter Anvin <hpa@zytor.com>
      Cc: Jonathan Corbet <corbet@lwn.net>
      Cc: Len Brown <len.brown@intel.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Linux PM list <linux-pm@vger.kernel.org>
      Cc: Logan Gunthorpe <logang@deltatee.com>
      Cc: Pavel Machek <pavel@ucw.cz>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Stephen Smalley <sds@tycho.nsa.gov>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Cc: linux-doc@vger.kernel.org
      Link: http://lkml.kernel.org/r/20160613221002.GA29719@www.outflux.netSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      65fe935d
  15. 10 May, 2016 6 commits
    • Kees Cook's avatar
      x86/KASLR: Clarify purpose of each get_random_long() · d2d3462f
      Kees Cook authored
      KASLR will be calling get_random_long() twice, but the debug output
      won't distinguishing between them. This patch adds a report on when it
      is fetching the physical vs virtual address. With this, once the virtual
      offset is separate, the report changes from:
      
       KASLR using RDTSC...
       KASLR using RDTSC...
      
      into:
      
       Physical KASLR using RDTSC...
       Virtual KASLR using RDTSC...
      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: 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/1462825332-10505-7-git-send-email-keescook@chromium.orgSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      d2d3462f
    • Baoquan He's avatar
      x86/KASLR: Add virtual address choosing function · 071a7493
      Baoquan He authored
      To support randomizing the kernel virtual address separately from the
      physical address, this patch adds find_random_virt_addr() to choose
      a slot anywhere between LOAD_PHYSICAL_ADDR and KERNEL_IMAGE_SIZE.
      Since this address is virtual, not physical, we can place the kernel
      anywhere in this region, as long as it is aligned and (in the case of
      kernel being larger than the slot size) placed with enough room to load
      the entire kernel image.
      
      For clarity and readability, find_random_addr() is renamed to
      find_random_phys_addr() and has "size" renamed to "image_size" to match
      find_random_virt_addr().
      Signed-off-by: default avatarBaoquan He <bhe@redhat.com>
      [ Rewrote changelog, refactored slot calculation for readability. ]
      [ Renamed find_random_phys_addr() and size argument. ]
      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: 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: 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/1462825332-10505-6-git-send-email-keescook@chromium.orgSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      071a7493
    • Kees Cook's avatar
      x86/KASLR: Return earliest overlap when avoiding regions · 06486d6c
      Kees Cook authored
      In preparation for being able to detect where to split up contiguous
      memory regions that overlap with memory regions to avoid, we need to
      pass back what the earliest overlapping region was. This modifies the
      overlap checker to return that information.
      
      Based on a separate mem_min_overlap() implementation by 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: 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/1462825332-10505-5-git-send-email-keescook@chromium.orgSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      06486d6c
    • Baoquan He's avatar
      x86/KASLR: Add 'struct slot_area' to manage random_addr slots · c401cf15
      Baoquan He authored
      In order to support KASLR moving the kernel anywhere in physical memory
      (which could be up to 64TB), we need to handle counting the potential
      randomization locations in a more efficient manner.
      
      In the worst case with 64TB, there could be roughly 32 * 1024 * 1024
      randomization slots if CONFIG_PHYSICAL_ALIGN is 0x1000000. Currently
      the starting address of candidate positions is stored into the slots[]
      array, one at a time. This method would cost too much memory and it's
      also very inefficient to get and save the slot information into the slot
      array one by one.
      
      This patch introduces 'struct slot_area' to manage each contiguous region
      of randomization slots. Each slot_area will contain the starting address
      and how many available slots are in this area. As with the original code,
      the slot_areas[] will avoid the mem_avoid[] regions.
      
      Since setup_data is a linked list, it could contain an unknown number
      of memory regions to be avoided, which could cause us to fragment
      the contiguous memory that the slot_area array is tracking. In normal
      operation this level of fragmentation will be extremely rare, but we
      choose a suitably large value (100) for the array. If setup_data forces
      the slot_area array to become highly fragmented and there are more
      slots available beyond the first 100 found, the rest will be ignored
      for KASLR selection.
      
      The function store_slot_info() is used to calculate the number of slots
      available in the passed-in memory region and stores it into slot_areas[]
      after adjusting for alignment and size requirements.
      Signed-off-by: default avatarBaoquan He <bhe@redhat.com>
      [ Rewrote changelog, squashed with new functions. ]
      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: 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: 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/1462825332-10505-4-git-send-email-keescook@chromium.orgSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      c401cf15
    • Kees Cook's avatar
      x86/boot: Add missing file header comments · cb18ef0d
      Kees Cook authored
      There were some files with missing header comments. Since they are
      included from both compressed and regular kernels, make note of that.
      Also corrects a typo in the mem_avoid 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: 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: 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/1462825332-10505-3-git-send-email-keescook@chromium.orgSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      cb18ef0d
    • Borislav Petkov's avatar
      x86/boot: Comment what finalize_identity_maps() does · 36a39ac9
      Borislav Petkov authored
      So it is not really obvious that finalize_identity_maps() doesn't do any
      finalization but it *actually* writes CR3 with the ident PGD. Comment
      that at the call site.
      Signed-off-by: default avatarBorislav Petkov <bp@suse.de>
      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: Kees Cook <keescook@chromium.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: akpm@linux-foundation.org
      Cc: bhe@redhat.com
      Cc: dyoung@redhat.com
      Cc: jkosina@suse.cz
      Cc: linux-tip-commits@vger.kernel.org
      Cc: luto@kernel.org
      Cc: vgoyal@redhat.com
      Cc: yinghai@kernel.org
      Link: http://lkml.kernel.org/r/20160507100541.GA24613@pd.tnicSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      36a39ac9
  16. 07 May, 2016 3 commits
    • 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>
      3a94707d
    • Kees Cook's avatar
      x86/KASLR: Improve comments around the mem_avoid[] logic · ed09acde
      Kees Cook authored
      This attempts to improve the comments that describe how the memory
      range used for decompression is avoided. Additionally uses an enum
      instead of raw numbers for the mem_avoid[] indexing.
      Suggested-by: default avatarBorislav Petkov <bp@alien8.de>
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Baoquan He <bhe@redhat.com>
      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: 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/20160506194459.GA16480@www.outflux.netSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      ed09acde
    • Borislav Petkov's avatar
      x86/boot: Simplify pointer casting in choose_random_location() · 549f90db
      Borislav Petkov authored
      Pass them down as 'unsigned long' directly and get rid of more casting and
      assignments.
      Signed-off-by: default avatarBorislav Petkov <bp@suse.de>
      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: Kees Cook <keescook@chromium.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: akpm@linux-foundation.org
      Cc: bhe@redhat.com
      Cc: dyoung@redhat.com
      Cc: linux-tip-commits@vger.kernel.org
      Cc: luto@kernel.org
      Cc: vgoyal@redhat.com
      Cc: yinghai@kernel.org
      Link: http://lkml.kernel.org/r/20160506115015.GI24044@pd.tnicSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      549f90db
  17. 06 May, 2016 2 commits
    • Yinghai Lu's avatar
      x86/KASLR: Consolidate mem_avoid[] entries · 9dc1969c
      Yinghai Lu authored
      The mem_avoid[] array is used to track positions that should be avoided (like
      the compressed kernel, decompression code, etc) when selecting a memory
      position for the randomly relocated kernel. Since ZO is now at the end of
      the decompression buffer and the decompression code (and its heap and
      stack) are at the front, we can safely consolidate the decompression entry,
      the heap entry, and the stack entry. The boot_params memory, however, could
      be elsewhere, so it should be explicitly included.
      Signed-off-by: default avatarYinghai Lu <yinghai@kernel.org>
      Signed-off-by: default avatarBaoquan He <bhe@redhat.com>
      [ Rwrote changelog, cleaned up code 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: 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: kernel-hardening@lists.openwall.com
      Cc: lasse.collin@tukaani.org
      Link: http://lkml.kernel.org/r/1462486436-3707-3-git-send-email-keescook@chromium.orgSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      9dc1969c
    • Kees Cook's avatar
      x86/boot: Clean up pointer casting · 2bc1cd39
      Kees Cook authored
      Currently extract_kernel() defines the input and output buffer pointers
      as "unsigned char *" since that's effectively what they are. It passes
      these to the decompressor routine and to the ELF parser, which both
      logically deal with buffer pointers too. There is some casting ("unsigned
      long") done to validate the numerical value of the pointers, but it is
      relatively limited.
      
      However, choose_random_location() operates almost exclusively on the
      numerical representation of these pointers, so it ended up carrying
      a lot of "unsigned long" casts. With the future physical/virtual split
      these casts were going to multiply, so this attempts to solve the
      problem by doing all the casting in choose_random_location()'s entry
      and return instead of through-out the code. Adjusts argument names to
      be more meaningful, and changes one us of "choice" to "output" to make
      the future physical/virtual split more clear (i.e. "choice" should be
      strictly a function return value and not used as an intermediate).
      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: 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: Yinghai Lu <yinghai@kernel.org>
      Cc: kernel-hardening@lists.openwall.com
      Cc: lasse.collin@tukaani.org
      Link: http://lkml.kernel.org/r/1462486436-3707-2-git-send-email-keescook@chromium.orgSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      2bc1cd39
  18. 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
  19. 22 Apr, 2016 3 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
    • Baoquan He's avatar
      x86/KASLR: Drop CONFIG_RANDOMIZE_BASE_MAX_OFFSET · e8581e3d
      Baoquan He authored
      Currently CONFIG_RANDOMIZE_BASE_MAX_OFFSET is used to limit the maximum
      offset for kernel randomization. This limit doesn't need to be a CONFIG
      since it is tied completely to KERNEL_IMAGE_SIZE, and will make no sense
      once physical and virtual offsets are randomized separately. This patch
      removes CONFIG_RANDOMIZE_BASE_MAX_OFFSET and consolidates the Kconfig
      help text.
      
      [kees: rewrote changelog, dropped KERNEL_IMAGE_SIZE_DEFAULT, rewrote help]
      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@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-3-git-send-email-keescook@chromium.orgSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      e8581e3d
    • 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