Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 27 9月, 2022 2 次提交
    • A
      efi: libstub: unify initrd loading between architectures · f4dc7fff
      由 Ard Biesheuvel 提交于 
      Use a EFI configuration table to pass the initrd to the core kernel,
instead of per-arch methods. This cleans up the code considerably, and
should make it easier for architectures to get rid of their reliance on
DT for doing EFI boot in the future.
Signed-off-by: NArd Biesheuvel <ardb@kernel.org>
      f4dc7fff
    • A
      efi: libstub: simplify efi_get_memory_map() and struct efi_boot_memmap · eab31265
      由 Ard Biesheuvel 提交于 
      Currently, struct efi_boot_memmap is a struct that is passed around
between callers of efi_get_memory_map() and the users of the resulting
data, and which carries pointers to various variables whose values are
provided by the EFI GetMemoryMap() boot service.

This is overly complex, and it is much easier to carry these values in
the struct itself. So turn the struct into one that carries these data
items directly, including a flex array for the variable number of EFI
memory descriptors that the boot service may return.
Signed-off-by: NArd Biesheuvel <ardb@kernel.org>
      eab31265
  3. 01 6月, 2022 1 次提交
    • A
      efi/x86: libstub: Make DXE calls mixed mode safe · 31f1a0ed
      由 Ard Biesheuvel 提交于 
      The newly added DXE calls use 64-bit quantities, which means we need to
marshall them explicitly when running in mixed mode. Currently, we get
away without it because we just bail when GetMemorySpaceDescriptor()
fails, which is guaranteed to happen due to the function argument mixup.

Let's fix this properly, though, by defining the macros that describe
how to marshall the arguments. While at it, drop an incorrect cast on a
status variable.
Signed-off-by: NArd Biesheuvel <ardb@kernel.org>
      31f1a0ed
  5. 03 5月, 2022 2 次提交
  7. 22 11月, 2021 1 次提交
  9. 26 10月, 2020 1 次提交
  11. 26 6月, 2020 2 次提交
    • A
      efi/x86: Only copy upto the end of setup_header · 59476f80
      由 Arvind Sankar 提交于 
      When copying the setup_header into the boot_params buffer, only the data
that is actually part of the setup_header should be copied.

efi_pe_entry() currently copies the entire second sector, which
initializes some of the fields in boot_params beyond the setup_header
with garbage (i.e. part of the real-mode boot code gets copied into
those fields).

This does not cause any issues currently because the fields that are
overwritten are padding, BIOS EDD information that won't get used, and
the E820 table which will get properly filled in later.

Fix this to only copy data that is actually part of the setup_header
structure.
Signed-off-by: NArvind Sankar <nivedita@alum.mit.edu>
Signed-off-by: NArd Biesheuvel <ardb@kernel.org>
      59476f80
    • A
      efi/x86: Remove unused variables · 0bda49f3
      由 Arvind Sankar 提交于 
      Commit

  987053a3 ("efi/x86: Move command-line initrd loading to efi_main")

made the ramdisk_addr/ramdisk_size variables in efi_pe_entry unused, but
neglected to delete them.

Delete these unused variables.
Signed-off-by: NArvind Sankar <nivedita@alum.mit.edu>
Signed-off-by: NArd Biesheuvel <ardb@kernel.org>
      0bda49f3
  13. 28 5月, 2020 1 次提交
  15. 22 5月, 2020 1 次提交
  17. 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
  19. 01 5月, 2020 7 次提交
  21. 24 4月, 2020 4 次提交
  23. 14 4月, 2020 3 次提交
  25. 08 3月, 2020 6 次提交
  27. 24 2月, 2020 8 次提交
    • A
      efi/x86: Implement mixed mode boot without the handover protocol · 17054f49
      由 Ard Biesheuvel 提交于 
      Add support for booting 64-bit x86 kernels from 32-bit firmware running
on 64-bit capable CPUs without requiring the bootloader to implement
the EFI handover protocol or allocate the setup block, etc etc, all of
which can be done by the stub itself, using code that already exists.

Instead, create an ordinary EFI application entrypoint but implemented
in 32-bit code [so that it can be invoked by 32-bit firmware], and stash
the address of this 32-bit entrypoint in the .compat section where the
bootloader can find it.

Note that we use the setup block embedded in the binary to go through
startup_32(), but it gets reallocated and copied in efi_pe_entry(),
using the same code that runs when the x86 kernel is booted in EFI
mode from native firmware. This requires the loaded image protocol to
be installed on the kernel image's EFI handle, and point to the kernel
image itself and not to its loader. This, in turn, requires the
bootloader to use the LoadImage() boot service to load the 64-bit
image from 32-bit firmware, which is in fact supported by firmware
based on EDK2. (Only StartImage() will fail, and instead, the newly
added entrypoint needs to be invoked)
Signed-off-by: NArd Biesheuvel <ardb@kernel.org>
      17054f49
    • 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: Clean up command line parsing routine · 91d150c0
      由 Ard Biesheuvel 提交于 
      We currently parse the command non-destructively, to avoid having to
allocate memory for a copy before passing it to the standard parsing
routines that are used by the core kernel, and which modify the input
to delineate the parsed tokens with NUL characters.

Instead, we call strstr() and strncmp() to go over the input multiple
times, and match prefixes rather than tokens, which implies that we
would match, e.g., 'nokaslrfoo' in the stub and disable KASLR, while
the kernel would disregard the option and run with KASLR enabled.

In order to avoid having to reason about whether and how this behavior
may be abused, let's clean up the parsing routines, and rebuild them
on top of the existing helpers.
Signed-off-by: NArd Biesheuvel <ardb@kernel.org>
      91d150c0
    • 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
    • A
      efi/libstub: Rewrite file I/O routine · 9302c1bb
      由 Ard Biesheuvel 提交于 
      The file I/O routine that is used to load initrd or dtb files from
the EFI system partition suffers from a few issues:
- it converts the u8[] command line back to a UTF-16 string, which is
  pointless since we only handle initrd or dtb arguments provided via
  the loaded image protocol anyway, which is where we got the UTF-16[]
  command line from in the first place when booting via the PE entry
  point,
- in the far majority of cases, only a single initrd= option is present,
  but it optimizes for multiple options, by going over the command line
  twice, allocating heap buffers for dynamically sized arrays, etc.
- the coding style is hard to follow, with few comments, and all logic
  including string parsing etc all combined in a single routine.

Let's fix this by rewriting most of it, based on the idea that in the
case of multiple initrds, we can just allocate a new, bigger buffer
and copy over the data before freeing the old one.
Signed-off-by: NArd Biesheuvel <ardb@kernel.org>
      9302c1bb