1. 29 11月, 2015 1 次提交
    • M
      x86/efi: Hoist page table switching code into efi_call_virt() · c9f2a9a6
      Matt Fleming 提交于
      This change is a prerequisite for pending patches that switch to
      a dedicated EFI page table, instead of using 'trampoline_pgd'
      which shares PGD entries with 'swapper_pg_dir'. The pending
      patches make it impossible to dereference the runtime service
      function pointer without first switching %cr3.
      
      It's true that we now have duplicated switching code in
      efi_call_virt() and efi_call_phys_{prolog,epilog}() but we are
      sacrificing code duplication for a little more clarity and the
      ease of writing the page table switching code in C instead of
      asm.
      Signed-off-by: NMatt Fleming <matt@codeblueprint.co.uk>
      Reviewed-by: NBorislav Petkov <bp@suse.de>
      Acked-by: NBorislav Petkov <bp@suse.de>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Dave Jones <davej@codemonkey.org.uk>
      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: Sai Praneeth Prakhya <sai.praneeth.prakhya@intel.com>
      Cc: Stephen Smalley <sds@tycho.nsa.gov>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Toshi Kani <toshi.kani@hp.com>
      Cc: linux-efi@vger.kernel.org
      Link: http://lkml.kernel.org/r/1448658575-17029-5-git-send-email-matt@codeblueprint.co.ukSigned-off-by: NIngo Molnar <mingo@kernel.org>
      c9f2a9a6
  2. 12 10月, 2015 1 次提交
  3. 02 10月, 2015 1 次提交
  4. 30 9月, 2015 1 次提交
  5. 23 9月, 2015 1 次提交
    • A
      x86, efi, kasan: #undef memset/memcpy/memmove per arch · 769a8089
      Andrey Ryabinin 提交于
      In not-instrumented code KASAN replaces instrumented memset/memcpy/memmove
      with not-instrumented analogues __memset/__memcpy/__memove.
      
      However, on x86 the EFI stub is not linked with the kernel.  It uses
      not-instrumented mem*() functions from arch/x86/boot/compressed/string.c
      
      So we don't replace them with __mem*() variants in EFI stub.
      
      On ARM64 the EFI stub is linked with the kernel, so we should replace
      mem*() functions with __mem*(), because the EFI stub runs before KASAN
      sets up early shadow.
      
      So let's move these #undef mem* into arch's asm/efi.h which is also
      included by the EFI stub.
      
      Also, this will fix the warning in 32-bit build reported by kbuild test
      robot:
      
      	efi-stub-helper.c:599:2: warning: implicit declaration of function 'memcpy'
      
      [akpm@linux-foundation.org: use 80 cols in comment]
      Signed-off-by: NAndrey Ryabinin <ryabinin.a.a@gmail.com>
      Reported-by: NFengguang Wu <fengguang.wu@gmail.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Matt Fleming <matt.fleming@intel.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      769a8089
  6. 19 5月, 2015 1 次提交
    • I
      x86/fpu: Rename i387.h to fpu/api.h · df6b35f4
      Ingo Molnar 提交于
      We already have fpu/types.h, move i387.h to fpu/api.h.
      
      The file name has become a misnomer anyway: it offers generic FPU APIs,
      but is not limited to i387 functionality.
      Reviewed-by: NBorislav Petkov <bp@alien8.de>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Dave Hansen <dave.hansen@linux.intel.com>
      Cc: Fenghua Yu <fenghua.yu@intel.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Signed-off-by: NIngo Molnar <mingo@kernel.org>
      df6b35f4
  7. 01 4月, 2015 1 次提交
    • I
      efi: Clean up the efi_call_phys_[prolog|epilog]() save/restore interaction · 744937b0
      Ingo Molnar 提交于
      Currently x86-64 efi_call_phys_prolog() saves into a global variable (save_pgd),
      and efi_call_phys_epilog() restores the kernel pagetables from that global
      variable.
      
      Change this to a cleaner save/restore pattern where the saving function returns
      the saved object and the restore function restores that.
      
      Apply the same concept to the 32-bit code as well.
      
      Plus this approach, as an added bonus, allows us to express the
      !efi_enabled(EFI_OLD_MEMMAP) situation in a clean fashion as well,
      via a 'NULL' return value.
      
      Cc: Tapasweni Pathak <tapaswenipathak@gmail.com>
      Signed-off-by: NIngo Molnar <mingo@kernel.org>
      Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
      744937b0
  8. 12 11月, 2014 1 次提交
    • A
      efi/x86: Move x86 back to libstub · 243b6754
      Ard Biesheuvel 提交于
      This reverts commit 84be8805, which itself reverted my original
      attempt to move x86 from #include'ing .c files from across the tree
      to using the EFI stub built as a static library.
      
      The issue that affected the original approach was that splitting
      the implementation into several .o files resulted in the variable
      'efi_early' becoming a global with external linkage, which under
      -fPIC implies that references to it must go through the GOT. However,
      dealing with this additional GOT entry turned out to be troublesome
      on some EFI implementations. (GCC's visibility=hidden attribute is
      supposed to lift this requirement, but it turned out not to work on
      the 32-bit build.)
      
      Instead, use a pure getter function to get a reference to efi_early.
      This approach results in no additional GOT entries being generated,
      so there is no need for any changes in the early GOT handling.
      Tested-by: NMaarten Lankhorst <maarten.lankhorst@canonical.com>
      Signed-off-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
      243b6754
  9. 04 10月, 2014 5 次提交
    • M
      efi: Delete the in_nmi() conditional runtime locking · 60b4dc77
      Matt Fleming 提交于
      commit 5dc3826d9f08 ("efi: Implement mandatory locking for UEFI Runtime
      Services") implemented some conditional locking when accessing variable
      runtime services that Ingo described as "pretty disgusting".
      
      The intention with the !efi_in_nmi() checks was to avoid live-locks when
      trying to write pstore crash data into an EFI variable. Such lockless
      accesses are allowed according to the UEFI specification when we're in a
      "non-recoverable" state, but whether or not things are implemented
      correctly in actual firmware implementations remains an unanswered
      question, and so it would seem sensible to avoid doing any kind of
      unsynchronized variable accesses.
      
      Furthermore, the efi_in_nmi() tests are inadequate because they don't
      account for the case where we call EFI variable services from panic or
      oops callbacks and aren't executing in NMI context. In other words,
      live-locking is still possible.
      
      Let's just remove the conditional locking altogether. Now we've got the
      ->set_variable_nonblocking() EFI variable operation we can abort if the
      runtime lock is already held. Aborting is by far the safest option.
      
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
      Cc: Matthew Garrett <mjg59@srcf.ucam.org>
      Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
      60b4dc77
    • M
      x86/efi: Mark initialization code as such · 4e78eb05
      Mathias Krause 提交于
      The 32 bit and 64 bit implementations differ in their __init annotations
      for some functions referenced from the common EFI code. Namely, the 32
      bit variant is missing some of the __init annotations the 64 bit variant
      has.
      
      To solve the colliding annotations, mark the corresponding functions in
      efi_32.c as initialization code, too -- as it is such.
      
      Actually, quite a few more functions are only used during initialization
      and therefore can be marked __init. They are therefore annotated, too.
      Also add the __init annotation to the prototypes in the efi.h header so
      users of those functions will see it's meant as initialization code
      only.
      
      This patch also fixes the "prelog" typo. ("prologue" / "epilogue" might
      be more appropriate but this is C code after all, not an opera! :D)
      Signed-off-by: NMathias Krause <minipli@googlemail.com>
      Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
      4e78eb05
    • M
      x86/efi: Unexport add_efi_memmap variable · 60920685
      Mathias Krause 提交于
      This variable was accidentally exported, even though it's only used in
      this compilation unit and only during initialization.
      
      Remove the bogus export, make the variable static instead and mark it
      as __initdata.
      
      Fixes: 200001eb ("x86 boot: only pick up additional EFI memmap...")
      Cc: Paul Jackson <pj@sgi.com>
      Signed-off-by: NMathias Krause <minipli@googlemail.com>
      Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
      60920685
    • M
      x86/efi: Remove unused efi_call* macros · 24ffd84b
      Mathias Krause 提交于
      Complement commit 62fa6e69 ("x86/efi: Delete most of the efi_call*
      macros") and delete the stub macros for the !CONFIG_EFI case, too. In
      fact, there are no EFI calls in this case so we don't need a dummy for
      efi_call() even.
      Signed-off-by: NMathias Krause <minipli@googlemail.com>
      Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
      24ffd84b
    • 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
  10. 24 9月, 2014 1 次提交
    • M
      Revert "efi/x86: efistub: Move shared dependencies to <asm/efi.h>" · 84be8805
      Matt Fleming 提交于
      This reverts commit f23cf8bd ("efi/x86: efistub: Move shared
      dependencies to <asm/efi.h>") as well as the x86 parts of commit
      f4f75ad5 ("efi: efistub: Convert into static library").
      
      The road leading to these two reverts is long and winding.
      
      The above two commits were merged during the v3.17 merge window and
      turned the common EFI boot stub code into a static library. This
      necessitated making some symbols global in the x86 boot stub which
      introduced new entries into the early boot GOT.
      
      The problem was that we weren't fixing up the newly created GOT entries
      before invoking the EFI boot stub, which sometimes resulted in hangs or
      resets. This failure was reported by Maarten on his Macbook pro.
      
      The proposed fix was commit 9cb0e394 ("x86/efi: Fixup GOT in all
      boot code paths"). However, that caused issues for Linus when booting
      his Sony Vaio Pro 11. It was subsequently reverted in commit
      f3670394.
      
      So that leaves us back with Maarten's Macbook pro not booting.
      
      At this stage in the release cycle the least risky option is to revert
      the x86 EFI boot stub to the pre-merge window code structure where we
      explicitly #include efi-stub-helper.c instead of linking with the static
      library. The arm64 code remains unaffected.
      
      We can take another swing at the x86 parts for v3.18.
      
      Conflicts:
      	arch/x86/include/asm/efi.h
      Tested-by: NJosh Boyer <jwboyer@fedoraproject.org>
      Tested-by: NMaarten Lankhorst <maarten.lankhorst@canonical.com>
      Tested-by: Leif Lindholm <leif.lindholm@linaro.org> [arm64]
      Tested-by: NLinus Torvalds <torvalds@linux-foundation.org>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>,
      Cc: Ingo Molnar <mingo@kernel.org>
      Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
      84be8805
  11. 19 7月, 2014 1 次提交
    • M
      x86/reboot: Add EFI reboot quirk for ACPI Hardware Reduced flag · 44be28e9
      Matt Fleming 提交于
      It appears that the BayTrail-T class of hardware requires EFI in order
      to powerdown and reboot and no other reliable method exists.
      
      This quirk is generally applicable to all hardware that has the ACPI
      Hardware Reduced bit set, since usually ACPI would be the preferred
      method.
      
      Cc: Len Brown <len.brown@intel.com>
      Cc: Mark Salter <msalter@redhat.com>
      Cc: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>
      Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
      44be28e9
  12. 08 7月, 2014 1 次提交
  13. 19 6月, 2014 1 次提交
  14. 17 4月, 2014 4 次提交
  15. 05 3月, 2014 7 次提交
    • B
      x86/efi: Quirk out SGI UV · a5d90c92
      Borislav Petkov 提交于
      Alex reported hitting the following BUG after the EFI 1:1 virtual
      mapping work was merged,
      
       kernel BUG at arch/x86/mm/init_64.c:351!
       invalid opcode: 0000 [#1] SMP
       Call Trace:
        [<ffffffff818aa71d>] init_extra_mapping_uc+0x13/0x15
        [<ffffffff818a5e20>] uv_system_init+0x22b/0x124b
        [<ffffffff8108b886>] ? clockevents_register_device+0x138/0x13d
        [<ffffffff81028dbb>] ? setup_APIC_timer+0xc5/0xc7
        [<ffffffff8108b620>] ? clockevent_delta2ns+0xb/0xd
        [<ffffffff818a3a92>] ? setup_boot_APIC_clock+0x4a8/0x4b7
        [<ffffffff8153d955>] ? printk+0x72/0x74
        [<ffffffff818a1757>] native_smp_prepare_cpus+0x389/0x3d6
        [<ffffffff818957bc>] kernel_init_freeable+0xb7/0x1fb
        [<ffffffff81535530>] ? rest_init+0x74/0x74
        [<ffffffff81535539>] kernel_init+0x9/0xff
        [<ffffffff81541dfc>] ret_from_fork+0x7c/0xb0
        [<ffffffff81535530>] ? rest_init+0x74/0x74
      
      Getting this thing to work with the new mapping scheme would need more
      work, so automatically switch to the old memmap layout for SGI UV.
      Acked-by: NRuss Anderson <rja@sgi.com>
      Cc: Alex Thorlton <athorlton@sgi.com
      Signed-off-by: NBorislav Petkov <bp@suse.de>
      Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
      a5d90c92
    • M
      x86/efi: Wire up CONFIG_EFI_MIXED · 7d453eee
      Matt Fleming 提交于
      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: NMatt Fleming <matt.fleming@intel.com>
      7d453eee
    • M
      x86/efi: Add mixed runtime services support · 4f9dbcfc
      Matt Fleming 提交于
      Setup the runtime services based on whether we're booting in EFI native
      mode or not. For non-native mode we need to thunk from 64-bit into
      32-bit mode before invoking the EFI runtime services.
      
      Using the runtime services after SetVirtualAddressMap() is slightly more
      complicated because we need to ensure that all the addresses we pass to
      the firmware are below the 4GB boundary so that they can be addressed
      with 32-bit pointers, see efi_setup_page_tables().
      Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
      4f9dbcfc
    • M
      x86/efi: Firmware agnostic handover entry points · b8ff87a6
      Matt Fleming 提交于
      The EFI handover code only works if the "bitness" of the firmware and
      the kernel match, i.e. 64-bit firmware and 64-bit kernel - it is not
      possible to mix the two. This goes against the tradition that a 32-bit
      kernel can be loaded on a 64-bit BIOS platform without having to do
      anything special in the boot loader. Linux distributions, for one thing,
      regularly run only 32-bit kernels on their live media.
      
      Despite having only one 'handover_offset' field in the kernel header,
      EFI boot loaders use two separate entry points to enter the kernel based
      on the architecture the boot loader was compiled for,
      
          (1) 32-bit loader: handover_offset
          (2) 64-bit loader: handover_offset + 512
      
      Since we already have two entry points, we can leverage them to infer
      the bitness of the firmware we're running on, without requiring any boot
      loader modifications, by making (1) and (2) valid entry points for both
      CONFIG_X86_32 and CONFIG_X86_64 kernels.
      
      To be clear, a 32-bit boot loader will always use (1) and a 64-bit boot
      loader will always use (2). It's just that, if a single kernel image
      supports (1) and (2) that image can be used with both 32-bit and 64-bit
      boot loaders, and hence both 32-bit and 64-bit EFI.
      
      (1) and (2) must be 512 bytes apart at all times, but that is already
      part of the boot ABI and we could never change that delta without
      breaking existing boot loaders anyhow.
      Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
      b8ff87a6
    • B
      x86/efi: Make efi virtual runtime map passing more robust · b7b898ae
      Borislav Petkov 提交于
      Currently, running SetVirtualAddressMap() and passing the physical
      address of the virtual map array was working only by a lucky coincidence
      because the memory was present in the EFI page table too. Until Toshi
      went and booted this on a big HP box - the krealloc() manner of resizing
      the memmap we're doing did allocate from such physical addresses which
      were not mapped anymore and boom:
      
      http://lkml.kernel.org/r/1386806463.1791.295.camel@misato.fc.hp.com
      
      One way to take care of that issue is to reimplement the krealloc thing
      but with pages. We start with contiguous pages of order 1, i.e. 2 pages,
      and when we deplete that memory (shouldn't happen all that often but you
      know firmware) we realloc the next power-of-two pages.
      
      Having the pages, it is much more handy and easy to map them into the
      EFI page table with the already existing mapping code which we're using
      for building the virtual mappings.
      
      Thanks to Toshi Kani and Matt for the great debugging help.
      Reported-by: NToshi Kani <toshi.kani@hp.com>
      Signed-off-by: NBorislav Petkov <bp@suse.de>
      Tested-by: NToshi Kani <toshi.kani@hp.com>
      Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
      b7b898ae
    • B
      x86/efi: Dump the EFI page table · 11cc8512
      Borislav Petkov 提交于
      This is very useful for debugging issues with the recently added
      pagetable switching code for EFI virtual mode.
      Signed-off-by: NBorislav Petkov <bp@suse.de>
      Tested-by: NToshi Kani <toshi.kani@hp.com>
      Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
      11cc8512
    • M
      efi: Move facility flags to struct efi · 3e909599
      Matt Fleming 提交于
      As we grow support for more EFI architectures they're going to want the
      ability to query which EFI features are available on the running system.
      Instead of storing this information in an architecture-specific place,
      stick it in the global 'struct efi', which is already the central
      location for EFI state.
      
      While we're at it, let's change the return value of efi_enabled() to be
      bool and replace all references to 'facility' with 'feature', which is
      the usual word used to describe the attributes of the running system.
      Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
      3e909599
  16. 14 2月, 2014 1 次提交
  17. 03 1月, 2014 1 次提交
  18. 29 12月, 2013 1 次提交
    • 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
  19. 21 12月, 2013 1 次提交
  20. 02 11月, 2013 1 次提交
    • B
      x86/efi: Runtime services virtual mapping · d2f7cbe7
      Borislav Petkov 提交于
      We map the EFI regions needed for runtime services non-contiguously,
      with preserved alignment on virtual addresses starting from -4G down
      for a total max space of 64G. This way, we provide for stable runtime
      services addresses across kernels so that a kexec'd kernel can still use
      them.
      
      Thus, they're mapped in a separate pagetable so that we don't pollute
      the kernel namespace.
      
      Add an efi= kernel command line parameter for passing miscellaneous
      options and chicken bits from the command line.
      
      While at it, add a chicken bit called "efi=old_map" which can be used as
      a fallback to the old runtime services mapping method in case there's
      some b0rkage with a particular EFI implementation (haha, it is hard to
      hold up the sarcasm here...).
      
      Also, add the UEFI RT VA space to Documentation/x86/x86_64/mm.txt.
      Signed-off-by: NBorislav Petkov <bp@suse.de>
      Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
      d2f7cbe7
  21. 29 10月, 2013 1 次提交
  22. 11 6月, 2013 2 次提交
    • B
      efi: Convert runtime services function ptrs · 43ab0476
      Borislav Petkov 提交于
      ... to void * like the boot services and lose all the void * casts. No
      functionality change.
      Signed-off-by: NBorislav Petkov <bp@suse.de>
      Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
      43ab0476
    • 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
  23. 16 4月, 2013 1 次提交
    • 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
  24. 14 2月, 2013 1 次提交
  25. 31 1月, 2013 1 次提交
    • M
      efi: Make 'efi_enabled' a function to query EFI facilities · 83e68189
      Matt Fleming 提交于
      Originally 'efi_enabled' indicated whether a kernel was booted from
      EFI firmware. Over time its semantics have changed, and it now
      indicates whether or not we are booted on an EFI machine with
      bit-native firmware, e.g. 64-bit kernel with 64-bit firmware.
      
      The immediate motivation for this patch is the bug report at,
      
          https://bugs.launchpad.net/ubuntu-cdimage/+bug/1040557
      
      which details how running a platform driver on an EFI machine that is
      designed to run under BIOS can cause the machine to become
      bricked. Also, the following report,
      
          https://bugzilla.kernel.org/show_bug.cgi?id=47121
      
      details how running said driver can also cause Machine Check
      Exceptions. Drivers need a new means of detecting whether they're
      running on an EFI machine, as sadly the expression,
      
          if (!efi_enabled)
      
      hasn't been a sufficient condition for quite some time.
      
      Users actually want to query 'efi_enabled' for different reasons -
      what they really want access to is the list of available EFI
      facilities.
      
      For instance, the x86 reboot code needs to know whether it can invoke
      the ResetSystem() function provided by the EFI runtime services, while
      the ACPI OSL code wants to know whether the EFI config tables were
      mapped successfully. There are also checks in some of the platform
      driver code to simply see if they're running on an EFI machine (which
      would make it a bad idea to do BIOS-y things).
      
      This patch is a prereq for the samsung-laptop fix patch.
      
      Cc: David Airlie <airlied@linux.ie>
      Cc: Corentin Chary <corentincj@iksaif.net>
      Cc: Matthew Garrett <mjg59@srcf.ucam.org>
      Cc: Dave Jiang <dave.jiang@intel.com>
      Cc: Olof Johansson <olof@lixom.net>
      Cc: Peter Jones <pjones@redhat.com>
      Cc: Colin Ian King <colin.king@canonical.com>
      Cc: Steve Langasek <steve.langasek@canonical.com>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: Konrad Rzeszutek Wilk <konrad@kernel.org>
      Cc: Rafael J. Wysocki <rjw@sisk.pl>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
      Signed-off-by: NH. Peter Anvin <hpa@linux.intel.com>
      83e68189
  26. 16 12月, 2012 1 次提交