Skip to content
  1. Feb 24, 2020
  3. Feb 23, 2020
    • Ard Biesheuvel's avatar
      efi/libstub/x86: Avoid overflowing code32_start on PE entry · 04a7d0e1
      Ard Biesheuvel authored 
      

When using the native PE entry point (as opposed to the EFI handover
protocol entry point that is used more widely), we set code32_start,
which is a 32-bit wide field, to the effective symbol address of
startup_32, which could overflow given that the EFI loader may have
located the running image anywhere in memory, and we haven't reached
the point yet where we relocate ourselves.

Since we relocate ourselves if code32_start != pref_address, this
isn't likely to lead to problems in practice, given how unlikely
it is that the truncated effective address of startup_32 happens
to equal pref_address. But it is better to defer the assignment
of code32_start to after the relocation, when it is guaranteed to
fit.

While at it, move the call to efi_relocate_kernel() to an earlier
stage so it is more likely that our preferred offset in memory has
not been occupied by other memory allocations done in the mean time.

Signed-off-by: default avatarArd Biesheuvel <ardb@kernel.org>
      04a7d0e1
    • Ard Biesheuvel's avatar
      efi/libstub/x86: Remove pointless zeroing of apm_bios_info · e6d832ea
      Ard Biesheuvel authored 
      

We have some code in the EFI stub entry point that takes the address
of the apm_bios_info struct in the newly allocated and zeroed out
boot_params structure, only to zero it out again. This is pointless
so remove it.

Signed-off-by: default avatarArd Biesheuvel <ardb@kernel.org>
      e6d832ea
    • Gustavo A. R. Silva's avatar
      efi/apple-properties: Replace zero-length array with flexible-array member · 3b9274ea
      Gustavo A. R. Silva authored 
      The current codebase makes use of the zero-length array language
extension to the C90 standard, but the preferred mechanism to declare
variable-length types such as these ones is a flexible array member[1][2],
introduced in C99:

struct foo {
        int stuff;
        struct boo array[];
};

By making use of the mechanism above, we will get a compiler warning
in case the flexible array does not occur last in the structure, which
will help us prevent some kind of undefined behavior bugs from being
inadvertenly introduced[3] to the codebase from now on.

This issue was found with the help of Coccinelle.

[1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
[2] https://github.com/KSPP/linux/issues/21


[3] commit 76497732 ("cxgb3/l2t: Fix undefined behaviour")

Signed-off-by: default avatarGustavo A. R. Silva <gustavo@embeddedor.com>
Link: https://lore.kernel.org/r/20200211231421.GA15697@embeddedor


Signed-off-by: default avatarArd Biesheuvel <ardb@kernel.org>
      3b9274ea
    • Ard Biesheuvel's avatar
      efi/libstub/arm64: Use 1:1 mapping of RT services if property table exists · b92165d2
      Ard Biesheuvel authored 
      

The UEFI spec defines (and deprecates) a misguided and shortlived
memory protection feature that is based on splitting memory regions
covering PE/COFF executables into separate code and data regions,
without annotating them as belonging to the same executable image.
When the OS assigns the virtual addresses of these regions, it may
move them around arbitrarily, without taking into account that the
PE/COFF code sections may contain relative references into the data
sections, which means the relative placement of these segments has
to be preserved or the executable image will be corrupted.

The original workaround on arm64 was to ensure that adjacent regions
of the same type were mapped adjacently in the virtual mapping, but
this requires sorting of the memory map, which we would prefer to
avoid.

Considering that the native physical mapping of the PE/COFF images
does not suffer from this issue, let's preserve it at runtime, and
install it as the virtual mapping as well.

Signed-off-by: default avatarArd Biesheuvel <ardb@kernel.org>
      b92165d2