1. 14 10月, 2015 1 次提交
  2. 31 7月, 2015 1 次提交
    • D
      x86/efi: Use all 64 bit of efi_memmap in setup_e820() · 7cc03e48
      Dmitry Skorodumov 提交于
      The efi_info structure stores low 32 bits of memory map
      in efi_memmap and high 32 bits in efi_memmap_hi.
      
      While constructing pointer in the setup_e820(), need
      to take into account all 64 bit of the pointer.
      
      It is because on 64bit machine the function
      efi_get_memory_map() may return full 64bit pointer and before
      the patch that pointer was truncated.
      
      The issue is triggered on Parallles virtual machine and
      fixed with this patch.
      Signed-off-by: NDmitry Skorodumov <sdmitry@parallels.com>
      Cc: Denis V. Lunev <den@openvz.org>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
      7cc03e48
  3. 21 7月, 2015 1 次提交
  4. 28 5月, 2015 1 次提交
    • D
      e820, efi: add ACPI 6.0 persistent memory types · ad5fb870
      Dan Williams 提交于
      ACPI 6.0 formalizes e820-type-7 and efi-type-14 as persistent memory.
      Mark it "reserved" and allow it to be claimed by a persistent memory
      device driver.
      
      This definition is in addition to the Linux kernel's existing type-12
      definition that was recently added in support of shipping platforms with
      NVDIMM support that predate ACPI 6.0 (which now classifies type-12 as
      OEM reserved).
      
      Note, /proc/iomem can be consulted for differentiating legacy
      "Persistent Memory (legacy)" E820_PRAM vs standard "Persistent Memory"
      E820_PMEM.
      
      Cc: Boaz Harrosh <boaz@plexistor.com>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Christoph Hellwig <hch@lst.de>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Jens Axboe <axboe@fb.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Matthew Wilcox <willy@linux.intel.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Acked-by: NJeff Moyer <jmoyer@redhat.com>
      Acked-by: NAndy Lutomirski <luto@amacapital.net>
      Reviewed-by: NRoss Zwisler <ross.zwisler@linux.intel.com>
      Acked-by: NChristoph Hellwig <hch@lst.de>
      Tested-by: NToshi Kani <toshi.kani@hp.com>
      Signed-off-by: NDan Williams <dan.j.williams@intel.com>
      ad5fb870
  5. 17 4月, 2015 1 次提交
    • R
      x86/efi: Store upper bits of command line buffer address in ext_cmd_line_ptr · 98b228f5
      Roy Franz 提交于
      Until now, the EFI stub was only setting the 32 bit cmd_line_ptr in
      the setup_header structure, so on 64 bit platforms this could be truncated.
      This patch adds setting the upper bits of the buffer address in
      ext_cmd_line_ptr.  This case was likely never hit, as the allocation
      for this buffer is done at the lowest available address.  Only
      x86_64 kernels have this problem, as the 1-1 mapping mandated
      by EFI ensures that all memory is 32 bit addressable on 32 bit
      platforms.  The EFI stub does not support mixed mode, so the
      32 bit kernel on 64 bit firmware case does not need to be handled.
      Signed-off-by: NRoy Franz <roy.franz@linaro.org>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
      98b228f5
  6. 14 2月, 2015 1 次提交
    • A
      x86_64: kasan: add interceptors for memset/memmove/memcpy functions · 393f203f
      Andrey Ryabinin 提交于
      Recently instrumentation of builtin functions calls was removed from GCC
      5.0.  To check the memory accessed by such functions, userspace asan
      always uses interceptors for them.
      
      So now we should do this as well.  This patch declares
      memset/memmove/memcpy as weak symbols.  In mm/kasan/kasan.c we have our
      own implementation of those functions which checks memory before accessing
      it.
      
      Default memset/memmove/memcpy now now always have aliases with '__'
      prefix.  For files that built without kasan instrumentation (e.g.
      mm/slub.c) original mem* replaced (via #define) with prefixed variants,
      cause we don't want to check memory accesses there.
      Signed-off-by: NAndrey Ryabinin <a.ryabinin@samsung.com>
      Cc: Dmitry Vyukov <dvyukov@google.com>
      Cc: Konstantin Serebryany <kcc@google.com>
      Cc: Dmitry Chernenkov <dmitryc@google.com>
      Signed-off-by: NAndrey Konovalov <adech.fo@gmail.com>
      Cc: Yuri Gribov <tetra2005@gmail.com>
      Cc: Konstantin Khlebnikov <koct9i@gmail.com>
      Cc: Sasha Levin <sasha.levin@oracle.com>
      Cc: Christoph Lameter <cl@linux.com>
      Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
      Cc: Dave Hansen <dave.hansen@intel.com>
      Cc: Andi Kleen <andi@firstfloor.org>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Christoph Lameter <cl@linux.com>
      Cc: Pekka Enberg <penberg@kernel.org>
      Cc: David Rientjes <rientjes@google.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      393f203f
  7. 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
  8. 04 10月, 2014 2 次提交
    • A
      x86/efi: Adding efi_printks on memory allocationa and pci.reads · 77e21e87
      Andre Müller 提交于
      All other calls to allocate memory seem to make some noise already, with the
      exception of two calls (for gop, uga) in the setup_graphics path.
      
      The purpose is to be noisy on worrysome errors immediately.
      
      commit fb86b244 ("x86/efi: Add better error logging to EFI boot
      stub") introduces printing false alarms for lots of hardware. Rather
      than playing Whack a Mole with non-fatal exit conditions, try the other
      way round.
      
      This is per Matt Fleming's suggestion:
      
      > Where I think we could improve things
      > is by adding efi_printk() message in certain error paths. Clearly, not
      > all error paths need such messages, e.g. the EFI_INVALID_PARAMETER path
      > you highlighted above, but it makes sense for memory allocation and PCI
      > read failures.
      
      Link: http://article.gmane.org/gmane.linux.kernel.efi/4628Signed-off-by: NAndre Müller <andre.muller@web.de>
      Cc: Ulf Winkelvos <ulf@winkelvos.de>
      Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
      77e21e87
    • 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
  9. 25 9月, 2014 1 次提交
    • M
      x86/efi: Truncate 64-bit values when calling 32-bit OutputString() · 115c6628
      Matt Fleming 提交于
      If we're executing the 32-bit efi_char16_printk() code path (i.e.
      running on top of 32-bit firmware) we know that efi_early->text_output
      will be a 32-bit value, even though ->text_output has type u64.
      
      Unfortunately, we currently pass ->text_output directly to
      efi_early->call() so for CONFIG_X86_32 the compiler will push a 64-bit
      value onto the stack, causing the other parameters to be misaligned.
      
      The way we handle this in the rest of the EFI boot stub is to pass
      pointers as arguments to efi_early->call(), which automatically do the
      right thing (pointers are 32-bit on CONFIG_X86_32, and we simply ignore
      the upper 32-bits of the argument register if running in 64-bit mode
      with 32-bit firmware).
      
      This fixes a corruption bug when printing strings from the 32-bit EFI
      boot stub.
      
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=84241Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
      115c6628
  10. 24 9月, 2014 2 次提交
    • M
      x86/efi: Delete misleading efi_printk() error message · 56394ab8
      Matt Fleming 提交于
      A number of people are reporting seeing the "setup_efi_pci() failed!"
      error message in what used to be a quiet boot,
      
        https://bugzilla.kernel.org/show_bug.cgi?id=81891
      
      The message isn't all that helpful because setup_efi_pci() can return a
      non-success error code for a variety of reasons, not all of them fatal.
      
      Let's drop the return code from setup_efi_pci*() altogether, since
      there's no way to process it in any meaningful way outside of the inner
      __setup_efi_pci*() functions.
      Reported-by: NDarren Hart <dvhart@linux.intel.com>
      Reported-by: NJosh Boyer <jwboyer@fedoraproject.org>
      Cc: Ulf Winkelvos <ulf@winkelvos.de>
      Cc: Andre Müller <andre.muller@web.de>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
      56394ab8
    • 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. 09 9月, 2014 1 次提交
    • Y
      x86/efi: Only load initrd above 4g on second try · 47226ad4
      Yinghai Lu 提交于
      Mantas found that after commit 4bf7111f ("x86/efi: Support initrd
      loaded above 4G"), the kernel freezes at the earliest possible moment
      when trying to boot via UEFI on Asus laptop.
      
      Revert to old way to load initrd under 4G on first try, second try will
      use above 4G buffer when initrd is too big and does not fit under 4G.
      
      [ The cause of the freeze appears to be a firmware bug when reading
        file data into buffers above 4GB, though the exact reason is unknown.
        Mantas reports that the hang can be avoid if the file size is a
        multiple of 512 bytes, but I've seen some ASUS firmware simply
        corrupting the file data rather than freezing.
      
        Laszlo fixed an issue in the upstream EDK2 DiskIO code in Aug 2013
        which may possibly be related, commit 4e39b75e ("MdeModulePkg/DiskIoDxe:
        fix source/destination pointer of overrun transfer").
      
        Whatever the cause, it's unlikely that a fix will be forthcoming
        from the vendor, hence the workaround - Matt ]
      
      Cc: Laszlo Ersek <lersek@redhat.com>
      Reported-by: NMantas Mikulėnas <grawity@gmail.com>
      Reported-by: NHarald Hoyer <harald@redhat.com>
      Tested-by: NAnders Darander <anders@chargestorm.se>
      Tested-by: NCalvin Walton <calvin.walton@kepstin.ca>
      Signed-off-by: NYinghai Lu <yinghai@kernel.org>
      Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
      47226ad4
  12. 19 7月, 2014 2 次提交
  13. 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: efistub: Move shared dependencies to <asm/efi.h> · f23cf8bd
      Ard Biesheuvel 提交于
      This moves definitions depended upon both by code under arch/x86/boot
      and under drivers/firmware/efi to <asm/efi.h>. This is in preparation of
      turning the stub code under drivers/firmware/efi into a static library.
      Signed-off-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
      f23cf8bd
  14. 19 6月, 2014 1 次提交
  15. 17 4月, 2014 1 次提交
  16. 11 4月, 2014 3 次提交
  17. 27 3月, 2014 1 次提交
  18. 05 3月, 2014 3 次提交
    • 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
    • M
      x86/efi: Split the boot stub into 32/64 code paths · c116e8d6
      Matt Fleming 提交于
      Make the decision which code path to take at runtime based on
      efi_early->is64.
      Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
      c116e8d6
    • M
      x86/efi: Build our own EFI services pointer table · 54b52d87
      Matt Fleming 提交于
      It's not possible to dereference the EFI System table directly when
      booting a 64-bit kernel on a 32-bit EFI firmware because the size of
      pointers don't match.
      
      In preparation for supporting the above use case, build a list of
      function pointers on boot so that callers don't have to worry about
      converting pointer sizes through multiple levels of indirection.
      Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
      54b52d87
  19. 30 9月, 2013 2 次提交
    • B
      x86 efi: bugfix interrupt disabling sequence · 0ce6cda2
      Bart Kuivenhoven 提交于
      The problem in efi_main was that the idt was cleared before the
      interrupts were disabled.
      
      The UEFI spec states that interrupts aren't used so this shouldn't be
      too much of a problem. Peripherals however don't necessarily know about
      this and thus might cause interrupts to happen anyway. Even if
      ExitBootServices() has been called.
      
      This means there is a risk of an interrupt being triggered while the IDT
      register is nullified and the interrupt bit hasn't been cleared,
      allowing for a triple fault.
      
      This patch disables the interrupt flag, while leaving the existing IDT
      in place. The CPU won't care about the IDT at all as long as the
      interrupt bit is off, so it's safe to leave it in place as nothing will
      ever happen to it.
      
      [ Removed the now unused 'idt' variable - Matt ]
      Signed-off-by: NBart Kuivenhoven <bemk@redhat.com>
      Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
      0ce6cda2
    • L
      x86: EFI stub support for large memory maps · d2078d5a
      Linn Crosetto 提交于
      This patch fixes a problem with EFI memory maps larger than 128 entries
      when booting using the EFI stub, which results in overflowing e820_map
      in boot_params and an eventual halt when checking the map size in
      sanitize_e820_map().
      
      If the number of map entries is greater than what can fit in e820_map,
      add the extra entries to the setup_data list using type SETUP_E820_EXT.
      These extra entries are then picked up when the setup_data list is
      parsed in parse_e820_ext().
      Signed-off-by: NLinn Crosetto <linn@hp.com>
      Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
      d2078d5a
  20. 25 9月, 2013 9 次提交
  21. 26 7月, 2013 1 次提交
  22. 11 6月, 2013 2 次提交
    • Z
      x86, efi: retry ExitBootServices() on failure · d3768d88
      Zach Bobroff 提交于
      ExitBootServices is absolutely supposed to return a failure if any
      ExitBootServices event handler changes the memory map.  Basically the
      get_map loop should run again if ExitBootServices returns an error the
      first time.  I would say it would be fair that if ExitBootServices gives
      an error the second time then Linux would be fine in returning control
      back to BIOS.
      
      The second change is the following line:
      
      again:
              size += sizeof(*mem_map) * 2;
      
      Originally you were incrementing it by the size of one memory map entry.
      The issue here is all related to the low_alloc routine you are using.
      In this routine you are making allocations to get the memory map itself.
      Doing this allocation or allocations can affect the memory map by more
      than one record.
      
      [ mfleming - changelog, code style ]
      Signed-off-by: NZach Bobroff <zacharyb@ami.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
      d3768d88
    • 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