[6/7] efi: restrict arm/arm64 linux loader initrd placement

Message ID 20170612145341.3351-7-leif.lindholm@linaro.org
State New
Headers show
Series
  • efi: improved correctness, arm unification, and cleanup
Related show

Commit Message

Leif Lindholm June 12, 2017, 2:53 p.m.
The 32-bit arm Linux kernel is built as a zImage, which self-decompresses
down to near start of RAM. In order for an initrd/initramfs to be
accessible, it needs to be placed within the first ~768MB of RAM.
The initrd loader built into the kernel EFI stub restricts this down to
512MB for simplicity - so enable the same restriction in grub.

For arm64, the requirement is within a 1GB aligned 32GB window also
covering the (runtime) kernel image. Since the EFI stub loader itself
will attempt to relocate to near start of RAM, force initrd to be loaded
completely within the first 32GB of RAM.

Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org>

---
 grub-core/loader/arm64/linux.c | 39 ++++++++++++++++++++++++++++++++++++++-
 1 file changed, 38 insertions(+), 1 deletion(-)

-- 
2.11.0


_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Comments

Daniel Kiper July 27, 2017, 3:16 p.m. | #1
On Mon, Jun 12, 2017 at 03:53:40PM +0100, Leif Lindholm wrote:
> The 32-bit arm Linux kernel is built as a zImage, which self-decompresses

> down to near start of RAM. In order for an initrd/initramfs to be

> accessible, it needs to be placed within the first ~768MB of RAM.

> The initrd loader built into the kernel EFI stub restricts this down to

> 512MB for simplicity - so enable the same restriction in grub.

>

> For arm64, the requirement is within a 1GB aligned 32GB window also

> covering the (runtime) kernel image. Since the EFI stub loader itself

> will attempt to relocate to near start of RAM, force initrd to be loaded

> completely within the first 32GB of RAM.

>

> Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org>

> ---

>  grub-core/loader/arm64/linux.c | 39 ++++++++++++++++++++++++++++++++++++++-

>  1 file changed, 38 insertions(+), 1 deletion(-)

>

> diff --git a/grub-core/loader/arm64/linux.c b/grub-core/loader/arm64/linux.c

> index 8cd44230d..7e989c2b9 100644

> --- a/grub-core/loader/arm64/linux.c

> +++ b/grub-core/loader/arm64/linux.c

> @@ -35,6 +35,23 @@

>

>  GRUB_MOD_LICENSE ("GPLv3+");

>

> +/*

> + * 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.

> + *

> + * 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)

> +#endif

> +

>  static grub_dl_t my_mod;

>  static int loaded;

>

> @@ -194,6 +211,25 @@ grub_linux_unload (void)

>    return GRUB_ERR_NONE;

>  }

>

> +/*

> + * This function returns a pointer to a legally allocated initrd buffer,

> + * or NULL if unsuccessful

> + */

> +static void *

> +allocate_initrd_mem (int initrd_pages)

> +{

> +  grub_addr_t max_addr;

> +

> +  if (grub_efi_get_dram_base (&max_addr) != GRUB_ERR_NONE)

> +    return NULL;

> +

> +  max_addr += INITRD_MAX_ADDRESS_OFFSET - 1;


I do not understand this. Why do not pass simply INITRD_MAX_ADDRESS_OFFSET
instead of max_addr to grub_efi_allocate_pages_real()?

> +  return grub_efi_allocate_pages_real (max_addr, initrd_pages,

> +				       GRUB_EFI_ALLOCATE_MAX_ADDRESS,

> +				       GRUB_EFI_LOADER_DATA);

> +}


Daniel

_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Vladimir 'phcoder' Serbinenko July 27, 2017, 3:18 p.m. | #2
On Thu, Jul 27, 2017, 17:16 Daniel Kiper <dkiper@net-space.pl> wrote:

> On Mon, Jun 12, 2017 at 03:53:40PM +0100, Leif Lindholm wrote:

