Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 17 8月, 2017 1 次提交
    • B
      efi: Introduce efi_early_memdesc_ptr to get pointer to memmap descriptor · 02e43c2d
      由 Baoquan He 提交于 
      The existing map iteration helper for_each_efi_memory_desc_in_map can
only be used after the kernel initializes the EFI subsystem to set up
struct efi_memory_map.

Before that we also need iterate map descriptors which are stored in several
intermediate structures, like struct efi_boot_memmap for arch independent
usage and struct efi_info for x86 arch only.

Introduce efi_early_memdesc_ptr() to get pointer to a map descriptor, and
replace several places where that primitive is open coded.
Signed-off-by: NBaoquan He <bhe@redhat.com>
[ Various improvements to the text. ]
Acked-by: NMatt Fleming <matt@codeblueprint.co.uk>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: ard.biesheuvel@linaro.org
Cc: fanc.fnst@cn.fujitsu.com
Cc: izumi.taku@jp.fujitsu.com
Cc: keescook@chromium.org
Cc: linux-efi@vger.kernel.org
Cc: n-horiguchi@ah.jp.nec.com
Cc: thgarnie@google.com
Link: http://lkml.kernel.org/r/20170816134651.GF21273@x1Signed-off-by: NIngo Molnar <mingo@kernel.org>
      02e43c2d
  3. 05 4月, 2017 3 次提交
  5. 07 2月, 2017 1 次提交
    • A
      efi/libstub: Make file I/O chunking x86-specific · b3879a4d
      由 Ard Biesheuvel 提交于 
      The ARM decompressor is finicky when it comes to uninitialized variables
with local linkage, the reason being that it may relocate .text and .bss
independently when executing from ROM. This is only possible if all
references into .bss from .text are absolute, and this happens to be the
case for references emitted under -fpic to symbols with external linkage,
and so all .bss references must involve symbols with external linkage.

When building the ARM stub using clang, the initialized local variable
__chunk_size is optimized into a zero-initialized flag that indicates
whether chunking is in effect or not. This flag is therefore emitted into
.bss, which triggers the ARM decompressor's diagnostics, resulting in a
failed build.

Under UEFI, we never execute the decompressor from ROM, so the diagnostic
makes little sense here. But we can easily work around the issue by making
__chunk_size global instead.

However, given that the file I/O chunking that is controlled by the
__chunk_size variable is intended to work around known bugs on various
x86 implementations of UEFI, we can simply make the chunking an x86
specific feature. This is an improvement by itself, and also removes the
need to parse the efi= options in the stub entirely.
Tested-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: NMatt Fleming <matt@codeblueprint.co.uk>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-efi@vger.kernel.org
Link: http://lkml.kernel.org/r/1486380166-31868-8-git-send-email-ard.biesheuvel@linaro.org
[ Small readability edits. ]
Signed-off-by: NIngo Molnar <mingo@kernel.org>
      b3879a4d
  7. 01 2月, 2017 1 次提交
  9. 13 11月, 2016 2 次提交
  11. 05 9月, 2016 2 次提交
    • J
      efi/libstub: Introduce ExitBootServices helper · fc07716b
      由 Jeffrey Hugo 提交于 
      The spec allows ExitBootServices to fail with EFI_INVALID_PARAMETER if a
race condition has occurred where the EFI has updated the memory map after
the stub grabbed a reference to the map.  The spec defines a retry
proceedure with specific requirements to handle this scenario.

