Skip to content

K
Kernel

openeuler / Kernel
接近 2 年 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 17 9月, 2020 1 次提交
  3. 16 9月, 2020 3 次提交
  5. 09 7月, 2020 1 次提交
  7. 17 6月, 2020 1 次提交
    • A
      efi/libstub: arm: Print CPU boot mode and MMU state at boot · 2a55280a
      由 Ard Biesheuvel 提交于 
      On 32-bit ARM, we may boot at HYP mode, or with the MMU and caches off
(or both), even though the EFI spec does not actually support this.
While booting at HYP mode is something we might tolerate, fiddling
with the caches is a more serious issue, as disabling the caches is
tricky to do safely from C code, and running without the Dcache makes
it impossible to support unaligned memory accesses, which is another
explicit requirement imposed by the EFI spec.

So take note of the CPU mode and MMU state in the EFI stub diagnostic
output so that we can easily diagnose any issues that may arise from
this. E.g.,

  EFI stub: Entering in SVC mode with MMU enabled

Also, capture the CPSR and SCTLR system register values at EFI stub
entry, and after ExitBootServices() returns, and check whether the
MMU and Dcache were disabled at any point. If this is the case, a
diagnostic message like the following will be emitted:

  efi: [Firmware Bug]: EFI stub was entered with MMU and Dcache disabled, please fix your firmware!
  efi: CPSR at EFI stub entry        : 0x600001d3
  efi: SCTLR at EFI stub entry       : 0x00c51838
  efi: CPSR after ExitBootServices() : 0x600001d3
  efi: SCTLR after ExitBootServices(): 0x00c50838
Signed-off-by: NArd Biesheuvel <ardb@kernel.org>
Reviewed-by: NLeif Lindholm <leif@nuviainc.com>
      2a55280a
  9. 16 6月, 2020 1 次提交
  11. 23 5月, 2020 1 次提交
  13. 22 5月, 2020 1 次提交
  15. 21 5月, 2020 3 次提交
  17. 19 5月, 2020 3 次提交
  19. 14 5月, 2020 1 次提交
    • L
      efi/libstub/x86: Avoid EFI map buffer alloc in allocate_e820() · fd626195
      由 Lenny Szubowicz 提交于 
      In allocate_e820(), call the EFI get_memory_map() service directly
instead of indirectly via efi_get_memory_map(). This avoids allocation
of a buffer and return of the full EFI memory map, which is not needed
here and would otherwise need to be freed.

Routine allocate_e820() only needs to know how many EFI memory
descriptors there are in the map to allocate an adequately sized
e820ext buffer, if it's needed. Note that since efi_get_memory_map()
returns a memory map buffer sized with extra headroom, allocate_e820()
now needs to explicitly factor that into the e820ext size calculation.
Signed-off-by: NLenny Szubowicz <lszubowi@redhat.com>
Suggested-by: NArd Biesheuvel <ardb@kernel.org>
Signed-off-by: NArd Biesheuvel <ardb@kernel.org>
      fd626195
  21. 05 5月, 2020 2 次提交
  23. 01 5月, 2020 3 次提交
  25. 24 4月, 2020 11 次提交
  27. 14 4月, 2020 1 次提交
  29. 24 2月, 2020 7 次提交
    • A
      efi/libstub/x86: Use Exit() boot service to exit the stub on errors · 3b8f44fc
      由 Ard Biesheuvel 提交于 
      Currently, we either return with an error [from efi_pe_entry()] or
enter a deadloop [in efi_main()] if any fatal errors occur during
execution of the EFI stub. Let's switch to calling the Exit() EFI boot
service instead in both cases, so that we
a) can get rid of the deadloop, and simply return to the boot manager
   if any errors occur during execution of the stub, including during
   the call to ExitBootServices(),
b) can also return cleanly from efi_pe_entry() or efi_main() in mixed
   mode, once we introduce support for LoadImage/StartImage based mixed
   mode in the next patch.

Note that on systems running downstream GRUBs [which do not use LoadImage
or StartImage to boot the kernel, and instead, pass their own image
handle as the loaded image handle], calling Exit() will exit from GRUB
rather than from the kernel, but this is a tolerable side effect.
Signed-off-by: NArd Biesheuvel <ardb@kernel.org>
      3b8f44fc
    • A
      efi/libstub/x86: Make loaded_image protocol handling mixed mode safe · f7b85b33
      由 Ard Biesheuvel 提交于 
      Add the definitions and use the special wrapper so that the loaded_image
UEFI protocol can be safely used from mixed mode.
Signed-off-by: NArd Biesheuvel <ardb@kernel.org>
      f7b85b33
    • A
      efi/libstub: Take noinitrd cmdline argument into account for devpath initrd · 79d3219d
      由 Ard Biesheuvel 提交于 
      One of the advantages of using what basically amounts to a callback