> > The 32-bit arm Linux kernel is built as a zImage, which self-decompresses

> > down to near start of RAM. In order for an initrd/initramfs to be

> > accessible, it needs to be placed within the first ~768MB of RAM.

> > The initrd loader built into the kernel EFI stub restricts this down to

> > 512MB for simplicity - so enable the same restriction in grub.

> >

> > For arm64, the requirement is within a 1GB aligned 32GB window also

> > covering the (runtime) kernel image. Since the EFI stub loader itself

> > will attempt to relocate to near start of RAM, force initrd to be loaded

> > completely within the first 32GB of RAM.

> >

> > Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org>

> > ---

> >  grub-core/loader/arm64/linux.c | 39

> ++++++++++++++++++++++++++++++++++++++-

> >  1 file changed, 38 insertions(+), 1 deletion(-)

> >

> > diff --git a/grub-core/loader/arm64/linux.c

> b/grub-core/loader/arm64/linux.c

> > index 8cd44230d..7e989c2b9 100644

> > --- a/grub-core/loader/arm64/linux.c

> > +++ b/grub-core/loader/arm64/linux.c

> > @@ -35,6 +35,23 @@

> >

> >  GRUB_MOD_LICENSE ("GPLv3+");

> >

> > +/*

> > + * 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.

> > + *

> > + * 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)

> > +#endif

> > +

> >  static grub_dl_t my_mod;

> >  static int loaded;

> >

> > @@ -194,6 +211,25 @@ grub_linux_unload (void)

> >    return GRUB_ERR_NONE;

> >  }

> >

> > +/*

> > + * This function returns a pointer to a legally allocated initrd buffer,

> > + * or NULL if unsuccessful

> > + */

> > +static void *

> > +allocate_initrd_mem (int initrd_pages)

> > +{

> > +  grub_addr_t max_addr;

> > +

> > +  if (grub_efi_get_dram_base (&max_addr) != GRUB_ERR_NONE)

> > +    return NULL;

> > +

> > +  max_addr += INITRD_MAX_ADDRESS_OFFSET - 1;

>

> I do not understand this. Why do not pass simply INITRD_MAX_ADDRESS_OFFSET

> instead of max_addr to grub_efi_allocate_pages_real()?

>

On ARM it's common for RAM to start at address different from 0

>

> > +  return grub_efi_allocate_pages_real (max_addr, initrd_pages,

> > +                                    GRUB_EFI_ALLOCATE_MAX_ADDRESS,

> > +                                    GRUB_EFI_LOADER_DATA);

> > +}

>

> Daniel

>

> _______________________________________________

> Grub-devel mailing list

> Grub-devel@gnu.org

> https://lists.gnu.org/mailman/listinfo/grub-devel

>
_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Daniel Kiper July 27, 2017, 3:40 p.m. | #3
On Thu, Jul 27, 2017 at 03:18:16PM +0000, Vladimir 'phcoder' Serbinenko wrote:
> On Thu, Jul 27, 2017, 17:16 Daniel Kiper <dkiper@net-space.pl> wrote:

> > On Mon, Jun 12, 2017 at 03:53:40PM +0100, Leif Lindholm wrote:

> > > The 32-bit arm Linux kernel is built as a zImage, which self-decompresses

> > > down to near start of RAM. In order for an initrd/initramfs to be

> > > accessible, it needs to be placed within the first ~768MB of RAM.

> > > The initrd loader built into the kernel EFI stub restricts this down to

> > > 512MB for simplicity - so enable the same restriction in grub.

> > >

> > > For arm64, the requirement is within a 1GB aligned 32GB window also

> > > covering the (runtime) kernel image. Since the EFI stub loader itself

> > > will attempt to relocate to near start of RAM, force initrd to be loaded

> > > completely within the first 32GB of RAM.

> > >

> > > Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org>

> > > ---

