An error occurred fetching the project authors.
  1. 08 Aug, 2015 1 commit
  2. 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
  3. 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
  4. 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
  5. 13 Mar, 2014 1 commit
  6. 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
  7. 29 Dec, 2013 1 commit
  8. 30 Jan, 2013 1 commit
  9. 27 Jan, 2013 1 commit
  10. 20 Nov, 2012 1 commit
  11. 20 Aug, 2012 1 commit
  12. 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
  13. 21 Jun, 2012 1 commit
  14. 07 Jun, 2012 1 commit
  15. 26 Mar, 2012 3 commits
  16. 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: default 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
  17. 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
  18. 12 Dec, 2009 1 commit
  19. 20 May, 2009 1 commit
  20. 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
  21. 11 May, 2009 1 commit
  22. 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
  23. 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
  24. 13 Feb, 2009 1 commit
  25. 16 Sep, 2008 1 commit
  26. 26 Apr, 2008 1 commit
  27. 17 Apr, 2008 3 commits
  28. 30 Jan, 2008 1 commit
    • H. Peter Anvin's avatar
      i386: handle an initrd in highmem (version 2) · cf8fa920
      H. Peter Anvin authored
      The boot protocol has until now required that the initrd be located in
      lowmem, which makes the lowmem/highmem boundary visible to the boot
      loader.  This was exported to the bootloader via a compile-time
      field.  Unfortunately, the vmalloc= command-line option breaks this
      part of the protocol; instead of adding yet another hack that affects
      the bootloader, have the kernel relocate the initrd down below the
      lowmem boundary inside the kernel itself.
      
      Note that this does not rely on HIGHMEM being enabled in the kernel.
      Signed-off-by: default avatarH. Peter Anvin <hpa@zytor.com>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      cf8fa920
  29. 29 Nov, 2007 1 commit
    • Jens Rottmann's avatar
      x86 setup: don't recalculate ss:esp unless really necessary · 16252da6
      Jens Rottmann authored
      In order to work around old LILO versions providing an invalid ss
      register, the current setup code always sets up a new stack,
      immediately following .bss and the heap. But this breaks LOADLIN.
      
      This rewrite of the workaround checks for an invalid stack (ss!=ds)
      first, and leaves ss:sp alone otherwise (apart from aligning esp).
      
      [hpa note: LOADLIN has a number of arbitrary hard-coded limits that
      are being pushed up against.  Without some major revision of LOADLIN
      itself it will not be sustainable keeping it alive.  This gives it
      another brief lease on life, however.  This patch also helps the
      cmdline truncation problem with old versions of SYSLINUX.]
      
      Signed-off-by: Jens Rottmann <JRottmann at LiPPERT-AT. de>
      Signed-off-by: default avatarH. Peter Anvin <hpa@zytor.com>
      16252da6
  30. 26 Oct, 2007 1 commit
  31. 22 Oct, 2007 1 commit
    • Rusty Russell's avatar
      i386: paravirt boot sequence · a24e7851
      Rusty Russell authored
      This patch uses the updated boot protocol to do paravirtualized boot.
      If the boot version is >= 2.07, then it will do two things:
      
       1. Check the bootparams loadflags to see if we should reload the
          segment registers and clear interrupts.  This is appropriate
          for normal native boot and some paravirtualized environments, but
          inapproprate for others.
      
       2. Check the hardware architecture, and dispatch to the appropriate
          kernel entrypoint.  If the bootloader doesn't set this, then we
          simply do the normal boot sequence.
      Signed-off-by: default avatarJeremy Fitzhardinge <jeremy@xensource.com>
      Signed-off-by: default avatarRusty Russell <rusty@rustcorp.com.au>
      Acked-by: default avatarH. Peter Anvin <hpa@zytor.com>
      Cc: "Eric W. Biederman" <ebiederm@xmission.com>
      Cc: Vivek Goyal <vgoyal@in.ibm.com>
      Cc: James Bottomley <James.Bottomley@HansenPartnership.com>
      Cc: Zachary Amsden <zach@vmware.com>
      Cc: Andi Kleen <ak@suse.de>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ingo Molnar <mingo@elte.hu>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      a24e7851
  32. 11 Oct, 2007 1 commit
  33. 20 Sep, 2007 1 commit
  34. 31 Jul, 2007 1 commit