interface into the bootloader for loading the initrd is that it provides
a natural place for the bootloader or firmware to measure the initrd
contents while they are being passed to the kernel.

Unfortunately, this is not a guarantee that the initrd will in fact be
loaded and its /init invoked by the kernel, since the command line may
contain the 'noinitrd' option, in which case the initrd is ignored, but
this will not be reflected in the PCR that covers the initrd measurement.

This could be addressed by measuring the command line as well, and
including that PCR in the attestation policy, but this locks down the
command line completely, which may be too restrictive.

So let's take the noinitrd argument into account in the stub, too. This
forces any PCR that covers the initrd to assume a different value when
noinitrd is passed, allowing an attestation policy to disregard the
command line if there is no need to take its measurement into account
for other reasons.

As Peter points out, this would still require the agent that takes the
measurements to measure a separator event into the PCR in question at
ExitBootServices() time, to prevent replay attacks using the known
measurement from the TPM log.

Cc: Peter Jones <pjones@redhat.com>
Signed-off-by: NArd Biesheuvel <ardb@kernel.org>
      79d3219d
    • A
      efi/libstub: Add support for loading the initrd from a device path · ec93fc37
      由 Ard Biesheuvel 提交于 
      There are currently two ways to specify the initrd to be passed to the
Linux kernel when booting via the EFI stub:
- it can be passed as a initrd= command line option when doing a pure PE
  boot (as opposed to the EFI handover protocol that exists for x86)
- otherwise, the bootloader or firmware can load the initrd into memory,
  and pass the address and size via the bootparams struct (x86) or
  device tree (ARM)

In the first case, we are limited to loading from the same file system
that the kernel was loaded from, and it is also problematic in a trusted
boot context, given that we cannot easily protect the command line from
tampering without either adding complicated white/blacklisting of boot
arguments or locking down the command line altogether.

In the second case, we force the bootloader to duplicate knowledge about
the boot protocol which is already encoded in the stub, and which may be
subject to change over time, e.g., bootparams struct definitions, memory
allocation/alignment requirements for the placement of the initrd etc etc.
In the ARM case, it also requires the bootloader to modify the hardware
description provided by the firmware, as it is passed in the same file.
On systems where the initrd is measured after loading, it creates a time
window where the initrd contents might be manipulated in memory before
handing over to the kernel.

Address these concerns by adding support for loading the initrd into
memory by invoking the EFI LoadFile2 protocol installed on a vendor
GUIDed device path that specifically designates a Linux initrd.
This addresses the above concerns, by putting the EFI stub in charge of
placement in memory and of passing the base and size to the kernel proper
(via whatever means it desires) while still leaving it up to the firmware
or bootloader to obtain the file contents, potentially from other file
systems than the one the kernel itself was loaded from. On platforms that
implement measured boot, it permits the firmware to take the measurement
right before the kernel actually consumes the contents.
Acked-by: NLaszlo Ersek <lersek@redhat.com>
Tested-by: NIlias Apalodimas <ilias.apalodimas@linaro.org>
Acked-by: NIlias Apalodimas <ilias.apalodimas@linaro.org>
Signed-off-by: NArd Biesheuvel <ardb@kernel.org>
      ec93fc37
    • A
      efi/libstub: Make the LoadFile EFI protocol accessible · 2931d526
      由 Ard Biesheuvel 提交于 
      Add the protocol definitions, GUIDs and mixed mode glue so that
the EFI loadfile protocol can be used from the stub. This will
be used in a future patch to load the initrd.
Signed-off-by: NArd Biesheuvel <ardb@kernel.org>
      2931d526
    • A
      efi/libstub: Expose LocateDevicePath boot service · abd26868
      由 Ard Biesheuvel 提交于 
      We will be adding support for loading the initrd from a GUIDed
device path in a subsequent patch, so update the prototype of
the LocateDevicePath() boot service to make it callable from
our code.
Signed-off-by: NArd Biesheuvel <ardb@kernel.org>
      abd26868
    • A
      efi/libstub: Take soft and hard memory limits into account for initrd loading · 31f5e546
      由 Ard Biesheuvel 提交于 
      On x86, the preferred load address of the initrd is still below 4 GB,
even though in some cases, we can cope with an initrd that is loaded
above that.

To simplify the code, and to make it more straightforward to introduce
other ways to load the initrd, pass the soft and hard memory limits at
the same time, and let the code handling the initrd= command line option
deal with this.
Signed-off-by: NArd Biesheuvel <ardb@kernel.org>
      31f5e546