Re: initrd loading, max size, addr_min, and page_align

[Andrei Borzenkov <arvidjaar@gmail.com>]

В Thu, 5 Feb 2015 21:55:54 +0000
Eric Ewanco <Eric.Ewanco@genband.com> пишет:

> 
> Background: I need to use a really large initrd for x86_64 (Linux 3.4.47), and I'm near the limit, so I'm studying grub-core/loader/i386/linux.c to find out the whys and wherefores of the GRUB 2.00 size limit.

GRUB 2.00 is way too old.

> 
> In the process of doing this I noticed a strange behavior.  The code has a ceiling (addr_max) and a floor (addr_min) for the initrd.  The initrd is loaded high, so that it ends at the ceiling and grows toward the floor as the size of the initrd increases.  The odd behavior, or at least the one that I don't understand, is that the floor grows upward toward the ceiling at the same time.  The lines in question:
> 
>   addr_min = (grub_addr_t) prot_mode_target + prot_init_space
>              + page_align (size);
> 

This code is different in current GIT.

>   /* Put the initrd as high as possible, 4KiB aligned.  */
>   addr = (addr_max - size) & ~0xFFF;
> 
> page_align(size) returns a rounded-up alignment of size; i.e., if size is 0x2335b728, it returns 0x2335c000.  Consequently, if the initrd size doubles, the distance between the ceiling and the first byte doubles (expected), AND the distance between the floor and the first byte halves because both are proportional to the size.  I would expect the floor to remain relatively constant based on the memory map.  Maybe be adjusted between 1-4k bytes for alignment, but not by the whole size of the initrd.
> 
> I'm wondering if this is a bug, or if my modest and cursory understanding of the code is incorrect.
> 
> If I am incorrect, can someone explain the page_align calculus, and also explain how the value of GRUB_LINUX_INITRD_MAX_ADDRESS (0x37FFFFFF) was determined, whether it is hard or might be revisable upward on some systems, and what the implications are of changing it (i.e. will it either work or not boot at all, or whether I might silently hose something).
> 
> Thanks,
> Eric Ewanco
> 
> 
>