1. 04 10月, 2014 3 次提交
    • J
      efi-bgrt: Add error handling; inform the user when ignoring the BGRT · 1282278e
      Josh Triplett 提交于
      Gracefully handle failures to allocate memory for the image, which might
      be arbitrarily large.
      
      efi_bgrt_init can fail in various ways as well, usually because the
      BIOS-provided BGRT structure does not match expectations.  Add
      appropriate error messages rather than failing silently.
      Reported-by: NSrihari Vijayaraghavan <linux.bug.reporting@gmail.com>
      Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=81321Signed-off-by: NJosh Triplett <josh@joshtriplett.org>
      Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
      1282278e
    • M
      efi: Add efi= parameter parsing to the EFI boot stub · 5a17dae4
      Matt Fleming 提交于
      We need a way to customize the behaviour of the EFI boot stub, in
      particular, we need a way to disable the "chunking" workaround, used
      when reading files from the EFI System Partition.
      
      One of my machines doesn't cope well when reading files in 1MB chunks to
      a buffer above the 4GB mark - it appears that the "chunking" bug
      workaround triggers another firmware bug. This was only discovered with
      commit 4bf7111f ("x86/efi: Support initrd loaded above 4G"), and
      that commit is perfectly valid. The symptom I observed was a corrupt
      initrd rather than any kind of crash.
      
      efi= is now used to specify EFI parameters in two very different
      execution environments, the EFI boot stub and during kernel boot.
      
      There is also a slight performance optimization by enabling efi=nochunk,
      but that's offset by the fact that you're more likely to run into
      firmware issues, at least on x86. This is the rationale behind leaving
      the workaround enabled by default.
      
      Also provide some documentation for EFI_READ_CHUNK_SIZE and why we're
      using the current value of 1MB.
      Tested-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
      Cc: Roy Franz <roy.franz@linaro.org>
      Cc: Maarten Lankhorst <m.b.lankhorst@gmail.com>
      Cc: Leif Lindholm <leif.lindholm@linaro.org>
      Cc: Borislav Petkov <bp@suse.de>
      Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
      5a17dae4
    • A
      efi: Implement mandatory locking for UEFI Runtime Services · 161485e8
      Ard Biesheuvel 提交于
      According to section 7.1 of the UEFI spec, Runtime Services are not fully
      reentrant, and there are particular combinations of calls that need to be
      serialized. Use a spinlock to serialize all Runtime Services with respect
      to all others, even if this is more than strictly needed.
      
      We've managed to get away without requiring a runtime services lock
      until now because most of the interactions with EFI involve EFI
      variables, and those operations are already serialised with
      __efivars->lock.
      
      Some of the assumptions underlying the decision whether locks are
      needed or not (e.g., SetVariable() against ResetSystem()) may not
      apply universally to all [new] architectures that implement UEFI.
      Rather than try to reason our way out of this, let's just implement at
      least what the spec requires in terms of locking.
      Signed-off-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
      161485e8
  2. 17 8月, 2014 1 次提交
  3. 16 8月, 2014 36 次提交