[Question] Should retain 2M alignment if kernel image is bad aligned at entry or BSS overlaps?

Ard Biesheuvel ardb at kernel.org
Mon Feb 28 23:22:20 PST 2022


On Tue, 1 Mar 2022 at 07:50, Kefeng Wang <wangkefeng.wang at huawei.com> wrote:
>
> Hi Ard,Will and all maintainer,
>
> As commit 3a262423755b ("efi/libstub: arm64: Relax 2M alignment again
> for relocatable kernels") saids, a relocatable image does not need to
> be copied to a 2M aligned offset if it was loaded on a 64k boundary
> (for a 4 KB granule kernel) by EFI. But if there is some FIRMWARE BUG,
>
> 1) kernel image not aligned on 64k boundary
> or
> 2) Image BSS overlaps adjacent EFI memory region
>
> When kaslr is disabled(eg, EFI_RNG_PROTOCOL unavailable), it will leads
> KPTI forced ON after kernel image relocated, message shown below,
>
>    CPU features: kernel page table isolation forced ON by KASLR
>    ...
>    KASLR disabled due to lack of seed
>
> The KASLR don't enabled actually, and KPTI is forced enabled which could
> affect performance.
>

This message is misleading. If the alignment modulo 2M != 0, we still
have 5 bits of 'randomization', although these bits are probably
highly predictable on a given system.

> I found commit 7c116db24d94 ("efi/libstub/arm64: Retain 2MB kernel Image
> alignment if !KASLR") in v5.8, should we retain 2M alignment if kernel image
> is bad aligned at entry or BSS overlaps?
>

Personally, I think we're doing enough already to deal with Redhat's
broken out-of-tree GRUB/SHIM concoction, which is the primary reason
for these workarounds  IIRC.

You can already pass nokalsr on the kernel command line if you want to
avoid the downsides entirely, so as I understand it, this is mostly
about an unquantified performance gain on systems that use a broken
bootloader and lack the entropy source for a KASLR seed, but are not
able to put nokaslr on the command line?


>
> diff --git a/drivers/firmware/efi/libstub/arm64-stub.c
> b/drivers/firmware/efi/libstub/arm64-stub.c
> index 9cc556013d08..47ecd9b80db3 100644
> --- a/drivers/firmware/efi/libstub/arm64-stub.c
> +++ b/drivers/firmware/efi/libstub/arm64-stub.c
> @@ -87,6 +87,7 @@ efi_status_t handle_kernel_image(unsigned long
> *image_addr,
>   {
>          efi_status_t status;
>          unsigned long kernel_size, kernel_memsize = 0;
> +       bool need_2m_aligned = false;
>          u32 phys_seed = 0;
>
>          /*
> @@ -119,9 +120,11 @@ efi_status_t handle_kernel_image(unsigned long
> *image_addr,
>          if (image->image_base != _text)
>                  efi_err("FIRMWARE BUG: efi_loaded_image_t::image_base
> has bogus value\n");
>
> -       if (!IS_ALIGNED((u64)_text, SEGMENT_ALIGN))
> +       if (!IS_ALIGNED((u64)_text, SEGMENT_ALIGN)) {
> +               need_2m_aligned = true;
>                  efi_err("FIRMWARE BUG: kernel image not aligned on %dk
> boundary\n",
>                          SEGMENT_ALIGN >> 10);
> +       }
>
>          kernel_size = _edata - _text;
>          kernel_memsize = kernel_size + (_end - _edata);
> @@ -142,6 +145,7 @@ efi_status_t handle_kernel_image(unsigned long
> *image_addr,
>
>          if (status != EFI_SUCCESS) {
>                  if (!check_image_region((u64)_text, kernel_memsize)) {
> +                       need_2m_aligned = true;
>                          efi_err("FIRMWARE BUG: Image BSS overlaps
> adjacent EFI memory region\n");
>                  } else if (IS_ALIGNED((u64)_text, min_kimg_align)) {
>                          /*
> @@ -152,7 +156,8 @@ efi_status_t handle_kernel_image(unsigned long
> *image_addr,
>                          *reserve_size = 0;
>                          return EFI_SUCCESS;
>                  }
> -
> +               if (efi_nokaslr & need_2m_aligned)
> +                       min_kimg_align = MIN_KIMG_ALIGN;
>                  status = efi_allocate_pages_aligned(*reserve_size,
> reserve_addr,
>                                                      ULONG_MAX,
> min_kimg_align);



More information about the linux-arm-kernel mailing list