1. 20 Nov, 2018 1 commit
  2. 10 Oct, 2018 1 commit
    • Juergen Gross's avatar
      x86/boot: Add ACPI RSDP address to setup_header · ae7e1238
      Juergen Gross authored
      Xen PVH guests receive the address of the RSDP table from Xen. In order
      to support booting a Xen PVH guest via Grub2 using the standard x86
      boot entry we need a way for Grub2 to pass the RSDP address to the
      kernel.
      
      For this purpose expand the struct setup_header to hold the physical
      address of the RSDP address. Being zero means it isn't specified and
      has to be located the legacy way (searching through low memory or
      EBDA).
      
      While documenting the new setup_header layout and protocol version
      2.14 add the missing documentation of protocol version 2.13.
      
      There are Grub2 versions in several distros with a downstream patch
      violating the boot protocol by writing past the end of setup_header.
      This requires another update of the boot protocol to enable the kernel
      to distinguish between a specified RSDP address and one filled with
      garbage by such a broken Grub2.
      
      From protocol 2.14 on Grub2 will write the version it is supporting
      (but never a higher value than found to be supported by the kernel)
      ored with 0x8000 to the version field of setup_header. This enables
      the kernel to know up to which field Grub2 has written information
      to. All fields after that are supposed to be clobbered.
      Signed-off-by: default avatarJuergen Gross <jgross@suse.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: boris.ostrovsky@oracle.com
      Cc: bp@alien8.de
      Cc: corbet@lwn.net
      Cc: linux-doc@vger.kernel.org
      Cc: xen-devel@lists.xenproject.org
      Link: http://lkml.kernel.org/r/20181010061456.22238-3-jgross@suse.comSigned-off-by: Ingo Molnar's avatarIngo Molnar <mingo@kernel.org>
      ae7e1238
  3. 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
  4. 11 Oct, 2017 1 commit
  5. 29 Aug, 2017 1 commit
  6. 28 Jan, 2017 2 commits
    • Ingo Molnar's avatar
      x86/boot/e820: Remove assembly guard from asm/e820/types.h · b0bd00d6
      Ingo Molnar authored
      There's an assembly guard in asm/e820/types.h, and only
      a single .S file includes this header: arch/x86/boot/header.S,
      but it does not actually make use of any of the E820 defines.
      
      Remove the inclusion and remove the assembly guard as well.
      
      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: Ingo Molnar's avatarIngo Molnar <mingo@kernel.org>
      b0bd00d6
    • Ingo Molnar's avatar
      x86/boot/e820: Move asm/e820.h to asm/e820/api.h · 66441bd3
      Ingo Molnar authored
      In line with asm/e820/types.h, move the e820 API declarations to
      asm/e820/api.h and update all usage sites.
      
      This is just a mechanical, obviously correct move & replace patch,
      there will be subsequent changes to clean up the code and to make
      better use of the new header organization.
      
      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: Ingo Molnar's avatarIngo Molnar <mingo@kernel.org>
      66441bd3
  7. 29 Apr, 2016 1 commit
    • Yinghai Lu's avatar
      x86/boot: Calculate decompression size during boot not build · d607251b
      Yinghai Lu authored
      Currently z_extract_offset is calculated in boot/compressed/mkpiggy.c.
      This doesn't work well because mkpiggy.c doesn't know the details of the
      decompressor in use. As a result, it can only make an estimation, which
      has risks:
      
       - output + output_len (VO) could be much bigger than input + input_len
         (ZO). In this case, the decompressed kernel plus relocs could overwrite
         the decompression code while it is running.
      
       - The head code of ZO could be bigger than z_extract_offset. In this case
         an overwrite could happen when the head code is running to move ZO to
         the end of buffer. Though currently the size of the head code is very
         small it's still a potential risk. Since there is no rule to limit the
         size of the head code of ZO, it runs the risk of suddenly becoming a
         (hard to find) bug.
      
      Instead, this moves the z_extract_offset calculation into header.S, and
      makes adjustments to be sure that the above two cases can never happen,
      and further corrects the comments describing the calculations.
      
      Since we have (in the previous patch) made ZO always be located against
      the end of decompression buffer, z_extract_offset is only used here to
      calculate an appropriate buffer size (INIT_SIZE), and is not longer used
      elsewhere. As such, it can be removed from voffset.h.
      
      Additionally clean up #if/#else #define to improve readability.
      Signed-off-by: default avatarYinghai Lu <yinghai@kernel.org>
      Signed-off-by: default avatarBaoquan He <bhe@redhat.com>
      [ Rewrote the changelog and comments. ]
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: 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-4-git-send-email-keescook@chromium.orgSigned-off-by: Ingo Molnar's avatarIngo Molnar <mingo@kernel.org>
      d607251b
  8. 22 Apr, 2016 1 commit
    • 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: Ingo Molnar's avatarIngo Molnar <mingo@kernel.org>
      4252db10
  9. 10 Sep, 2015 1 commit
    • Dave Young's avatar
      kexec: split kexec_load syscall from kexec core code · 2965faa5
      Dave Young authored
      There are two kexec load syscalls, kexec_load another and kexec_file_load.
       kexec_file_load has been splited as kernel/kexec_file.c.  In this patch I
      split kexec_load syscall code to kernel/kexec.c.
      
      And add a new kconfig option KEXEC_CORE, so we can disable kexec_load and
      use kexec_file_load only, or vice verse.
      
      The original requirement is from Ted Ts'o, he want kexec kernel signature
      being checked with CONFIG_KEXEC_VERIFY_SIG enabled.  But kexec-tools use
      kexec_load syscall can bypass the checking.
      
      Vivek Goyal proposed to create a common kconfig option so user can compile
      in only one syscall for loading kexec kernel.  KEXEC/KEXEC_FILE selects
      KEXEC_CORE so that old config files still work.
      
      Because there's general code need CONFIG_KEXEC_CORE, so I updated all the
      architecture Kconfig with a new option KEXEC_CORE, and let KEXEC selects
      KEXEC_CORE in arch Kconfig.  Also updated general kernel code with to
      kexec_load syscall.
      
      [akpm@linux-foundation.org: coding-style fixes]
      Signed-off-by: default avatarDave Young <dyoung@redhat.com>
      Cc: Eric W. Biederman <ebiederm@xmission.com>
      Cc: Vivek Goyal <vgoyal@redhat.com>
      Cc: Petr Tesarik <ptesarik@suse.cz>
      Cc: Theodore Ts'o <tytso@mit.edu>
      Cc: Josh Boyer <jwboyer@fedoraproject.org>
      Cc: David Howells <dhowells@redhat.com>
      Cc: Geert Uytterhoeven <geert@linux-m68k.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      2965faa5
  10. 08 Aug, 2015 1 commit
  11. 18 Jul, 2014 1 commit
    • Michael Brown's avatar
      x86/efi: Request desired alignment via the PE/COFF headers · aeffc492
      Michael Brown authored
      The EFI boot stub goes to great pains to relocate the kernel image to
      an appropriately aligned address, as indicated by the ->kernel_alignment
      field in the bzImage header.  However, for the PE stub entry case, we
      can request that the EFI PE/COFF loader do the work for us.
      
      Fix by exposing the desired alignment via the SectionAlignment field
      in the PE/COFF headers.  Despite its name, this field provides an
      overall alignment requirement for the loaded file.  (Naturally, the
      FileAlignment field describes the alignment for individual sections.)
      
      There is no way in the PE/COFF headers to express the concept of
      min_alignment; we therefore do not expose the minimum (as opposed to
      preferred) alignment.
      Signed-off-by: default avatarMichael Brown <mbrown@fensystems.co.uk>
      Signed-off-by: default avatarMatt Fleming <matt.fleming@intel.com>
      aeffc492
  12. 10 Jul, 2014 1 commit
    • Michael Brown's avatar
      x86/efi: Include a .bss section within the PE/COFF headers · c7fb93ec
      Michael Brown authored
      The PE/COFF headers currently describe only the initialised-data
      portions of the image, and result in no space being allocated for the
      uninitialised-data portions.  Consequently, the EFI boot stub will end
      up overwriting unexpected areas of memory, with unpredictable results.
      
      Fix by including a .bss section in the PE/COFF headers (functionally
      equivalent to the init_size field in the bzImage header).
      Signed-off-by: default avatarMichael Brown <mbrown@fensystems.co.uk>
      Cc: Thomas Bächler <thomas@archlinux.org>
      Cc: Josh Boyer <jwboyer@fedoraproject.org>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarMatt Fleming <matt.fleming@intel.com>
      c7fb93ec
  13. 07 Jun, 2014 1 commit
    • Matt Fleming's avatar
      x86/boot: EFI_MIXED should not prohibit loading above 4G · 745c5167
      Matt Fleming authored
      commit 7d453eee ("x86/efi: Wire up CONFIG_EFI_MIXED") introduced a
      regression for the functionality to load kernels above 4G. The relevant
      (incorrect) reasoning behind this change can be seen in the commit
      message,
      
        "The xloadflags field in the bzImage header is also updated to reflect
        that the kernel supports both entry points by setting both of
        XLF_EFI_HANDOVER_32 and XLF_EFI_HANDOVER_64 when CONFIG_EFI_MIXED=y.
        XLF_CAN_BE_LOADED_ABOVE_4G is disabled so that the kernel text is
        guaranteed to be addressable with 32-bits."
      
      This is obviously bogus since 32-bit EFI loaders will never place the
      kernel above the 4G mark. So this restriction is entirely unnecessary.
      
      But things are worse than that - since we want to encourage people to
      always compile with CONFIG_EFI_MIXED=y so that their kernels work out of
      the box for both 32-bit and 64-bit firmware, commit 7d453eee
      effectively disables XLF_CAN_BE_LOADED_ABOVE_4G completely.
      
      Remove the overzealous and superfluous restriction and restore the
      XLF_CAN_BE_LOADED_ABOVE_4G functionality.
      
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Dave Young <dyoung@redhat.com>
      Cc: Vivek Goyal <vgoyal@redhat.com>
      Signed-off-by: default avatarMatt Fleming <matt.fleming@intel.com>
      Link: http://lkml.kernel.org/r/1402140380-15377-1-git-send-email-matt@console-pimps.orgSigned-off-by: default avatarH. Peter Anvin <hpa@zytor.com>
      745c5167
  14. 13 Mar, 2014 1 commit
  15. 04 Mar, 2014 2 commits
    • Matt Fleming's avatar
      x86/efi: Wire up CONFIG_EFI_MIXED · 7d453eee
      Matt Fleming authored
      Add the Kconfig option and bump the kernel header version so that boot
      loaders can check whether the handover code is available if they want.
      
      The xloadflags field in the bzImage header is also updated to reflect
      that the kernel supports both entry points by setting both of
      XLF_EFI_HANDOVER_32 and XLF_EFI_HANDOVER_64 when CONFIG_EFI_MIXED=y.
      XLF_CAN_BE_LOADED_ABOVE_4G is disabled so that the kernel text is
      guaranteed to be addressable with 32-bits.
      
      Note that no boot loaders should be using the bits set in xloadflags to
      decide which entry point to jump to. The entire scheme is based on the
      concept that 32-bit bootloaders always jump to ->handover_offset and
      64-bit loaders always jump to ->handover_offset + 512. We set both bits
      merely to inform the boot loader that it's safe to use the native
      handover offset even if the machine type in the PE/COFF header claims
      otherwise.
      Signed-off-by: default avatarMatt Fleming <matt.fleming@intel.com>
      7d453eee
    • Matt Fleming's avatar
      x86/boot: Cleanup header.S by removing some #ifdefs · 86134a1b
      Matt Fleming authored
      handover_offset is now filled out by build.c. Don't set a default value
      as it will be overwritten anyway.
      Acked-by: default avatarBorislav Petkov <bp@suse.de>
      Signed-off-by: default avatarMatt Fleming <matt.fleming@intel.com>
      86134a1b
  16. 29 Dec, 2013 1 commit
  17. 30 Jan, 2013 1 commit
  18. 27 Jan, 2013 1 commit
  19. 20 Nov, 2012 1 commit
  20. 20 Aug, 2012 1 commit
  21. 20 Jul, 2012 1 commit
    • Matt Fleming's avatar
      x86, efi: Handover Protocol · 9ca8f72a
      Matt Fleming authored
      As things currently stand, traditional EFI boot loaders and the EFI
      boot stub are carrying essentially the same initialisation code
      required to setup an EFI machine for booting a kernel. There's really
      no need to have this code in two places and the hope is that, with
      this new protocol, initialisation and booting of the kernel can be
      left solely to the kernel's EFI boot stub. The responsibilities of the
      boot loader then become,
      
         o Loading the kernel image from boot media
      
      File system code still needs to be carried by boot loaders for the
      scenario where the kernel and initrd files reside on a file system
      that the EFI firmware doesn't natively understand, such as ext4, etc.
      
         o Providing a user interface
      
      Boot loaders still need to display any menus/interfaces, for example
      to allow the user to select from a list of kernels.
      
      Bump the boot protocol number because we added the 'handover_offset'
      field to indicate the location of the handover protocol entry point.
      
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Peter Jones <pjones@redhat.com>
      Cc: Ingo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarMatt Fleming <matt.fleming@intel.com>
      Acked-and-Tested-by: default avatarMatthew Garrett <mjg@redhat.com>
      Link: http://lkml.kernel.org/r/1342689828-16815-1-git-send-email-matt@console-pimps.orgSigned-off-by: default avatarH. Peter Anvin <hpa@zytor.com>
      9ca8f72a
  22. 21 Jun, 2012 1 commit
  23. 07 Jun, 2012 1 commit
  24. 26 Mar, 2012 3 commits
  25. 12 Dec, 2011 1 commit
    • Matt Fleming's avatar
      x86, efi: EFI boot stub support · 291f3632
      Matt Fleming authored
      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: Henrik Rydberg's avatarHenrik Rydberg <rydberg@euromail.se>
      Signed-off-by: default avatarMatt Fleming <matt.fleming@intel.com>
      Link: http://lkml.kernel.org/r/1321383097.2657.9.camel@mfleming-mobl1.ger.corp.intel.comSigned-off-by: default avatarH. Peter Anvin <hpa@linux.intel.com>
      291f3632
  26. 27 Sep, 2011 1 commit
    • Paul Bolle's avatar
      doc: fix broken references · 395cf969
      Paul Bolle authored
      There are numerous broken references to Documentation files (in other
      Documentation files, in comments, etc.). These broken references are
      caused by typo's in the references, and by renames or removals of the
      Documentation files. Some broken references are simply odd.
      
      Fix these broken references, sometimes by dropping the irrelevant text
      they were part of.
      Signed-off-by: default avatarPaul Bolle <pebolle@tiscali.nl>
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      395cf969
  27. 12 Dec, 2009 1 commit
  28. 20 May, 2009 1 commit
  29. 12 May, 2009 2 commits
    • H. Peter Anvin's avatar
      x86: add extension fields for bootloader type and version · 5031296c
      H. Peter Anvin authored
      A long ago, in days of yore, it all began with a god named Thor.
      There were vikings and boats and some plans for a Linux kernel
      header.  Unfortunately, a single 8-bit field was used for bootloader
      type and version.  This has generally worked without *too* much pain,
      but we're getting close to flat running out of ID fields.
      
      Add extension fields for both type and version.  The type will be
      extended if it the old field is 0xE; the version is a simple MSB
      extension.
      
      Keep /proc/sys/kernel/bootloader_type containing
      (type << 4) + (ver & 0xf) for backwards compatiblity, but also add
      /proc/sys/kernel/bootloader_version which contains the full version
      number.
      
      [ Impact: new feature to support more bootloaders ]
      Signed-off-by: default avatarH. Peter Anvin <hpa@zytor.com>
      5031296c
    • H. Peter Anvin's avatar
      x86, boot: make kernel_alignment adjustable; new bzImage fields · 37ba7ab5
      H. Peter Anvin authored
      Make the kernel_alignment field adjustable; this allows us to set it
      to a large value (intended to be 16 MB to avoid ZONE_DMA contention,
      memory holes and other weirdness) while a smart bootloader can still
      force a loading at a lesser alignment if absolutely necessary.
      
      Also export pref_address (preferred loading address, corresponding to
      the link-time address) and init_size, the total amount of linear
      memory the kernel will require during initialization.
      
      [ Impact: allows better kernel placement, gives bootloader more info ]
      Signed-off-by: default avatarH. Peter Anvin <hpa@zytor.com>
      37ba7ab5
  30. 11 May, 2009 1 commit
  31. 09 Apr, 2009 1 commit
    • H. Peter Anvin's avatar
      x86, setup: "glove box" BIOS calls -- infrastructure · 7a734e7d
      H. Peter Anvin authored
      Impact: new interfaces (not yet used)
      
      For all the platforms out there, there is an infinite number of buggy
      BIOSes.  This adds infrastructure to treat BIOS interrupts more like
      toxic waste and "glove box" them -- we switch out the register set,
      perform the BIOS interrupt, and then restore the previous state.
      
      LKML-Reference: <49DE7F79.4030106@zytor.com>
      Signed-off-by: default avatarH. Peter Anvin <hpa@linux.intel.com>
      Cc: Pavel Machek <pavel@ucw.cz>
      Cc: Rafael J. Wysocki <rjw@sisk.pl>
      7a734e7d
  32. 11 Mar, 2009 1 commit
    • H. Peter Anvin's avatar
      x86: remove zImage support · 5e47c478
      H. Peter Anvin authored
      Impact: obsolete feature removal
      
      The zImage kernel format has been functionally unused for a very long
      time.  It is just barely possible to build a modern kernel that still
      fits within the zImage size limit, but it is highly unlikely that
      anyone ever uses it.  Furthermore, although it is still supported by
      most bootloaders, it has been at best poorly tested (or not tested at
      all); some bootloaders are even known to not support zImage at all and
      not having even noticed.
      
      Also remove some really obsolete constants that no longer have any
      meaning.
      
      LKML-Reference: <49B703D4.1000008@zytor.com>
      Signed-off-by: default avatarH. Peter Anvin <hpa@zytor.com>
      5e47c478
  33. 13 Feb, 2009 1 commit
  34. 16 Sep, 2008 1 commit
  35. 26 Apr, 2008 1 commit