> > >  grub-core/loader/arm64/linux.c | 39

> > ++++++++++++++++++++++++++++++++++++++-

> > >  1 file changed, 38 insertions(+), 1 deletion(-)

> > >

> > > diff --git a/grub-core/loader/arm64/linux.c

> > b/grub-core/loader/arm64/linux.c

> > > index 8cd44230d..7e989c2b9 100644

> > > --- a/grub-core/loader/arm64/linux.c

> > > +++ b/grub-core/loader/arm64/linux.c

> > > @@ -35,6 +35,23 @@

> > >

> > >  GRUB_MOD_LICENSE ("GPLv3+");

> > >

> > > +/*

> > > + * 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.

> > > + *

> > > + * 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)

> > > +#endif

> > > +

> > >  static grub_dl_t my_mod;

> > >  static int loaded;

> > >

> > > @@ -194,6 +211,25 @@ grub_linux_unload (void)

> > >    return GRUB_ERR_NONE;

> > >  }

> > >

> > > +/*

> > > + * This function returns a pointer to a legally allocated initrd buffer,

> > > + * or NULL if unsuccessful

> > > + */

> > > +static void *

> > > +allocate_initrd_mem (int initrd_pages)

> > > +{

> > > +  grub_addr_t max_addr;

> > > +

> > > +  if (grub_efi_get_dram_base (&max_addr) != GRUB_ERR_NONE)

> > > +    return NULL;

> > > +

> > > +  max_addr += INITRD_MAX_ADDRESS_OFFSET - 1;

> >

> > I do not understand this. Why do not pass simply INITRD_MAX_ADDRESS_OFFSET

> > instead of max_addr to grub_efi_allocate_pages_real()?

> >

> On ARM it's common for RAM to start at address different from 0


OK, but, AIUI we have to load initrd no higher than INITRD_MAX_ADDRESS_OFFSET.
So, we do not care where the region starts. We care where region ends.
Am I missing something?

Daniel

_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Vladimir 'phcoder' Serbinenko July 27, 2017, 3:41 p.m. | #4
On Thu, Jul 27, 2017, 17:40 Daniel Kiper <dkiper@net-space.pl> wrote:

> On Thu, Jul 27, 2017 at 03:18:16PM +0000, Vladimir 'phcoder' Serbinenko

> wrote:

> > On Thu, Jul 27, 2017, 17:16 Daniel Kiper <dkiper@net-space.pl> wrote:

> > > On Mon, Jun 12, 2017 at 03:53:40PM +0100, Leif Lindholm wrote:

> > > > The 32-bit arm Linux kernel is built as a zImage, which

> self-decompresses

> > > > down to near start of RAM. In order for an initrd/initramfs to be

> > > > accessible, it needs to be placed within the first ~768MB of RAM.

> > > > The initrd loader built into the kernel EFI stub restricts this down

> to

> > > > 512MB for simplicity - so enable the same restriction in grub.

> > > >

> > > > For arm64, the requirement is within a 1GB aligned 32GB window also

> > > > covering the (runtime) kernel image. Since the EFI stub loader itself

> > > > will attempt to relocate to near start of RAM, force initrd to be

> loaded

> > > > completely within the first 32GB of RAM.

> > > >

> > > > Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org>

> > > > ---

> > > >  grub-core/loader/arm64/linux.c | 39

> > > ++++++++++++++++++++++++++++++++++++++-

> > > >  1 file changed, 38 insertions(+), 1 deletion(-)

> > > >

> > > > diff --git a/grub-core/loader/arm64/linux.c

> > > b/grub-core/loader/arm64/linux.c

> > > > index 8cd44230d..7e989c2b9 100644

> > > > --- a/grub-core/loader/arm64/linux.c

> > > > +++ b/grub-core/loader/arm64/linux.c

> > > > @@ -35,6 +35,23 @@

> > > >

> > > >  GRUB_MOD_LICENSE ("GPLv3+");

> > > >

> > > > +/*

> > > > + * 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.

> > > > + *

> > > > + * 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)

> > > > +#endif

> > > > +

> > > >  static grub_dl_t my_mod;

> > > >  static int loaded;

> > > >

> > > > @@ -194,6 +211,25 @@ grub_linux_unload (void)

> > > >    return GRUB_ERR_NONE;

> > > >  }

> > > >

> > > > +/*

> > > > + * This function returns a pointer to a legally allocated initrd

> buffer,

> > > > + * or NULL if unsuccessful

> > > > + */

> > > > +static void *

> > > > +allocate_initrd_mem (int initrd_pages)

> > > > +{

> > > > +  grub_addr_t max_addr;

> > > > +

> > > > +  if (grub_efi_get_dram_base (&max_addr) != GRUB_ERR_NONE)

> > > > +    return NULL;

> > > > +

> > > > +  max_addr += INITRD_MAX_ADDRESS_OFFSET - 1;

> > >

> > > I do not understand this. Why do not pass simply

> INITRD_MAX_ADDRESS_OFFSET

> > > instead of max_addr to grub_efi_allocate_pages_real()?

> > >

> > On ARM it's common for RAM to start at address different from 0

>

> OK, but, AIUI we have to load initrd no higher than

> INITRD_MAX_ADDRESS_OFFSET.

> So, we do not care where the region starts. We care where region ends.

> Am I missing something?

>

The limit is relative to the start of RAM.

>

> Daniel

>
_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Daniel Kiper July 27, 2017, 4:12 p.m. | #5
On Thu, Jul 27, 2017 at 03:41:25PM +0000, Vladimir 'phcoder' Serbinenko wrote:
> On Thu, Jul 27, 2017, 17:40 Daniel Kiper <dkiper@net-space.pl> wrote:

> > On Thu, Jul 27, 2017 at 03:18:16PM +0000, Vladimir 'phcoder' Serbinenko

> > wrote:

> > > On Thu, Jul 27, 2017, 17:16 Daniel Kiper <dkiper@net-space.pl> wrote:

> > > > On Mon, Jun 12, 2017 at 03:53:40PM +0100, Leif Lindholm wrote:

> > > > > The 32-bit arm Linux kernel is built as a zImage, which

> > self-decompresses

> > > > > down to near start of RAM. In order for an initrd/initramfs to be

> > > > > accessible, it needs to be placed within the first ~768MB of RAM.

> > > > > The initrd loader built into the kernel EFI stub restricts this down

> > to

> > > > > 512MB for simplicity - so enable the same restriction in grub.

> > > > >

> > > > > For arm64, the requirement is within a 1GB aligned 32GB window also

> > > > > covering the (runtime) kernel image. Since the EFI stub loader itself

> > > > > will attempt to relocate to near start of RAM, force initrd to be

> > loaded

> > > > > completely within the first 32GB of RAM.

> > > > >

> > > > > Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org>

> > > > > ---

> > > > >  grub-core/loader/arm64/linux.c | 39

> > > > ++++++++++++++++++++++++++++++++++++++-

> > > > >  1 file changed, 38 insertions(+), 1 deletion(-)

> > > > >

> > > > > diff --git a/grub-core/loader/arm64/linux.c

> > > > b/grub-core/loader/arm64/linux.c

> > > > > index 8cd44230d..7e989c2b9 100644

> > > > > --- a/grub-core/loader/arm64/linux.c

> > > > > +++ b/grub-core/loader/arm64/linux.c

> > > > > @@ -35,6 +35,23 @@

> > > > >

> > > > >  GRUB_MOD_LICENSE ("GPLv3+");

> > > > >

> > > > > +/*

> > > > > + * 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.

> > > > > + *

> > > > > + * 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)

> > > > > +#endif

> > > > > +

> > > > >  static grub_dl_t my_mod;

> > > > >  static int loaded;

> > > > >

> > > > > @@ -194,6 +211,25 @@ grub_linux_unload (void)

> > > > >    return GRUB_ERR_NONE;

> > > > >  }

> > > > >

> > > > > +/*

> > > > > + * This function returns a pointer to a legally allocated initrd

> > buffer,

> > > > > + * or NULL if unsuccessful

> > > > > + */

> > > > > +static void *

> > > > > +allocate_initrd_mem (int initrd_pages)

> > > > > +{

> > > > > +  grub_addr_t max_addr;

> > > > > +

> > > > > +  if (grub_efi_get_dram_base (&max_addr) != GRUB_ERR_NONE)

> > > > > +    return NULL;

> > > > > +

> > > > > +  max_addr += INITRD_MAX_ADDRESS_OFFSET - 1;

> > > >

> > > > I do not understand this. Why do not pass simply

> > INITRD_MAX_ADDRESS_OFFSET

> > > > instead of max_addr to grub_efi_allocate_pages_real()?

> > > >

> > > On ARM it's common for RAM to start at address different from 0

> >

> > OK, but, AIUI we have to load initrd no higher than

> > INITRD_MAX_ADDRESS_OFFSET.

> > So, we do not care where the region starts. We care where region ends.

> > Am I missing something?

> >

> The limit is relative to the start of RAM.


OK, then it make sense. Thanks for clarification. I would just
ask for a comment to avoid reader confusion.

Daniel

_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Leif Lindholm July 28, 2017, 6:44 p.m. | #6
On Thu, Jul 27, 2017 at 06:12:42PM +0200, Daniel Kiper wrote:
> On Thu, Jul 27, 2017 at 03:41:25PM +0000, Vladimir 'phcoder' Serbinenko wrote:

> > On Thu, Jul 27, 2017, 17:40 Daniel Kiper <dkiper@net-space.pl> wrote:

> > > On Thu, Jul 27, 2017 at 03:18:16PM +0000, Vladimir 'phcoder' Serbinenko

> > > wrote:

> > > > On Thu, Jul 27, 2017, 17:16 Daniel Kiper <dkiper@net-space.pl> wrote:

> > > > > On Mon, Jun 12, 2017 at 03:53:40PM +0100, Leif Lindholm wrote:

> > > > > > The 32-bit arm Linux kernel is built as a zImage, which

> > > self-decompresses

> > > > > > down to near start of RAM. In order for an initrd/initramfs to be

> > > > > > accessible, it needs to be placed within the first ~768MB of RAM.

> > > > > > The initrd loader built into the kernel EFI stub restricts this down

> > > to

> > > > > > 512MB for simplicity - so enable the same restriction in grub.

> > > > > >

> > > > > > For arm64, the requirement is within a 1GB aligned 32GB window also

> > > > > > covering the (runtime) kernel image. Since the EFI stub loader itself

> > > > > > will attempt to relocate to near start of RAM, force initrd to be

> > > loaded

> > > > > > completely within the first 32GB of RAM.

> > > > > >

> > > > > > Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org>

> > > > > > ---

> > > > > >  grub-core/loader/arm64/linux.c | 39

> > > > > ++++++++++++++++++++++++++++++++++++++-

> > > > > >  1 file changed, 38 insertions(+), 1 deletion(-)

> > > > > >

> > > > > > diff --git a/grub-core/loader/arm64/linux.c

> > > > > b/grub-core/loader/arm64/linux.c

> > > > > > index 8cd44230d..7e989c2b9 100644

> > > > > > --- a/grub-core/loader/arm64/linux.c

> > > > > > +++ b/grub-core/loader/arm64/linux.c

> > > > > > @@ -35,6 +35,23 @@

> > > > > >

> > > > > >  GRUB_MOD_LICENSE ("GPLv3+");

> > > > > >

> > > > > > +/*

> > > > > > + * 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.

> > > > > > + *

> > > > > > + * 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)

> > > > > > +#endif

> > > > > > +

> > > > > >  static grub_dl_t my_mod;

> > > > > >  static int loaded;

> > > > > >

> > > > > > @@ -194,6 +211,25 @@ grub_linux_unload (void)

> > > > > >    return GRUB_ERR_NONE;

> > > > > >  }

> > > > > >

> > > > > > +/*

> > > > > > + * This function returns a pointer to a legally allocated initrd

> > > buffer,

> > > > > > + * or NULL if unsuccessful

> > > > > > + */

> > > > > > +static void *

> > > > > > +allocate_initrd_mem (int initrd_pages)

> > > > > > +{

> > > > > > +  grub_addr_t max_addr;

> > > > > > +

> > > > > > +  if (grub_efi_get_dram_base (&max_addr) != GRUB_ERR_NONE)

> > > > > > +    return NULL;

> > > > > > +

> > > > > > +  max_addr += INITRD_MAX_ADDRESS_OFFSET - 1;

> > > > >

> > > > > I do not understand this. Why do not pass simply

> > > INITRD_MAX_ADDRESS_OFFSET

> > > > > instead of max_addr to grub_efi_allocate_pages_real()?

> > > > >

> > > > On ARM it's common for RAM to start at address different from 0

> > >

> > > OK, but, AIUI we have to load initrd no higher than

> > > INITRD_MAX_ADDRESS_OFFSET.

> > > So, we do not care where the region starts. We care where region ends.

> > > Am I missing something?

> > >

> > The limit is relative to the start of RAM.

> 

> OK, then it make sense. Thanks for clarification. I would just

> ask for a comment to avoid reader confusion.


Would moving this function next to the comment block this patch adds
to the top of the file be sufficient?

/
    Leif

_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel

Patch hide | download patch | download mbox

diff --git a/grub-core/loader/arm64/linux.c b/grub-core/loader/arm64/linux.c
index 8cd44230d..7e989c2b9 100644
--- a/grub-core/loader/arm64/linux.c
+++ b/grub-core/loader/arm64/linux.c
@@ -35,6 +35,23 @@ 
 
 GRUB_MOD_LICENSE ("GPLv3+");
 
+/*
+ * 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.
+ *
+ * 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)
+#endif
+
 static grub_dl_t my_mod;
 static int loaded;
 
@@ -194,6 +211,25 @@  grub_linux_unload (void)
   return GRUB_ERR_NONE;
 }
 
+/*
+ * This function returns a pointer to a legally allocated initrd buffer,
+ * or NULL if unsuccessful
+ */
+static void *
+allocate_initrd_mem (int initrd_pages)
+{
+  grub_addr_t max_addr;
+
+  if (grub_efi_get_dram_base (&max_addr) != GRUB_ERR_NONE)
+    return NULL;
+
+  max_addr += INITRD_MAX_ADDRESS_OFFSET - 1;
+
+  return grub_efi_allocate_pages_real (max_addr, initrd_pages,
+				       GRUB_EFI_ALLOCATE_MAX_ADDRESS,
+				       GRUB_EFI_LOADER_DATA);
+}
+
 static grub_err_t
 grub_cmd_initrd (grub_command_t cmd __attribute__ ((unused)),
 		 int argc, char *argv[])
@@ -222,7 +258,8 @@  grub_cmd_initrd (grub_command_t cmd __attribute__ ((unused)),
   grub_dprintf ("linux", "Loading initrd\n");
 
   initrd_pages = (GRUB_EFI_BYTES_TO_PAGES (initrd_size));
-  initrd_mem = grub_efi_allocate_pages (0, initrd_pages);
+  initrd_mem = allocate_initrd_mem (initrd_pages);
+
   if (!initrd_mem)
     {
       grub_error (GRUB_ERR_OUT_OF_MEMORY, N_("out of memory"));