[RFC PATCH] efi: Add build error for new EFI arches that do not specify INITRD_MAX_ADDRESS_OFFSET

[RFC PATCH] efi: Add build error for new EFI arches that do not specify INITRD_MAX_ADDRESS_OFFSET

[Glenn Washburn]

Non-x86 EFI architectures were using a INITRD_MAX_ADDRESS_OFFSET defined
by the aarch64 architecture. This seems to generally work, as in no one
has complained about this. However, the code is misleading. Architectures
should explicitly set INITRD_MAX_ADDRESS_OFFSET. To avoid breaking current
EFI architectures, set to GRUB_EFI_MAX_USABLE_ADDRESS, effectively allowing
the entire address range. New architectures will fail to build until this
macro is set.

Signed-off-by: Glenn Washburn <development@efficientek.com>
---
My reading of a reply on the list[1] is that RISCV has no limit for the
initrd. But I think it would be good to point to documentation describing
limitations as in the ARM comments.

Glenn

[1] https://lists.gnu.org/archive/html/grub-devel/2021-07/msg00001.html
---
 grub-core/loader/efi/linux.c | 18 ++++++++++++++----
 1 file changed, 14 insertions(+), 4 deletions(-)

diff --git a/grub-core/loader/efi/linux.c b/grub-core/loader/efi/linux.c
index ab8fb35adb05..8f5460ba11e0 100644
--- a/grub-core/loader/efi/linux.c
+++ b/grub-core/loader/efi/linux.c
@@ -28,6 +28,7 @@
 #include <grub/efi/efi.h>
 #include <grub/efi/fdtload.h>
 #include <grub/efi/memory.h>
+#include <grub/cpu/efi/memory.h>
 #include <grub/efi/pe32.h>
 #include <grub/efi/sb.h>
 #include <grub/i18n.h>
@@ -290,21 +291,30 @@ grub_linux_unload (void)
 }
 
 #if !defined(__i386__) && !defined(__x86_64__)
+#if defined (__arm__)
 /*
  * As per linux/Documentation/arm/Booting
  * ARM initrd needs to be covered by kernel linear mapping,
  * so place it in the first 512MB of DRAM.
- *
+ */
+#define INITRD_MAX_ADDRESS_OFFSET (512U * 1024 * 1024)
+#elif defined (__aarch64__)
+/*
  * As per linux/Documentation/arm64/booting.txt
  * ARM64 initrd needs to be contained entirely within a 1GB aligned window
  * of up to 32GB of size that covers the kernel image as well.
  * Since the EFI stub loader will attempt to load the kernel near start of
  * RAM, place the buffer in the first 32GB of RAM.
  */
-#ifdef __arm__
-#define INITRD_MAX_ADDRESS_OFFSET (512U * 1024 * 1024)
-#else /* __aarch64__ */
 #define INITRD_MAX_ADDRESS_OFFSET (32ULL * 1024 * 1024 * 1024)
+#elif defined (__ia64__) || defined (__riscv) || defined (__loongarch_lp64)
+/*
+ * There has been no investigation into constraints on the initrd address
+ * for these platforms. Allow all the available address space for now.
+ */
+#define INITRD_MAX_ADDRESS_OFFSET GRUB_EFI_MAX_USABLE_ADDRESS
+#else
+#error "Unknown INITRD_MAX_ADDRESS_OFFSET for architecture"
 #endif
 
 /*
-- 
2.34.1

Re: [RFC PATCH] efi: Add build error for new EFI arches that do not specify INITRD_MAX_ADDRESS_OFFSET

[Ard Biesheuvel]

On Mon, 10 Jul 2023 at 20:33, Glenn Washburn
<development@efficientek.com> wrote:
>
> Non-x86 EFI architectures were using a INITRD_MAX_ADDRESS_OFFSET defined
> by the aarch64 architecture. This seems to generally work, as in no one
> has complained about this. However, the code is misleading. Architectures
> should explicitly set INITRD_MAX_ADDRESS_OFFSET. To avoid breaking current
> EFI architectures, set to GRUB_EFI_MAX_USABLE_ADDRESS, effectively allowing
> the entire address range. New architectures will fail to build until this
> macro is set.
>
> Signed-off-by: Glenn Washburn <development@efficientek.com>
> ---
> My reading of a reply on the list[1] is that RISCV has no limit for the
> initrd. But I think it would be good to point to documentation describing
> limitations as in the ARM comments.
>

AIUI, RISC-V may support 3, 4 or 5 levels of paging, and it may depend
on the kernel configuration which of those are actually supported.
This may affect the addressability of the linear region, and given
EDK2's tendency to allocate from the top of memory downwards, imposing
no limit at all may result allocations that the kernel cannot access.

That said, is this even an issue for RISC-V? As far as I remember, the
LoadFile2 based initrd loading method was supported from the
beginning, and so this is mostly dead code anyway on RISC-V, and
perhaps it would be better to simply disable it.



>
> [1] https://lists.gnu.org/archive/html/grub-devel/2021-07/msg00001.html
> ---
>  grub-core/loader/efi/linux.c | 18 ++++++++++++++----
>  1 file changed, 14 insertions(+), 4 deletions(-)
>
> diff --git a/grub-core/loader/efi/linux.c b/grub-core/loader/efi/linux.c
> index ab8fb35adb05..8f5460ba11e0 100644
> --- a/grub-core/loader/efi/linux.c
> +++ b/grub-core/loader/efi/linux.c
> @@ -28,6 +28,7 @@
>  #include <grub/efi/efi.h>
>  #include <grub/efi/fdtload.h>
>  #include <grub/efi/memory.h>
> +#include <grub/cpu/efi/memory.h>
>  #include <grub/efi/pe32.h>
>  #include <grub/efi/sb.h>
>  #include <grub/i18n.h>
> @@ -290,21 +291,30 @@ grub_linux_unload (void)
>  }
>
>  #if !defined(__i386__) && !defined(__x86_64__)
> +#if defined (__arm__)
>  /*
>   * As per linux/Documentation/arm/Booting
>   * ARM initrd needs to be covered by kernel linear mapping,
>   * so place it in the first 512MB of DRAM.
> - *
> + */
> +#define INITRD_MAX_ADDRESS_OFFSET (512U * 1024 * 1024)
> +#elif defined (__aarch64__)
> +/*
>   * As per linux/Documentation/arm64/booting.txt
>   * ARM64 initrd needs to be contained entirely within a 1GB aligned window
>   * of up to 32GB of size that covers the kernel image as well.
>   * Since the EFI stub loader will attempt to load the kernel near start of
>   * RAM, place the buffer in the first 32GB of RAM.
>   */
> -#ifdef __arm__
> -#define INITRD_MAX_ADDRESS_OFFSET (512U * 1024 * 1024)
> -#else /* __aarch64__ */
>  #define INITRD_MAX_ADDRESS_OFFSET (32ULL * 1024 * 1024 * 1024)
> +#elif defined (__ia64__) || defined (__riscv) || defined (__loongarch_lp64)
> +/*
> + * There has been no investigation into constraints on the initrd address
> + * for these platforms. Allow all the available address space for now.
> + */
> +#define INITRD_MAX_ADDRESS_OFFSET GRUB_EFI_MAX_USABLE_ADDRESS
> +#else
> +#error "Unknown INITRD_MAX_ADDRESS_OFFSET for architecture"
>  #endif
>
>  /*
> --
> 2.34.1
>