1. 05 3月, 2014 8 次提交
  2. 14 2月, 2014 2 次提交
    • M
      x86/efi: Check status field to validate BGRT header · 09503379
      Matt Fleming 提交于
      Madper reported seeing the following crash,
      
        BUG: unable to handle kernel paging request at ffffffffff340003
        IP: [<ffffffff81d85ba4>] efi_bgrt_init+0x9d/0x133
        Call Trace:
         [<ffffffff81d8525d>] efi_late_init+0x9/0xb
         [<ffffffff81d68f59>] start_kernel+0x436/0x450
         [<ffffffff81d6892c>] ? repair_env_string+0x5c/0x5c
         [<ffffffff81d68120>] ? early_idt_handlers+0x120/0x120
         [<ffffffff81d685de>] x86_64_start_reservations+0x2a/0x2c
         [<ffffffff81d6871e>] x86_64_start_kernel+0x13e/0x14d
      
      This is caused because the layout of the ACPI BGRT header on this system
      doesn't match the definition from the ACPI spec, and so we get a bogus
      physical address when dereferencing ->image_address in efi_bgrt_init().
      
      Luckily the status field in the BGRT header clearly marks it as invalid,
      so we can check that field and skip BGRT initialisation.
      Reported-by: NMadper Xie <cxie@redhat.com>
      Suggested-by: NToshi Kani <toshi.kani@hp.com>
      Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
      Cc: Matthew Garrett <mjg59@srcf.ucam.org>
      Cc: Josh Triplett <josh@joshtriplett.org>
      Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
      09503379
    • B
      x86/efi: Fix 32-bit fallout · c55d016f
      Borislav Petkov 提交于
      We do not enable the new efi memmap on 32-bit and thus we need to run
      runtime_code_page_mkexec() unconditionally there. Fix that.
      Reported-and-tested-by: NLejun Zhu <lejun.zhu@intel.com>
      Signed-off-by: NBorislav Petkov <bp@suse.de>
      Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
      c55d016f
  3. 06 2月, 2014 1 次提交
    • M
      x86/efi: Allow mapping BGRT on x86-32 · 081cd62a
      Matt Fleming 提交于
      CONFIG_X86_32 doesn't map the boot services regions into the EFI memory
      map (see commit 70087011 ("x86, efi: Don't map Boot Services on
      i386")), and so efi_lookup_mapped_addr() will fail to return a valid
      address. Executing the ioremap() path in efi_bgrt_init() causes the
      following warning on x86-32 because we're trying to ioremap() RAM,
      
       WARNING: CPU: 0 PID: 0 at arch/x86/mm/ioremap.c:102 __ioremap_caller+0x2ad/0x2c0()
       Modules linked in:
       CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.13.0-0.rc5.git0.1.2.fc21.i686 #1
       Hardware name: DellInc. Venue 8 Pro 5830/09RP78, BIOS A02 10/17/2013
        00000000 00000000 c0c0df08 c09a5196 00000000 c0c0df38 c0448c1e c0b41310
        00000000 00000000 c0b37bc1 00000066 c043bbfd c043bbfd 00e7dfe0 00073eff
        00073eff c0c0df48 c0448ce2 00000009 00000000 c0c0df9c c043bbfd 00078d88
       Call Trace:
        [<c09a5196>] dump_stack+0x41/0x52
        [<c0448c1e>] warn_slowpath_common+0x7e/0xa0
        [<c043bbfd>] ? __ioremap_caller+0x2ad/0x2c0
        [<c043bbfd>] ? __ioremap_caller+0x2ad/0x2c0
        [<c0448ce2>] warn_slowpath_null+0x22/0x30
        [<c043bbfd>] __ioremap_caller+0x2ad/0x2c0
        [<c0718f92>] ? acpi_tb_verify_table+0x1c/0x43
        [<c0719c78>] ? acpi_get_table_with_size+0x63/0xb5
        [<c087cd5e>] ? efi_lookup_mapped_addr+0xe/0xf0
        [<c043bc2b>] ioremap_nocache+0x1b/0x20
        [<c0cb01c8>] ? efi_bgrt_init+0x83/0x10c
        [<c0cb01c8>] efi_bgrt_init+0x83/0x10c
        [<c0cafd82>] efi_late_init+0x8/0xa
        [<c0c9bab2>] start_kernel+0x3ae/0x3c3
        [<c0c9b53b>] ? repair_env_string+0x51/0x51
        [<c0c9b378>] i386_start_kernel+0x12e/0x131
      
      Switch to using early_memremap(), which won't trigger this warning, and
      has the added benefit of more accurately conveying what we're trying to
      do - map a chunk of memory.
      
      This patch addresses the following bug report,
      
        https://bugzilla.kernel.org/show_bug.cgi?id=67911Reported-by: NAdam Williamson <awilliam@redhat.com>
      Cc: Josh Triplett <josh@joshtriplett.org>
      Cc: Matthew Garrett <mjg59@srcf.ucam.org>
      Cc: Rafael J. Wysocki <rjw@rjwysocki.net>
      Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
      081cd62a
  4. 29 12月, 2013 2 次提交
    • M
      x86/efi: Delete superfluous global variables · 518548ab
      Matt Fleming 提交于
      There's no need to save the runtime map details in global variables, the
      values are only required to pass to efi_runtime_map_setup().
      
      And because 'nr_efi_runtime_map' isn't needed, get_nr_runtime_map() can
      be deleted along with 'efi_data_len'.
      
      Cc: Dave Young <dyoung@redhat.com>
      Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
      518548ab
    • D
      x86/efi: Pass necessary EFI data for kexec via setup_data · 1fec0533
      Dave Young 提交于
      Add a new setup_data type SETUP_EFI for kexec use.  Passing the saved
      fw_vendor, runtime, config tables and EFI runtime mappings.
      
      When entering virtual mode, directly mapping the EFI runtime regions
      which we passed in previously. And skip the step to call
      SetVirtualAddressMap().
      
      Specially for HP z420 workstation we need save the smbios physical
      address.  The kernel boot sequence proceeds in the following order.
      Step 2 requires efi.smbios to be the physical address.  However, I found
      that on HP z420 EFI system table has a virtual address of SMBIOS in step
      1.  Hence, we need set it back to the physical address with the smbios
      in efi_setup_data.  (When it is still the physical address, it simply
      sets the same value.)
      
      1. efi_init() - Set efi.smbios from EFI system table
      2. dmi_scan_machine() - Temporary map efi.smbios to access SMBIOS table
      3. efi_enter_virtual_mode() - Map EFI ranges
      
      Tested on ovmf+qemu, lenovo thinkpad, a dell laptop and an
      HP z420 workstation.
      Signed-off-by: NDave Young <dyoung@redhat.com>
      Tested-by: NToshi Kani <toshi.kani@hp.com>
      Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
      1fec0533
  5. 21 12月, 2013 6 次提交
  6. 11 12月, 2013 1 次提交
  7. 29 11月, 2013 1 次提交
  8. 02 11月, 2013 3 次提交
  9. 29 10月, 2013 1 次提交
  10. 05 10月, 2013 1 次提交
  11. 18 9月, 2013 1 次提交
    • J
      x86, efi: Don't map Boot Services on i386 · 70087011
      Josh Boyer 提交于
      Add patch to fix 32bit EFI service mapping (rhbz 726701)
      
      Multiple people are reporting hitting the following WARNING on i386,
      
        WARNING: at arch/x86/mm/ioremap.c:102 __ioremap_caller+0x3d3/0x440()
        Modules linked in:
        Pid: 0, comm: swapper Not tainted 3.9.0-rc7+ #95
        Call Trace:
         [<c102b6af>] warn_slowpath_common+0x5f/0x80
         [<c1023fb3>] ? __ioremap_caller+0x3d3/0x440
         [<c1023fb3>] ? __ioremap_caller+0x3d3/0x440
         [<c102b6ed>] warn_slowpath_null+0x1d/0x20
         [<c1023fb3>] __ioremap_caller+0x3d3/0x440
         [<c106007b>] ? get_usage_chars+0xfb/0x110
         [<c102d937>] ? vprintk_emit+0x147/0x480
         [<c1418593>] ? efi_enter_virtual_mode+0x1e4/0x3de
         [<c102406a>] ioremap_cache+0x1a/0x20
         [<c1418593>] ? efi_enter_virtual_mode+0x1e4/0x3de
         [<c1418593>] efi_enter_virtual_mode+0x1e4/0x3de
         [<c1407984>] start_kernel+0x286/0x2f4
         [<c1407535>] ? repair_env_string+0x51/0x51
         [<c1407362>] i386_start_kernel+0x12c/0x12f
      
      Due to the workaround described in commit 916f676f ("x86, efi: Retain
      boot service code until after switching to virtual mode") EFI Boot
      Service regions are mapped for a period during boot. Unfortunately, with
      the limited size of the i386 direct kernel map it's possible that some
      of the Boot Service regions will not be directly accessible, which
      causes them to be ioremap()'d, triggering the above warning as the
      regions are marked as E820_RAM in the e820 memmap.
      
      There are currently only two situations where we need to map EFI Boot
      Service regions,
      
        1. To workaround the firmware bug described in 916f676f
        2. To access the ACPI BGRT image
      
      but since we haven't seen an i386 implementation that requires either,
      this simple fix should suffice for now.
      
      [ Added to changelog - Matt ]
      Reported-by: NBryan O'Donoghue <bryan.odonoghue.lkml@nexus-software.ie>
      Acked-by: NTom Zanussi <tom.zanussi@intel.com>
      Acked-by: NDarren Hart <dvhart@linux.intel.com>
      Cc: Josh Triplett <josh@joshtriplett.org>
      Cc: Matthew Garrett <mjg59@srcf.ucam.org>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NJosh Boyer <jwboyer@redhat.com>
      Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
      70087011
  12. 05 9月, 2013 2 次提交
  13. 11 7月, 2013 1 次提交
  14. 21 6月, 2013 1 次提交
  15. 11 6月, 2013 1 次提交
    • M
      Modify UEFI anti-bricking code · f8b84043
      Matthew Garrett 提交于
      This patch reworks the UEFI anti-bricking code, including an effective
      reversion of cc5a080c and 31ff2f20. It turns out that calling
      QueryVariableInfo() from boot services results in some firmware
      implementations jumping to physical addresses even after entering virtual
      mode, so until we have 1:1 mappings for UEFI runtime space this isn't
      going to work so well.
      
      Reverting these gets us back to the situation where we'd refuse to create
      variables on some systems because they classify deleted variables as "used"
      until the firmware triggers a garbage collection run, which they won't do
      until they reach a lower threshold. This results in it being impossible to
      install a bootloader, which is unhelpful.
      
      Feedback from Samsung indicates that the firmware doesn't need more than
      5KB of storage space for its own purposes, so that seems like a reasonable
      threshold. However, there's still no guarantee that a platform will attempt
      garbage collection merely because it drops below this threshold. It seems
      that this is often only triggered if an attempt to write generates a
      genuine EFI_OUT_OF_RESOURCES error. We can force that by attempting to
      create a variable larger than the remaining space. This should fail, but if
      it somehow succeeds we can then immediately delete it.
      
      I've tested this on the UEFI machines I have available, but I don't have
      a Samsung and so can't verify that it avoids the bricking problem.
      Signed-off-by: NMatthew Garrett <matthew.garrett@nebula.com>
      Signed-off-by: Lee, Chun-Y <jlee@suse.com> [ dummy variable cleanup ]
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
      f8b84043
  16. 06 6月, 2013 1 次提交
  17. 29 5月, 2013 1 次提交
    • D
      x86: Increase precision of x86_platform.get/set_wallclock() · 3565184e
      David Vrabel 提交于
      All the virtualized platforms (KVM, lguest and Xen) have persistent
      wallclocks that have more than one second of precision.
      
      read_persistent_wallclock() and update_persistent_wallclock() allow
      for nanosecond precision but their implementation on x86 with
      x86_platform.get/set_wallclock() only allows for one second precision.
      This means guests may see a wallclock time that is off by up to 1
      second.
      
      Make set_wallclock() and get_wallclock() take a struct timespec
      parameter (which allows for nanosecond precision) so KVM and Xen
      guests may start with a more accurate wallclock time and a Xen dom0
      can maintain a more accurate wallclock for guests.
      Signed-off-by: NDavid Vrabel <david.vrabel@citrix.com>
      Signed-off-by: NJohn Stultz <john.stultz@linaro.org>
      3565184e
  18. 14 5月, 2013 1 次提交
    • L
      x86, efi: initial the local variable of DataSize to zero · eccaf52f
      Lee, Chun-Yi 提交于
      That will be better initial the value of DataSize to zero for the input of
      GetVariable(), otherwise we will feed a random value. The debug log of input
      DataSize like this:
      
      ...
      [  195.915612] EFI Variables Facility v0.08 2004-May-17
      [  195.915819] efi: size: 18446744071581821342
      [  195.915969] efi:  size': 18446744071581821342
      [  195.916324] efi: size: 18446612150714306560
      [  195.916632] efi:  size': 18446612150714306560
      [  195.917159] efi: size: 18446612150714306560
      [  195.917453] efi:  size': 18446612150714306560
      ...
      
      The size' is value that was returned by BIOS.
      
      After applied this patch:
      [   82.442042] EFI Variables Facility v0.08 2004-May-17
      [   82.442202] efi: size: 0
      [   82.442360] efi:  size': 1039
      [   82.443828] efi: size: 0
      [   82.444127] efi:  size': 2616
      [   82.447057] efi: size: 0
      [   82.447356] efi:  size': 5832
      ...
      
      Found on Acer Aspire V3 BIOS, it will not return the size of data if we input a
      non-zero DataSize.
      
      Cc: Matthew Garrett <mjg59@srcf.ucam.org>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Signed-off-by: NLee, Chun-Yi <jlee@suse.com>
      Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
      eccaf52f
  19. 30 4月, 2013 1 次提交
  20. 17 4月, 2013 2 次提交
  21. 16 4月, 2013 2 次提交
    • M
      efi: Distinguish between "remaining space" and actually used space · 31ff2f20
      Matthew Garrett 提交于
      EFI implementations distinguish between space that is actively used by a
      variable and space that merely hasn't been garbage collected yet. Space
      that hasn't yet been garbage collected isn't available for use and so isn't
      counted in the remaining_space field returned by QueryVariableInfo().
      
      Combined with commit 68d92986 this can cause problems. Some implementations
      don't garbage collect until the remaining space is smaller than the maximum
      variable size, and as a result check_var_size() will always fail once more
      than 50% of the variable store has been used even if most of that space is
      marked as available for garbage collection. The user is unable to create
      new variables, and deleting variables doesn't increase the remaining space.
      
      The problem that 68d92986 was attempting to avoid was one where certain
      platforms fail if the actively used space is greater than 50% of the
      available storage space. We should be able to calculate that by simply
      summing the size of each available variable and subtracting that from
      the total storage space. With luck this will fix the problem described in
      https://bugzilla.kernel.org/show_bug.cgi?id=55471 without permitting
      damage to occur to the machines 68d92986 was attempting to fix.
      Signed-off-by: NMatthew Garrett <matthew.garrett@nebula.com>
      Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
      31ff2f20
    • M
      efi: Pass boot services variable info to runtime code · cc5a080c
      Matthew Garrett 提交于
      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: NMatthew Garrett <matthew.garrett@nebula.com>
      Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
      cc5a080c