grub-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Leif Lindholm
Subject: Re: [PATCH 6/7] efi: restrict arm/arm64 linux loader initrd placement
Date: Fri, 28 Jul 2017 19:44:15 +0100
User-agent: Mutt/1.5.23 (2014-03-12)

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 <address@hidden> wrote:
> > > On Thu, Jul 27, 2017 at 03:18:16PM +0000, Vladimir 'phcoder' Serbinenko
> > > wrote:
> > > > On Thu, Jul 27, 2017, 17:16 Daniel Kiper <address@hidden> 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 <address@hidden>
> > > > > > ---
> > > > > >  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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]