1. 09 8月, 2014 1 次提交
    • V
      kexec: support kexec/kdump on EFI systems · 6a2c20e7
      Vivek Goyal 提交于
      This patch does two things.  It passes EFI run time mappings to second
      kernel in bootparams efi_info.  Second kernel parse this info and create
      new mappings in second kernel.  That means mappings in first and second
      kernel will be same.  This paves the way to enable EFI in kexec kernel.
      
      This patch also prepares and passes EFI setup data through bootparams.
      This contains bunch of information about various tables and their
      addresses.
      
      These information gathering and passing has been written along the lines
      of what current kexec-tools is doing to make kexec work with UEFI.
      
      [akpm@linux-foundation.org: s/get_efi/efi_get/g, per Matt]
      Signed-off-by: NVivek Goyal <vgoyal@redhat.com>
      Cc: Borislav Petkov <bp@suse.de>
      Cc: Michael Kerrisk <mtk.manpages@gmail.com>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Cc: Eric Biederman <ebiederm@xmission.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Matthew Garrett <mjg59@srcf.ucam.org>
      Cc: Greg Kroah-Hartman <greg@kroah.com>
      Cc: Dave Young <dyoung@redhat.com>
      Cc: WANG Chao <chaowang@redhat.com>
      Cc: Baoquan He <bhe@redhat.com>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Matt Fleming <matt@console-pimps.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      6a2c20e7
  2. 19 7月, 2014 6 次提交
  3. 08 7月, 2014 2 次提交
    • A
      efi: efistub: Refactor stub components · bd669475
      Ard Biesheuvel 提交于
      In order to move from the #include "../../../xxxxx.c" anti-pattern used
      by both the x86 and arm64 versions of the stub to a static library
      linked into either the kernel proper (arm64) or a separate boot
      executable (x86), there is some prepatory work required.
      
      This patch does the following:
      - move forward declarations of functions shared between the arch
        specific and the generic parts of the stub to include/linux/efi.h
      - move forward declarations of functions shared between various .c files
        of the generic stub code to a new local header file called "efistub.h"
      - add #includes to all .c files which were formerly relying on the
        #includor to include the correct header files
      - remove all static modifiers from functions which will need to be
        externally visible once we move to a static library
      Signed-off-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
      bd669475
    • A
      efi/x86: Move UEFI Runtime Services wrappers to generic code · 022ee6c5
      Ard Biesheuvel 提交于
      In order for other archs (such as arm64) to be able to reuse the virtual
      mode function call wrappers, move them to drivers/firmware/efi/runtime-wrappers.c.
      Signed-off-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
      022ee6c5
  4. 01 5月, 2014 2 次提交
  5. 17 4月, 2014 1 次提交
  6. 15 4月, 2014 1 次提交
  7. 05 3月, 2014 3 次提交
    • M
      efi: Add separate 32-bit/64-bit definitions · 677703ce
      Matt Fleming 提交于
      The traditional approach of using machine-specific types such as
      'unsigned long' does not allow the kernel to interact with firmware
      running in a different CPU mode, e.g. 64-bit kernel with 32-bit EFI.
      
      Add distinct EFI structure definitions for both 32-bit and 64-bit so
      that we can use them in the 32-bit and 64-bit code paths.
      Acked-by: NBorislav Petkov <bp@suse.de>
      Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
      677703ce
    • M
      ia64/efi: Implement efi_enabled() · 09206380
      Matt Fleming 提交于
      There's no good reason to keep efi_enabled() under CONFIG_X86 anymore,
      since nothing about the implementation is specific to x86.
      
      Set EFI feature flags in the ia64 boot path instead of claiming to
      support all features. The old behaviour was actually buggy since
      efi.memmap never points to a valid memory map, so we shouldn't be
      claiming to support EFI_MEMMAP.
      
      Fortunately, this bug was never triggered because EFI_MEMMAP isn't used
      outside of arch/x86 currently, but that may not always be the case.
      Reviewed-and-tested-by: NTony Luck <tony.luck@intel.com>
      Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
      09206380
    • 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
  8. 21 12月, 2013 2 次提交
  9. 29 11月, 2013 1 次提交
    • S
      efivars, efi-pstore: Hold off deletion of sysfs entry until the scan is completed · e0d59733
      Seiji Aguchi 提交于
      Currently, when mounting pstore file system, a read callback of
      efi_pstore driver runs mutiple times as below.
      
      - In the first read callback, scan efivar_sysfs_list from head and pass
        a kmsg buffer of a entry to an upper pstore layer.
      - In the second read callback, rescan efivar_sysfs_list from the entry
        and pass another kmsg buffer to it.
      - Repeat the scan and pass until the end of efivar_sysfs_list.
      
      In this process, an entry is read across the multiple read function
      calls. To avoid race between the read and erasion, the whole process
      above is protected by a spinlock, holding in open() and releasing in
      close().
      
      At the same time, kmemdup() is called to pass the buffer to pstore
      filesystem during it. And then, it causes a following lockdep warning.
      
      To make the dynamic memory allocation runnable without taking spinlock,
      holding off a deletion of sysfs entry if it happens while scanning it
      via efi_pstore, and deleting it after the scan is completed.
      
      To implement it, this patch introduces two flags, scanning and deleting,
      to efivar_entry.
      
      On the code basis, it seems that all the scanning and deleting logic is
      not needed because __efivars->lock are not dropped when reading from the
      EFI variable store.
      
      But, the scanning and deleting logic is still needed because an
      efi-pstore and a pstore filesystem works as follows.
      
      In case an entry(A) is found, the pointer is saved to psi->data.  And
      efi_pstore_read() passes the entry(A) to a pstore filesystem by
      releasing  __efivars->lock.
      
      And then, the pstore filesystem calls efi_pstore_read() again and the
      same entry(A), which is saved to psi->data, is used for resuming to scan
      a sysfs-list.
      
      So, to protect the entry(A), the logic is needed.
      
      [    1.143710] ------------[ cut here ]------------
      [    1.144058] WARNING: CPU: 1 PID: 1 at kernel/lockdep.c:2740 lockdep_trace_alloc+0x104/0x110()
      [    1.144058] DEBUG_LOCKS_WARN_ON(irqs_disabled_flags(flags))
      [    1.144058] Modules linked in:
      [    1.144058] CPU: 1 PID: 1 Comm: systemd Not tainted 3.11.0-rc5 #2
      [    1.144058]  0000000000000009 ffff8800797e9ae0 ffffffff816614a5 ffff8800797e9b28
      [    1.144058]  ffff8800797e9b18 ffffffff8105510d 0000000000000080 0000000000000046
      [    1.144058]  00000000000000d0 00000000000003af ffffffff81ccd0c0 ffff8800797e9b78
      [    1.144058] Call Trace:
      [    1.144058]  [<ffffffff816614a5>] dump_stack+0x54/0x74
      [    1.144058]  [<ffffffff8105510d>] warn_slowpath_common+0x7d/0xa0
      [    1.144058]  [<ffffffff8105517c>] warn_slowpath_fmt+0x4c/0x50
      [    1.144058]  [<ffffffff8131290f>] ? vsscanf+0x57f/0x7b0
      [    1.144058]  [<ffffffff810bbd74>] lockdep_trace_alloc+0x104/0x110
      [    1.144058]  [<ffffffff81192da0>] __kmalloc_track_caller+0x50/0x280
      [    1.144058]  [<ffffffff815147bb>] ? efi_pstore_read_func.part.1+0x12b/0x170
      [    1.144058]  [<ffffffff8115b260>] kmemdup+0x20/0x50
      [    1.144058]  [<ffffffff815147bb>] efi_pstore_read_func.part.1+0x12b/0x170
      [    1.144058]  [<ffffffff81514800>] ? efi_pstore_read_func.part.1+0x170/0x170
      [    1.144058]  [<ffffffff815148b4>] efi_pstore_read_func+0xb4/0xe0
      [    1.144058]  [<ffffffff81512b7b>] __efivar_entry_iter+0xfb/0x120
      [    1.144058]  [<ffffffff8151428f>] efi_pstore_read+0x3f/0x50
      [    1.144058]  [<ffffffff8128d7ba>] pstore_get_records+0x9a/0x150
      [    1.158207]  [<ffffffff812af25c>] ? selinux_d_instantiate+0x1c/0x20
      [    1.158207]  [<ffffffff8128ce30>] ? parse_options+0x80/0x80
      [    1.158207]  [<ffffffff8128ced5>] pstore_fill_super+0xa5/0xc0
      [    1.158207]  [<ffffffff811ae7d2>] mount_single+0xa2/0xd0
      [    1.158207]  [<ffffffff8128ccf8>] pstore_mount+0x18/0x20
      [    1.158207]  [<ffffffff811ae8b9>] mount_fs+0x39/0x1b0
      [    1.158207]  [<ffffffff81160550>] ? __alloc_percpu+0x10/0x20
      [    1.158207]  [<ffffffff811c9493>] vfs_kern_mount+0x63/0xf0
      [    1.158207]  [<ffffffff811cbb0e>] do_mount+0x23e/0xa20
      [    1.158207]  [<ffffffff8115b51b>] ? strndup_user+0x4b/0xf0
      [    1.158207]  [<ffffffff811cc373>] SyS_mount+0x83/0xc0
      [    1.158207]  [<ffffffff81673cc2>] system_call_fastpath+0x16/0x1b
      [    1.158207] ---[ end trace 61981bc62de9f6f4 ]---
      Signed-off-by: NSeiji Aguchi <seiji.aguchi@hds.com>
      Tested-by: NMadper Xie <cxie@redhat.com>
      Cc: stable@kernel.org
      Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
      e0d59733
  10. 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
  11. 25 9月, 2013 1 次提交
  12. 05 9月, 2013 2 次提交
  13. 11 6月, 2013 1 次提交
  14. 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
  15. 30 4月, 2013 1 次提交
  16. 17 4月, 2013 4 次提交
    • T
      efi: split efisubsystem from efivars · a9499fa7
      Tom Gundersen 提交于
      This registers /sys/firmware/efi/{,systab,efivars/} whenever EFI is enabled
      and the system is booted with EFI.
      
      This allows
       *) userspace to check for the existence of /sys/firmware/efi as a way
          to determine whether or it is running on an EFI system.
       *) 'mount -t efivarfs none /sys/firmware/efi/efivars' without manually
          loading any modules.
      
      [ Also, move the efivar API into vars.c and unconditionally compile it.
        This allows us to move efivars.c, which now only contains the sysfs
        variable code, into the firmware/efi directory. Note that the efivars.c
        filename is kept to maintain backwards compatability with the old
        efivars.ko module. With this patch it is now possible for efivarfs
        to be built without CONFIG_EFI_VARS - Matt ]
      
      Cc: Seiji Aguchi <seiji.aguchi@hds.com>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: Mike Waychison <mikew@google.com>
      Cc: Kay Sievers <kay@vrfy.org>
      Cc: Jeremy Kerr <jk@ozlabs.org>
      Cc: Matthew Garrett <mjg59@srcf.ucam.org>
      Cc: Chun-Yi Lee <jlee@suse.com>
      Cc: Andy Whitcroft <apw@canonical.com>
      Cc: Tobias Powalowski <tpowa@archlinux.org>
      Signed-off-by: NTom Gundersen <teg@jklm.no>
      Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
      a9499fa7
    • M
      efivars: Move pstore code into the new EFI directory · 04851772
      Matt Fleming 提交于
      efivars.c has grown far too large and needs to be divided up. Create a
      new directory and move the persistence storage code to efi-pstore.c now
      that it uses the new efivar API. This helps us to greatly reduce the
      size of efivars.c and paves the way for moving other code out of
      efivars.c.
      
      Note that because CONFIG_EFI_VARS can be built as a module efi-pstore
      must also include support for building as a module.
      Reviewed-by: NTom Gundersen <teg@jklm.no>
      Tested-by: NTom Gundersen <teg@jklm.no>
      Cc: Seiji Aguchi <seiji.aguchi@hds.com>
      Cc: Anton Vorontsov <cbouatmailru@gmail.com>
      Cc: Colin Cross <ccross@android.com>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: Matthew Garrett <mjg59@srcf.ucam.org>
      Cc: Tony Luck <tony.luck@intel.com>
      Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
      04851772
    • M
      efivars: efivar_entry API · e14ab23d
      Matt Fleming 提交于
      There isn't really a formal interface for dealing with EFI variables
      or struct efivar_entry. Historically, this has led to various bits of
      code directly accessing the generic EFI variable ops, which inherently
      ties it to specific EFI variable operations instead of indirectly
      using whatever ops were registered with register_efivars(). This lead
      to the efivarfs code only working with the generic EFI variable ops
      and not CONFIG_GOOGLE_SMI.
      
      Encapsulate everything that needs to access '__efivars' inside an
      efivar_entry_* API and use the new API in the pstore, sysfs and
      efivarfs code.
      
      Much of the efivars code had to be rewritten to use this new API. For
      instance, it is now up to the users of the API to build the initial
      list of EFI variables in their efivar_init() callback function. The
      variable list needs to be passed to efivar_init() which allows us to
      keep work arounds for things like implementation bugs in
      GetNextVariable() in a central location.
      
      Allowing users of the API to use a callback function to build the list
      greatly benefits the efivarfs code which needs to allocate inodes and
      dentries for every variable.  It previously did this in a racy way
      because the code ran without holding the variable spinlock. Both the
      sysfs and efivarfs code maintain their own lists which means the two
      interfaces can be running simultaneously without interference, though
      it should be noted that because no synchronisation is performed it is
      very easy to create inconsistencies. efibootmgr doesn't currently use
      efivarfs and users are likely to also require the old sysfs interface,
      so it makes sense to allow both to be built.
      Reviewed-by: NTom Gundersen <teg@jklm.no>
      Tested-by: NTom Gundersen <teg@jklm.no>
      Cc: Seiji Aguchi <seiji.aguchi@hds.com>
      Cc: Matthew Garrett <mjg59@srcf.ucam.org>
      Cc: Jeremy Kerr <jk@ozlabs.org>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: Mike Waychison <mikew@google.com>
      Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
      e14ab23d
    • M
      efi: move utf16 string functions to efi.h · d5abc7c1
      Matt Fleming 提交于
      There are currently two implementations of the utf16 string functions.
      Somewhat confusingly, they've got different names.
      
      Centralise the functions in efi.h.
      Reviewed-by: NTom Gundersen <teg@jklm.no>
      Tested-by: NTom Gundersen <teg@jklm.no>
      Reviewed-by: NMike Waychison <mikew@google.com>
      Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
      d5abc7c1
  17. 09 4月, 2013 1 次提交
    • M
      x86, efivars: firmware bug workarounds should be in platform code · a6e4d5a0
      Matt Fleming 提交于
      Let's not burden ia64 with checks in the common efivars code that we're not
      writing too much data to the variable store. That kind of thing is an x86
      firmware bug, plain and simple.
      
      efi_query_variable_store() provides platforms with a wrapper in which they can
      perform checks and workarounds for EFI variable storage bugs.
      
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Matthew Garrett <mjg59@srcf.ucam.org>
      Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
      a6e4d5a0
  18. 13 2月, 2013 1 次提交
    • S
      efi_pstore: Introducing workqueue updating sysfs · a93bc0c6
      Seiji Aguchi 提交于
      [Problem]
      efi_pstore creates sysfs entries, which enable users to access to NVRAM,
      in a write callback. If a kernel panic happens in an interrupt context,
      it may fail because it could sleep due to dynamic memory allocations during
      creating sysfs entries.
      
      [Patch Description]
      This patch removes sysfs operations from a write callback by introducing
      a workqueue updating sysfs entries which is scheduled after the write
      callback is called.
      
      Also, the workqueue is kicked in a just oops case.
      A system will go down in other cases such as panic, clean shutdown and emergency
      restart. And we don't need to create sysfs entries because there is no chance for
      users to access to them.
      
      efi_pstore will be robust against a kernel panic in an interrupt context with this patch.
      Signed-off-by: NSeiji Aguchi <seiji.aguchi@hds.com>
      Acked-by: NMatt Fleming <matt.fleming@intel.com>
      Signed-off-by: NTony Luck <tony.luck@intel.com>
      a93bc0c6
  19. 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
  20. 16 12月, 2012 1 次提交
  21. 06 12月, 2012 1 次提交
  22. 27 11月, 2012 1 次提交
  23. 13 11月, 2012 1 次提交
  24. 30 10月, 2012 3 次提交
    • J
      x86-64/efi: Use EFI to deal with platform wall clock (again) · bd52276f
      Jan Beulich 提交于
      Other than ix86, x86-64 on EFI so far didn't set the
      {g,s}et_wallclock accessors to the EFI routines, thus
      incorrectly using raw RTC accesses instead.
      
      Simply removing the #ifdef around the respective code isn't
      enough, however: While so far early get-time calls were done in
      physical mode, this doesn't work properly for x86-64, as virtual
      addresses would still need to be set up for all runtime regions
      (which wasn't the case on the system I have access to), so
      instead the patch moves the call to efi_enter_virtual_mode()
      ahead (which in turn allows to drop all code related to calling
      efi-get-time in physical mode).
      
      Additionally the earlier calling of efi_set_executable()
      requires the CPA code to cope, i.e. during early boot it must be
      avoided to call cpa_flush_array(), as the first thing this
      function does is a BUG_ON(irqs_disabled()).
      
      Also make the two EFI functions in question here static -
      they're not being referenced elsewhere.
      
      History:
      
          This commit was originally merged as bacef661 ("x86-64/efi:
          Use EFI to deal with platform wall clock") but it resulted in some
          ASUS machines no longer booting due to a firmware bug, and so was
          reverted in f026cfa8. A pre-emptive fix for the buggy ASUS
          firmware was merged in 03a1c254975e ("x86, efi: 1:1 pagetable
          mapping for virtual EFI calls") so now this patch can be
          reapplied.
      Signed-off-by: NJan Beulich <jbeulich@suse.com>
      Tested-by: NMatt Fleming <matt.fleming@intel.com>
      Acked-by: NMatthew Garrett <mjg@redhat.com>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Signed-off-by: Matt Fleming <matt.fleming@intel.com> [added commit history]
      bd52276f
    • L
      efi: add efivars kobject to efi sysfs folder · 605e70c7
      Lee, Chun-Yi 提交于
      UEFI variable filesystem need a new mount point, so this patch add
      efivars kobject to efi_kobj for create a /sys/firmware/efi/efivars
      folder.
      
      Cc: Matthew Garrett <mjg@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Signed-off-by: NLee, Chun-Yi <jlee@suse.com>
      Signed-off-by: NJeremy Kerr <jeremy.kerr@canonical.com>
      Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
      605e70c7
    • M
      efi: Add support for a UEFI variable filesystem · 5d9db883
      Matthew Garrett 提交于
      The existing EFI variables code only supports variables of up to 1024
      bytes. This limitation existed in version 0.99 of the EFI specification,
      but was removed before any full releases. Since variables can now be
      larger than a single page, sysfs isn't the best interface for this. So,
      instead, let's add a filesystem. Variables can be read, written and
      created, with the first 4 bytes of each variable representing its UEFI
      attributes. The create() method doesn't actually commit to flash since
      zero-length variables can't exist per-spec.
      
      Updates from Jeremy Kerr <jeremy.kerr@canonical.com>.
      Signed-off-by: NMatthew Garrett <mjg@redhat.com>
      Signed-off-by: NJeremy Kerr <jeremy.kerr@canonical.com>
      Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
      5d9db883