1. 24 Apr, 2013 2 commits
    • Josh Boyer's avatar
      efi: Check EFI revision in setup_efi_vars · f697036b
      Josh Boyer authored
      We need to check the runtime sys_table for the EFI version the firmware
      specifies instead of just checking for a NULL QueryVariableInfo.  Older
      implementations of EFI don't have QueryVariableInfo but the runtime is
      a smaller structure, so the pointer to it may be pointing off into garbage.
      
      This is apparently the case with several Apple firmwares that support EFI
      1.10, and the current check causes them to no longer boot.  Fix based on
      a suggestion from Matthew Garrett.
      Signed-off-by: default avatarJosh Boyer <jwboyer@redhat.com>
      Signed-off-by: default avatarMatt Fleming <matt.fleming@intel.com>
      f697036b
    • Borislav Petkov's avatar
      x86, efi: Fix a build warning · 51f8fbba
      Borislav Petkov authored
      Fix this:
      
      arch/x86/boot/compressed/eboot.c: In function ‘setup_efi_vars’:
      arch/x86/boot/compressed/eboot.c:269:2: warning: passing argument 1 of ‘efi_call_phys’ makes pointer from integer without a cast [enabled by default]
      In file included from arch/x86/boot/compressed/eboot.c:12:0:
      /w/kernel/linux/arch/x86/include/asm/efi.h:8:33: note: expected ‘void *’ but argument is of type ‘long unsigned int’
      
      after cc5a080c ("efi: Pass boot services variable info to runtime
      code").
      Reported-by: default avatarPaul Bolle <pebolle@tiscali.nl>
      Cc: Matthew Garrett <matthew.garrett@nebula.com>
      Signed-off-by: default avatarBorislav Petkov <bp@suse.de>
      Signed-off-by: default avatarMatt Fleming <matt.fleming@intel.com>
      51f8fbba
  2. 15 Apr, 2013 1 commit
    • Matthew Garrett's avatar
      efi: Pass boot services variable info to runtime code · cc5a080c
      Matthew Garrett authored
      EFI variables can be flagged as being accessible only within boot services.
      This makes it awkward for us to figure out how much space they use at
      runtime. In theory we could figure this out by simply comparing the results
      from QueryVariableInfo() to the space used by all of our variables, but
      that fails if the platform doesn't garbage collect on every boot. Thankfully,
      calling QueryVariableInfo() while still inside boot services gives a more
      reliable answer. This patch passes that information from the EFI boot stub
      up to the efi platform code.
      Signed-off-by: default avatarMatthew Garrett <matthew.garrett@nebula.com>
      Signed-off-by: default avatarMatt Fleming <matt.fleming@intel.com>
      cc5a080c
  3. 31 Jan, 2013 1 commit
    • Lee, Chun-Yi's avatar
      x86, efi: Allow slash in file path of initrd · deb94101
      Lee, Chun-Yi authored
      When initrd file didn't put at the same place with stub kernel, we
      need give the file path of initrd, but need use backslash to separate
      directory and file. It's not friendly to unix/linux user, and not so
      intuitive for bootloader forward paramters to efi stub kernel by
      chainloading.
      
      This patch add support to handle_ramdisks for allow slash in file path
      of initrd, it convert slash to backlash when parsing path.
      
      In additional, this patch also separates print code of efi_char16_t from
      efi_printk, and print out the path/filename of initrd when failed to open
      initrd file. It's good for debug and discover typo.
      
      Cc: Matthew Garrett <mjg59@srcf.ucam.org>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Signed-off-by: default avatarLee, Chun-Yi <jlee@suse.com>
      Signed-off-by: default avatarMatt Fleming <matt.fleming@intel.com>
      deb94101
  4. 29 Jan, 2013 1 commit
  5. 28 Jan, 2013 2 commits
  6. 25 Jan, 2013 1 commit
  7. 20 Dec, 2012 1 commit
  8. 05 Dec, 2012 1 commit
  9. 20 Nov, 2012 1 commit
  10. 17 Sep, 2012 3 commits
  11. 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
  12. 01 Jun, 2012 2 commits
  13. 26 Mar, 2012 1 commit
  14. 16 Mar, 2012 1 commit
  15. 16 Dec, 2011 1 commit
  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