This scenario was previously observed on x86 - commit d3768d88 ("x86,
efi: retry ExitBootServices() on failure") but the current fix is not spec
compliant and the scenario is now observed on the Qualcomm Technologies
QDF2432 via the FDT stub which does not handle the error and thus causes
boot failures.  The user will notice the boot failure as the kernel is not
executed and the system may drop back to a UEFI shell, but will be
unresponsive to input and the system will require a power cycle to recover.

Add a helper to the stub library that correctly adheres to the spec in the
case of EFI_INVALID_PARAMETER from ExitBootServices and can be universally
used across all stub implementations.
Signed-off-by: NJeffrey Hugo <jhugo@codeaurora.org>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Leif Lindholm <leif.lindholm@linaro.org>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: <stable@vger.kernel.org>
Signed-off-by: NMatt Fleming <matt@codeblueprint.co.uk>
      fc07716b
    • J
      efi/libstub: Allocate headspace in efi_get_memory_map() · dadb57ab
      由 Jeffrey Hugo 提交于 
      efi_get_memory_map() allocates a buffer to store the memory map that it
retrieves.  This buffer may need to be reused by the client after
ExitBootServices() is called, at which point allocations are not longer
permitted.  To support this usecase, provide the allocated buffer size back
to the client, and allocate some additional headroom to account for any
reasonable growth in the map that is likely to happen between the call to
efi_get_memory_map() and the client reusing the buffer.
Signed-off-by: NJeffrey Hugo <jhugo@codeaurora.org>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Leif Lindholm <leif.lindholm@linaro.org>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: <stable@vger.kernel.org>
Signed-off-by: NMatt Fleming <matt@codeblueprint.co.uk>
      dadb57ab
  13. 28 4月, 2016 1 次提交
  15. 24 2月, 2016 1 次提交
  17. 25 2月, 2015 1 次提交
    • Y
      efi/libstub: Fix boundary checking in efi_high_alloc() · 7ed620bb
      由 Yinghai Lu 提交于 
      While adding support loading kernel and initrd above 4G to grub2 in legacy
mode, I was referring to efi_high_alloc().
That will allocate buffer for kernel and then initrd, and initrd will
use kernel buffer start as limit.

During testing found two buffers will be overlapped when initrd size is
very big like 400M.

It turns out efi_high_alloc() boundary checking is not right.
end - size will be the new start, and should not compare new
start with max, we need to make sure end is smaller than max.

[ Basically, with the current efi_high_alloc() code it's possible to
  allocate memory above 'max', because efi_high_alloc() doesn't check
  that the tail of the allocation is below 'max'.

  If you have an EFI memory map with a single entry that looks like so,

   [0xc0000000-0xc0004000]

  And want to allocate 0x3000 bytes below 0xc0003000 the current code
  will allocate [0xc0001000-0xc0004000], not [0xc0000000-0xc0003000]
  like you would expect. - Matt ]
Signed-off-by: NYinghai Lu <yinghai@kernel.org>
Reviewed-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: NMark Rutland <mark.rutland@arm.com>
Tested-by: NMark Rutland <mark.rutland@arm.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
      7ed620bb
  19. 18 2月, 2015 1 次提交
    • M
      Revert "efi/libstub: Call get_memory_map() to obtain map and desc sizes" · 43a9f696
      由 Matt Fleming 提交于 
      This reverts commit d1a8d66b.

Ard reported a boot failure when running UEFI under Qemu and Xen and
experimenting with various Tianocore build options,

 "As it turns out, when allocating room for the UEFI memory map using
  UEFI's AllocatePool (), it may result in two new memory map entries
  being created, for instance, when using Tianocore's preallocated region
  feature. For example, the following region

  0x00005ead5000-0x00005ebfffff [Conventional Memory|   |  |  |  |  |WB|WT|WC|UC]

  may be split like this

  0x00005ead5000-0x00005eae2fff [Conventional Memory|   |  |  |  |  |WB|WT|WC|UC]
  0x00005eae3000-0x00005eae4fff [Loader Data        |   |  |  |  |  |WB|WT|WC|UC]
  0x00005eae5000-0x00005ebfffff [Conventional Memory|   |  |  |  |  |WB|WT|WC|UC]

  if the preallocated Loader Data region was chosen to be right in the
  middle of the original free space.

  After patch d1a8d66b ("efi/libstub: Call get_memory_map() to
  obtain map and desc sizes"), this is not being dealt with correctly
  anymore, as the existing logic to allocate room for a single additional
  entry has become insufficient."

Mark requested to reinstate the old loop we had before commit
d1a8d66b, which grows the memory map buffer until it's big enough to
hold the EFI memory map.
Acked-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
Acked-by: NMark Rutland <mark.rutland@arm.com>
Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
      43a9f696
  21. 21 1月, 2015 1 次提交
    • A
      efi/libstub: Call get_memory_map() to obtain map and desc sizes · d1a8d66b
      由 Ard Biesheuvel 提交于 
      This fixes two minor issues in the implementation of get_memory_map():
- Currently, it assumes that sizeof(efi_memory_desc_t) == desc_size,
  which is usually true, but not mandated by the spec. (This was added
  intentionally to allow future additions to the definition of
  efi_memory_desc_t). The way the loop is implemented currently, the
  added slack space may be insufficient if desc_size is larger, which in
  some corner cases could result in the loop never terminating.
- It allocates 32 efi_memory_desc_t entries first (again, using the size
  of the struct instead of desc_size), and frees and reallocates if it
  turns out to be insufficient. Few implementations of UEFI have such small
  memory maps, which results in a unnecessary allocate/free pair on each
  invocation.

Fix this by calling the get_memory_map() boot service first with a '0'
input value for map size to retrieve the map size and desc size from the
firmware and only then perform the allocation, using desc_size rather
than sizeof(efi_memory_desc_t).
Signed-off-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
      d1a8d66b
  23. 16 1月, 2015 1 次提交
    • A
      arm64/efi: efistub: Apply __init annotation · ddeeefe2
      由 Ard Biesheuvel 提交于 
      This ensures all stub component are freed when the kernel proper is
done booting, by prefixing the names of all ELF sections that have
the SHF_ALLOC attribute with ".init". This approach ensures that even
implicitly emitted allocated data (like initializer values and string
literals) are covered.

At the same time, remove some __init annotations in the stub that have
now become redundant, and add the __init annotation to handle_kernel_image
which will now trigger a section mismatch warning without it.
Signed-off-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
      ddeeefe2
  25. 12 1月, 2015 1 次提交
  27. 04 10月, 2014 1 次提交
    • 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
  29. 19 7月, 2014 1 次提交
    • A
      efi: efistub: Convert into static library · f4f75ad5
      由 Ard Biesheuvel 提交于 
      This patch changes both x86 and arm64 efistub implementations
from #including shared .c files under drivers/firmware/efi to
building shared code as a static library.

The x86 code uses a stub built into the boot executable which
uncompresses the kernel at boot time. In this case, the library is
linked into the decompressor.

In the arm64 case, the stub is part of the kernel proper so the library
is linked into the kernel proper as well.
Signed-off-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
      f4f75ad5
  31. 08 7月, 2014 1 次提交
    • 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
  33. 17 4月, 2014 2 次提交
  35. 15 4月, 2014 2 次提交
  37. 11 4月, 2014 1 次提交
    • M
      efi: Pass correct file handle to efi_file_{read,close} · 47514c99
      由 Matt Fleming 提交于 
      We're currently passing the file handle for the root file system to
efi_file_read() and efi_file_close(), instead of the file handle for the
file we wish to read/close.

While this has worked up until now, it seems that it has only been by
pure luck. Olivier explains,

 "The issue is the UEFI Fat driver might return the same function for
  'fh->read()' and 'h->read()'. While in our case it does not work with
  a different implementation of EFI_SIMPLE_FILE_SYSTEM_PROTOCOL. In our
  case, we return a different pointer when reading a directory and
  reading a file."

Fixing this actually clears up the two functions because we can drop one
of the arguments, and instead only pass a file 'handle' argument.
Reported-by: NOlivier Martin <olivier.martin@arm.com>
Reviewed-by: NOlivier Martin <olivier.martin@arm.com>
Reviewed-by: NMark Rutland <mark.rutland@arm.com>
Cc: Leif Lindholm <leif.lindholm@linaro.org>
Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
      47514c99
  39. 27 3月, 2014 1 次提交
  41. 05 3月, 2014 1 次提交
    • 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
  43. 05 10月, 2013 1 次提交
  45. 25 9月, 2013 12 次提交