1. 25 7月, 2017 1 次提交
  2. 24 5月, 2017 1 次提交
  3. 25 1月, 2017 1 次提交
    • D
      x86/boot: Fix KASLR and memmap= collision · f2844249
      Dave Jiang 提交于
      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: NDave Jiang <dave.jiang@intel.com>
      Reviewed-by: NThomas Gleixner <tglx@linutronix.de>
      Acked-by: NKees Cook <keescook@chromium.org>
      Acked-by: NBaoquan 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: NIngo Molnar <mingo@kernel.org>
      f2844249
  4. 09 1月, 2017 1 次提交
  5. 09 6月, 2016 1 次提交
  6. 23 3月, 2015 1 次提交
    • A
      x86/boot: Standardize strcmp() · 1c1d046b
      Arjun Sreedharan 提交于
      strcmp() is always expected to return 0 when arguments are equal,
      negative when its first argument @str1 is less than its second argument
      @str2 and a positive value otherwise. Previously strcmp("a", "b")
      returned 1. Now it gives -1, as it is supposed to.
      
      Until now this bug never triggered, because all uses for strcmp() in the
      boot code tested for nonzero:
      
        triton:~/tip> git grep strcmp arch/x86/boot/
        arch/x86/boot/boot.h:int strcmp(const char *str1, const char *str2);
        arch/x86/boot/edd.c:            if (!strcmp(eddarg, "skipmbr") || !strcmp(eddarg, "skip")) {
        arch/x86/boot/edd.c:            else if (!strcmp(eddarg, "off"))
        arch/x86/boot/edd.c:            else if (!strcmp(eddarg, "on"))
      
      should in the future strcmp() be used in a comparative way in the boot
      code, it might have led to (not so subtle) bugs.
      Signed-off-by: NArjun Sreedharan <arjun024@gmail.com>
      Signed-off-by: NBorislav Petkov <bp@suse.de>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Link: http://lkml.kernel.org/r/1426520267-1803-1-git-send-email-arjun024@gmail.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      1c1d046b
  7. 08 5月, 2014 2 次提交
  8. 20 3月, 2014 1 次提交
  9. 13 12月, 2011 1 次提交
    • M
      x86, efi: EFI boot stub support · 291f3632
      Matt Fleming 提交于
      There is currently a large divide between kernel development and the
      development of EFI boot loaders. The idea behind this patch is to give
      the kernel developers full control over the EFI boot process. As
      H. Peter Anvin put it,
      
      "The 'kernel carries its own stub' approach been very successful in
      dealing with BIOS, and would make a lot of sense to me for EFI as
      well."
      
      This patch introduces an EFI boot stub that allows an x86 bzImage to
      be loaded and executed by EFI firmware. The bzImage appears to the
      firmware as an EFI application. Luckily there are enough free bits
      within the bzImage header so that it can masquerade as an EFI
      application, thereby coercing the EFI firmware into loading it and
      jumping to its entry point. The beauty of this masquerading approach
      is that both BIOS and EFI boot loaders can still load and run the same
      bzImage, thereby allowing a single kernel image to work in any boot
      environment.
      
      The EFI boot stub supports multiple initrds, but they must exist on
      the same partition as the bzImage. Command-line arguments for the
      kernel can be appended after the bzImage name when run from the EFI
      shell, e.g.
      
      Shell> bzImage console=ttyS0 root=/dev/sdb initrd=initrd.img
      
      v7:
       - Fix checkpatch warnings.
      
      v6:
      
       - Try to allocate initrd memory just below hdr->inird_addr_max.
      
      v5:
      
       - load_options_size is UTF-16, which needs dividing by 2 to convert
         to the corresponding ASCII size.
      
      v4:
      
       - Don't read more than image->load_options_size
      
      v3:
      
       - Fix following warnings when compiling CONFIG_EFI_STUB=n
      
         arch/x86/boot/tools/build.c: In function ‘main’:
         arch/x86/boot/tools/build.c:138:24: warning: unused variable ‘pe_header’
         arch/x86/boot/tools/build.c:138:15: warning: unused variable ‘file_sz’
      
       - As reported by Matthew Garrett, some Apple machines have GOPs that
         don't have hardware attached. We need to weed these out by
         searching for ones that handle the PCIIO protocol.
      
       - Don't allocate memory if no initrds are on cmdline
       - Don't trust image->load_options_size
      
      Maarten Lankhorst noted:
       - Don't strip first argument when booted from efibootmgr
       - Don't allocate too much memory for cmdline
       - Don't update cmdline_size, the kernel considers it read-only
       - Don't accept '\n' for initrd names
      
      v2:
      
       - File alignment was too large, was 8192 should be 512. Reported by
         Maarten Lankhorst on LKML.
       - Added UGA support for graphics
       - Use VIDEO_TYPE_EFI instead of hard-coded number.
       - Move linelength assignment until after we've assigned depth
       - Dynamically fill out AddressOfEntryPoint in tools/build.c
       - Don't use magic number for GDT/TSS stuff. Requested by Andi Kleen
       - The bzImage may need to be relocated as it may have been loaded at
         a high address address by the firmware. This was required to get my
         macbook booting because the firmware loaded it at 0x7cxxxxxx, which
         triggers this error in decompress_kernel(),
      
      	if (heap > ((-__PAGE_OFFSET-(128<<20)-1) & 0x7fffffff))
      		error("Destination address too large");
      
      Cc: Mike Waychison <mikew@google.com>
      Cc: Matthew Garrett <mjg@redhat.com>
      Tested-by: NHenrik Rydberg <rydberg@euromail.se>
      Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
      Link: http://lkml.kernel.org/r/1321383097.2657.9.camel@mfleming-mobl1.ger.corp.intel.comSigned-off-by: NH. Peter Anvin <hpa@linux.intel.com>
      291f3632
  10. 14 7月, 2010 1 次提交
  11. 13 7月, 2010 1 次提交
  12. 20 4月, 2008 1 次提交
  13. 11 10月, 2007 1 次提交
  14. 13 7月, 2007 1 次提交