initrd loading, max size, addr_min, and page_align

initrd loading, max size, addr_min, and page_align

[Eric Ewanco]

[-- Attachment #1.1: Type: text/plain, Size: 1828 bytes --]


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.

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);

  /* 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




[-- Attachment #1.2: Type: text/html, Size: 4397 bytes --]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Eric J Ewanco.vcf --]
[-- Type: text/x-vcard; name="Eric J Ewanco.vcf", Size: 3815 bytes --]

BEGIN:VCARD
VERSION:2.1
X-MS-SIGNATURE:YES
N;LANGUAGE=en-us:Ewanco;Eric;J
FN:Eric J Ewanco
ORG:GENBAND;2022 Product Session & Security
TITLE:Senior Designer
TEL;WORK;VOICE:+1 (978) 947-3412
TEL;CELL;VOICE:+1 (508) 410-0470
X-MS-TEL;VOICE;COMPANY:62-73412
ADR;WORK;PREF:;;3 Federal St;Billerica;MA;01821;United States of America
LABEL;WORK;PREF;ENCODING=QUOTED-PRINTABLE:3 Federal St=0D=0A=
Billerica MA 01821
X-MS-OL-DEFAULT-POSTAL-ADDRESS:2
URL;WORK:www.genband.com
EMAIL;PREF;INTERNET:Eric.Ewanco@genband.com
X-MS-IMADDRESS:eric.ewanco@gmail.com
X-MS-CARDPICTURE;TYPE=JPEG;ENCODING=BASE64:
 /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAcFBQYFBAcGBQYIBwcIChELCgkJChUPEAwRGBUa
 GRgVGBcbHichGx0lHRcYIi4iJSgpKywrGiAvMy8qMicqKyr/2wBDAQcICAoJChQLCxQqHBgc
 KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKir/wAAR
 CAAjAB0DASIAAhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAA
 AgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkK
 FhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWG
 h4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl
 5ufo6erx8vP09fb3+Pn6/8QAHwEAAwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREA
 AgECBAQDBAcFBAQAAQJ3AAECAxEEBSExBhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYk
 NOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOE
 hYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk
 5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD1rxH4j1S61o+HfCiKb4KGuLl+Ut1P9f8A
 P0zv+FX2c483xFrl5dXB6sZQoz7ZzWXo+q3trokEWhoJNf8AEE0lw8jjIhTew3H2GDj8fpWw
 vwx0+VRceJdWur28f7zvNtGfQZyf1rh/i6tc3zsl/wAE+m/3P3Iz5Ol0rybWjfkr3tqQy+Ed
 e8LL9t8J6tLeRpy9jcncHX/Z7Z+mD7113hnxFb+JdIW7hXypFYxzQt1jcdQa5G58L6p4MjOp
 +FL+a8tIvmn0+dtwZe5XHGce2fr0rntW8Tvo+tPqegBUt9Zt47l0borgsp/HIOfelz+y6WXb
 f5oTw7xyspKUukrWfmpL01T8joLmFvC+v6gdOt/MuXht7XTgw4BkeQn8AVJP0rUt/htp92v2
 jxJPcareyDMkkkzKAfRQpGBWh4uspprO0vLdSZbK5WZtjbTtwVJBwegYnoRwatW+o3CQgPNE
 xI/5boY2/MZVvqvFaqmlJpq66djiliq0qanTdpPRtb6Jde3X1ZzdxpVx4Cljv9LupptFZ1ju
 7OZ93khjjzEPsSMj/IPDfhCx1CwuGvoMxxXk8duCOiCQ/wBc1a8Si+1awGnJIZPtjiILEhjQ
 AnkljktgZPGB6+ldjFGIYlRFAAFONOLk1bRCq4qrToqXN77erW9ltfz1ZKRxXM6/PJpEaf2c
 5hDnlRyOvYHIH4UUVrP4WcGHV5pM1tNgjMYuSu6Z1GXYknHoPQew4rQooq1sZ1fjZ//Z

X-MS-OL-DESIGN;CHARSET=utf-8:<card xmlns="http://schemas.microsoft.com/office/outlook/12/electronicbusinesscards" ver="1.0" layout="left" bgcolor="ffffff"><img xmlns="" align="tleft" area="15" use="cardpicture"/><fld xmlns="" prop="name" align="left" dir="ltr" style="b" color="000000" size="10"/><fld xmlns="" prop="title" align="left" dir="ltr" color="000000" size="8"/><fld xmlns="" prop="blank" size="8"/><fld xmlns="" prop="org" align="left" dir="ltr" color="000000" size="8"/><fld xmlns="" prop="telwork" align="left" dir="ltr" color="000000" size="8"><label align="left" color="626262">office </label></fld><fld xmlns="" prop="telorg" align="left" dir="ltr" color="000000" size="8"><label align="left" color="626262">a2       </label></fld><fld xmlns="" prop="telcell" align="left" dir="ltr" color="000000" size="8"><label align="left" color="626262">mobile</label></fld><fld xmlns="" prop="email" align="left" dir="ltr" color="000000" size="8"><label align="left" color="626262">email   </label></fld><fld xmlns="" prop="im" align="left" dir="ltr" color="000000" size="8"><label align="left" color="626262">talk     </label></fld><fld xmlns="" prop="addrwork" align="left" dir="ltr" color="000000" size="8"/><fld xmlns="" prop="webwork" align="left" dir="ltr" color="000000" size="8"/><fld xmlns="" prop="dept" align="left" dir="ltr" color="000000" size="8"/><fld xmlns="" prop="blank" size="8"/><fld xmlns="" prop="blank" size="8"/><fld xmlns="" prop="blank" size="8"/><fld xmlns="" prop="blank" size="8"/></card>
REV:20110809T170626Z
END:VCARD

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

[Andrei Borzenkov]

В 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
> 
> 
> 

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

[Bruce Dubbs]

Andrei Borzenkov wrote:
> В 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.

But as far as I know grub-2.00 is the last "stable" release.  There is the more 
current grub-2.02~beta2 that was released over a year ago, but some people 
prefer releases that upstream has designated as stable.

Has grub gone to a policy of git snapshots only and forgone stable releases?

   -- Bruce

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

[Andrei Borzenkov]

В Sun, 08 Feb 2015 11:14:28 -0600
Bruce Dubbs <bruce.dubbs@gmail.com> пишет:

> Andrei Borzenkov wrote:
> > В 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.
> 
> But as far as I know grub-2.00 is the last "stable" release.  There is the more 
> current grub-2.02~beta2 that was released over a year ago, but some people 
> prefer releases that upstream has designated as stable.
> 

If you want to discuss a problem on development list, you should at
least verify if this problem exists in current code. 

In practice all ditros I'm aware of are using at least 2.02~beta2 or
what effectively amounts to git snapshot.

> Has grub gone to a policy of git snapshots only and forgone stable releases?
> 

I do not think it is intentional.

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

[Bruce Dubbs]

Andrei Borzenkov wrote:
> В Sun, 08 Feb 2015 11:14:28 -0600
> Bruce Dubbs <bruce.dubbs@gmail.com> пишет:
>
>> Andrei Borzenkov wrote:
>>> В 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.
>>
>> But as far as I know grub-2.00 is the last "stable" release.  There is the more
>> current grub-2.02~beta2 that was released over a year ago, but some people
>> prefer releases that upstream has designated as stable.
>>
>
> If you want to discuss a problem on development list, you should at
> least verify if this problem exists in current code.

I agree.

> In practice all ditros I'm aware of are using at least 2.02~beta2 or
> what effectively amounts to git snapshot.

Indeed.  We have gone to 2.02~beta2 also, although we prefer it when upstream 
labels a packages as stable.

>> Has grub gone to a policy of git snapshots only and forgone stable releases?
>>
>
> I do not think it is intentional.

There are several packages that do not release stable releases but only 
snapshots (but it is uncommon), however AFAIK grub is one of the very few active 
packages that does not seem to have a regularly scheduled release process.

It would actually help us if you just said that you are not going to designate 
stable, release candidate, beta, etc tarballs any more and it's up to the distro 
or individual to figure out what version to extract from version control.

   -- Bruce Dubbs
      LFS

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

[Michael Zimmermann]

yea everyone uses either the master branch or the latest beta - it
should be pretty stable.

I guess there just isn't anyone who has the time to test every single
feature to find bugs so we can say it's 99% stable.

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

[Eric Ewanco]

Andrei Borzenkov wrote:

>If you want to discuss a problem on development list,
> you should at least verify if this problem exists in current code. 

In  my defense, I did do a git pull before posting and attempted to look at the latest code.  Apparently, however, I somehow inadvertently looked at the wrong copy of the file (I have several copies of GRUB hanging around) and missed the fact this was fixed exactly as I thought it should be.  My apologies for not double-checking and for wasting everyone's time.  Thanks for the responses.