Skip to contentSkip to conversation

bootconfig length parse error in kernel

PATCH In review Chen Yu 3 participants 11 messages Nov 10, 2020 – Nov 13, 2020

lore
Share & tools
lore

Chen Yu

author
#0 lore raw

Hi Masami,
Thanks for writing bootconfig and it is useful for boot up trace event debugging.
However it was found that on 5.10-rc2 the bootconfig does not work and it shows "'bootconfig' found on command line, but no bootconfig found"
And the reason for this is the kernel found the magic number to be incorrect. I've added some hack in kernel to dump the first 12 bytes, it shows:
"OTCONFIG". So printed more content ahead we can find "#BOOTCONFIG" ahead. So it looks that there is some alignment during initrd load, and get_boot_config_from_initrd() might also deal with it. That is to say:
data = (char *)initrd_end - BOOTCONFIG_MAGIC_LEN;
might do some alignment?

Signature · 2 lines
Thanks,
Chenyu
#1 lore raw

Hi Chen,

Quoted 3 lines · On Tue, 10 Nov 2020 23:39:53 +0800 Chen Yu <[email protected]> wrote:

Hi Masami,
Thanks for writing bootconfig and it is useful for boot up trace event debugging.

Thanks for testing!

Quoted 10 lines

However it was found that on 5.10-rc2 the bootconfig does not work and it shows "'bootconfig' found on command line, but no bootconfig found"
And the reason for this is the kernel found the magic number to be incorrect. I've added some hack in kernel to dump the first 12 bytes, it shows:
"OTCONFIG". So printed more content ahead we can find "#BOOTCONFIG" ahead. So it looks that there is some alignment during initrd load, and get_boot_config_from_initrd() might also deal with it. That is to say:
data = (char *)initrd_end - BOOTCONFIG_MAGIC_LEN;
might do some alignment?

Hrm, interesting. So initrd_end might be aligned. Could you print out the actuall address of initrd_end? And could you tell me which platform are you tested?

Thank you,

Signature · 1 line
Masami Hiramatsu <[email protected]>
author
#2 lore raw

Hi Masami,

Quoted 23 lines · Masami Hiramatsu

Hi Chen,

Quoted 3 lines · On Tue, 10 Nov 2020 23:39:53 +0800 Chen Yu <[email protected]> wrote:

Hi Masami,
Thanks for writing bootconfig and it is useful for boot up trace event debugging.

Thanks for testing!

Quoted 10 lines

However it was found that on 5.10-rc2 the bootconfig does not work and it shows "'bootconfig' found on command line, but no bootconfig found"
And the reason for this is the kernel found the magic number to be incorrect. I've added some hack in kernel to dump the first 12 bytes, it shows:
"OTCONFIG". So printed more content ahead we can find "#BOOTCONFIG" ahead. So it looks that there is some alignment during initrd load, and get_boot_config_from_initrd() might also deal with it. That is to say:
data = (char *)initrd_end - BOOTCONFIG_MAGIC_LEN;
might do some alignment?

Quoted 2 lines

Hrm, interesting. So initrd_end might be aligned. Could you print out the actuall address of initrd_end?

I've done some investigation, it looks like this issue is not related to alignment, but related to
the bootloader that has provided an inaccurate ramdisk size via boot_params.hdr.ramdisk_size.
The actual size of initrd is:
ls /boot/initrd.img-5.10.0-rc3-e1000e-hw+ -l
-rw-r--r-- 1 root root 48689230 11月 12 00:08 /boot/initrd.img-5.10.0-rc3-e1000e-hw+
while the ramdisk size provided by bootloader via boot_params.hdr.ramdisk_size is
48689232, which is 2 bytes bigger than the actual size, and this is why the initrd_end
is bigger than expected and causing the missmatch of magic number. Since there is no guarantee that bootloader provides the accurate ramdisk size, an compromised
proposal might be that to search for the magic number a little ahead. For example, the
following patch works for me:

init/main.c +0 -0
index 130376ec10ba..60fb125d44f4 100644
@@ -273,7 +273,10 @@ static void * __init

get_boot_config_from_initrd(u32 *_size, u32 *_csum)

        if (!initrd_end)
                return NULL;

- data = (char *)initrd_end - BOOTCONFIG_MAGIC_LEN;
+ data = memchr((char *)initrd_end - 2 * BOOTCONFIG_MAGIC_LEN,
+ '#', BOOTCONFIG_MAGIC_LEN);
+ if (!data)
+ return NULL;
if (memcmp(data, BOOTCONFIG_MAGIC, BOOTCONFIG_MAGIC_LEN))
return NULL;

Quoted 2 lines

And could you tell me which platform are you tested?

It is HP ZHAN 99 Mobile Workstation G1 with i5-8300H, Ubuntu 20.04.

Thanks,
Chenyu

Quoted 4 lines

Thank you,

--
Masami Hiramatsu <[email protected]>

#3 lore raw

Hi Chen,

Quoted 26 lines · On Thu, 12 Nov 2020 12:34:36 +0800 Chen Yu <[email protected]> wrote:

Hi Masami,

Quoted 23 lines · Masami Hiramatsu

Hi Chen,

Quoted 3 lines · On Tue, 10 Nov 2020 23:39:53 +0800 Chen Yu <[email protected]> wrote:

Hi Masami,
Thanks for writing bootconfig and it is useful for boot up trace event debugging.

Thanks for testing!

Quoted 10 lines

However it was found that on 5.10-rc2 the bootconfig does not work and it shows "'bootconfig' found on command line, but no bootconfig found"
And the reason for this is the kernel found the magic number to be incorrect. I've added some hack in kernel to dump the first 12 bytes, it shows:
"OTCONFIG". So printed more content ahead we can find "#BOOTCONFIG" ahead. So it looks that there is some alignment during initrd load, and get_boot_config_from_initrd() might also deal with it. That is to say:
data = (char *)initrd_end - BOOTCONFIG_MAGIC_LEN;
might do some alignment?

Quoted 6 lines
Quoted 2 lines

Hrm, interesting. So initrd_end might be aligned. Could you print out the actuall address of initrd_end?

I've done some investigation, it looks like this issue is not related to alignment, but related to
the bootloader that has provided an inaccurate ramdisk size via boot_params.hdr.ramdisk_size.

Yeah, it seems to happen. bootloader can pass wrong (bigger) size to kernel. BTW, what bootloader would you use?

Quoted 9 lines

The actual size of initrd is:
ls /boot/initrd.img-5.10.0-rc3-e1000e-hw+ -l
-rw-r--r-- 1 root root 48689230 11月 12 00:08 /boot/initrd.img-5.10.0-rc3-e1000e-hw+
while the ramdisk size provided by bootloader via boot_params.hdr.ramdisk_size is
48689232, which is 2 bytes bigger than the actual size, and this is why the initrd_end
is bigger than expected and causing the missmatch of magic number.

OK. It seems that the bootloader might cut it up to 16 bytes aligned. (But I think that's wrong behavior, there is no reason to do it)

Quoted 3 lines

Since there is no guarantee that bootloader provides the accurate ramdisk size, an compromised
proposal might be that to search for the magic number a little ahead.

If the bootloader does such wrong behavior, there is no guarantee that the size is "a little" bigger. IOW, it can be aligned to the page size (4KB-)

Quoted 7 lines

For example, the
following patch works for me:

init/main.c +0 -0
index 130376ec10ba..60fb125d44f4 100644

init/main.c static void * __init · line 280

Quoted 9 lines
init/main.c +4 -1
@@ -273,7 +273,10 @@ static void * __init
 get_boot_config_from_initrd(u32 *_size, u32 *_csum)
        if (!initrd_end)
                return NULL;
 
-       data = (char *)initrd_end - BOOTCONFIG_MAGIC_LEN;
+       data = memchr((char *)initrd_end - 2 * BOOTCONFIG_MAGIC_LEN,
+                      '#', BOOTCONFIG_MAGIC_LEN);
+       if (!data)
+               return NULL;

So this also does not guarantee that we can find "#" in BOOTCONFIG_MAGIC_LEN. We need to find actual code in the bootloader, what it does.

Quoted 7 lines
init/main.c +0 -0
        if (memcmp(data, BOOTCONFIG_MAGIC, BOOTCONFIG_MAGIC_LEN))
                return NULL;
Quoted 4 lines

And could you tell me which platform are you tested?

It is HP ZHAN 99 Mobile Workstation G1 with i5-8300H, Ubuntu 20.04.

Hmm, this means x86 Grub2 does this change. Let me check it.

Thank you,

Signature · 1 line
Masami Hiramatsu <[email protected]>
author
#4 lore raw
Quoted 34 lines · Masami Hiramatsu

Hi Chen,

Quoted 28 lines · On Thu, 12 Nov 2020 12:34:36 +0800 Chen Yu <[email protected]> wrote:

Hi Masami,

Quoted 25 lines · Masami Hiramatsu

Hi Chen,

Quoted 3 lines · On Tue, 10 Nov 2020 23:39:53 +0800 Chen Yu <[email protected]> wrote:

Hi Masami,
Thanks for writing bootconfig and it is useful for boot up trace event debugging.

Thanks for testing!

Quoted 10 lines

However it was found that on 5.10-rc2 the bootconfig does not work and it shows "'bootconfig' found on command line, but no bootconfig found"
And the reason for this is the kernel found the magic number to be incorrect. I've added some hack in kernel to dump the first 12 bytes, it shows:
"OTCONFIG". So printed more content ahead we can find "#BOOTCONFIG" ahead. So it looks that there is some alignment during initrd load, and get_boot_config_from_initrd() might also deal with it. That is to say:
data = (char *)initrd_end - BOOTCONFIG_MAGIC_LEN;
might do some alignment?

Hrm, interesting. So initrd_end might be aligned. Could you print out the actuall address of initrd_end?

Quoted 8 lines
Quoted 4 lines

I've done some investigation, it looks like this issue is not related to alignment, but related to
the bootloader that has provided an inaccurate ramdisk size via boot_params.hdr.ramdisk_size.

Yeah, it seems to happen. bootloader can pass wrong (bigger) size to kernel. BTW, what bootloader would you use?

It is

$ grub-install --version
grub-install (GRUB) 2.04-1ubuntu26.2
Quoted 10 lines
Quoted 9 lines

The actual size of initrd is:
ls /boot/initrd.img-5.10.0-rc3-e1000e-hw+ -l
-rw-r--r-- 1 root root 48689230 11月 12 00:08 /boot/initrd.img-5.10.0-rc3-e1000e-hw+
while the ramdisk size provided by bootloader via boot_params.hdr.ramdisk_size is
48689232, which is 2 bytes bigger than the actual size, and this is why the initrd_end
is bigger than expected and causing the missmatch of magic number.

Quoted 3 lines

OK. It seems that the bootloader might cut it up to 16 bytes aligned. (But I think that's wrong behavior, there is no reason to do it)

Agree.

Quoted 9 lines
Quoted 4 lines

Since there is no guarantee that bootloader provides the accurate ramdisk size, an compromised
proposal might be that to search for the magic number a little ahead.

If the bootloader does such wrong behavior, there is no guarantee that the size is "a little" bigger. IOW, it can be aligned to the page size (4KB-)

Right. How about inserting the bootconfig at initrd_start if initrd_end could not be trusted?

Quoted 11 lines
Quoted 11 lines

For example, the
following patch works for me:

init/main.c +0 -0
index 130376ec10ba..60fb125d44f4 100644
@@ -273,7 +273,10 @@ static void * __init
 get_boot_config_from_initrd(u32 *_size, u32 *_csum)
        if (!initrd_end)
                return NULL;
 
Quoted 9 lines

init/main.c static void * __init · line 280

Quoted 5 lines
init/main.c +4 -1
-       data = (char *)initrd_end - BOOTCONFIG_MAGIC_LEN;
+       data = memchr((char *)initrd_end - 2 * BOOTCONFIG_MAGIC_LEN,
+                      '#', BOOTCONFIG_MAGIC_LEN);
+       if (!data)
+               return NULL;

So this also does not guarantee that we can find "#" in BOOTCONFIG_MAGIC_LEN. We need to find actual code in the bootloader, what it does.

Indeed.

Quoted 10 lines
Quoted 7 lines
init/main.c +0 -0
        if (memcmp(data, BOOTCONFIG_MAGIC, BOOTCONFIG_MAGIC_LEN))
                return NULL;
Quoted 4 lines

And could you tell me which platform are you tested?

It is HP ZHAN 99 Mobile Workstation G1 with i5-8300H, Ubuntu 20.04.

Hmm, this means x86 Grub2 does this change. Let me check it.

Okay.

Thanks,
Chenyu

Quoted 5 lines

Thank you,

--
Masami Hiramatsu <[email protected]>

#5 lore raw
Quoted 91 lines · On Thu, 12 Nov 2020 14:49:16 +0800 Chen Yu <[email protected]> wrote:
Quoted 34 lines · Masami Hiramatsu

Hi Chen,

Quoted 28 lines · On Thu, 12 Nov 2020 12:34:36 +0800 Chen Yu <[email protected]> wrote:

Hi Masami,

Quoted 25 lines · Masami Hiramatsu

Hi Chen,

Quoted 3 lines · On Tue, 10 Nov 2020 23:39:53 +0800 Chen Yu <[email protected]> wrote:

Hi Masami,
Thanks for writing bootconfig and it is useful for boot up trace event debugging.

Thanks for testing!

Quoted 10 lines

However it was found that on 5.10-rc2 the bootconfig does not work and it shows "'bootconfig' found on command line, but no bootconfig found"
And the reason for this is the kernel found the magic number to be incorrect. I've added some hack in kernel to dump the first 12 bytes, it shows:
"OTCONFIG". So printed more content ahead we can find "#BOOTCONFIG" ahead. So it looks that there is some alignment during initrd load, and get_boot_config_from_initrd() might also deal with it. That is to say:
data = (char *)initrd_end - BOOTCONFIG_MAGIC_LEN;
might do some alignment?

Hrm, interesting. So initrd_end might be aligned. Could you print out the actuall address of initrd_end?

Quoted 8 lines
Quoted 4 lines

I've done some investigation, it looks like this issue is not related to alignment, but related to
the bootloader that has provided an inaccurate ramdisk size via boot_params.hdr.ramdisk_size.

Yeah, it seems to happen. bootloader can pass wrong (bigger) size to kernel. BTW, what bootloader would you use?

It is

$ grub-install --version
grub-install (GRUB) 2.04-1ubuntu26.2
Quoted 10 lines
Quoted 9 lines

The actual size of initrd is:
ls /boot/initrd.img-5.10.0-rc3-e1000e-hw+ -l
-rw-r--r-- 1 root root 48689230 11月 12 00:08 /boot/initrd.img-5.10.0-rc3-e1000e-hw+
while the ramdisk size provided by bootloader via boot_params.hdr.ramdisk_size is
48689232, which is 2 bytes bigger than the actual size, and this is why the initrd_end
is bigger than expected and causing the missmatch of magic number.

Quoted 3 lines

OK. It seems that the bootloader might cut it up to 16 bytes aligned. (But I think that's wrong behavior, there is no reason to do it)

Agree.

Quoted 9 lines
Quoted 4 lines

Since there is no guarantee that bootloader provides the accurate ramdisk size, an compromised
proposal might be that to search for the magic number a little ahead.

If the bootloader does such wrong behavior, there is no guarantee that the size is "a little" bigger. IOW, it can be aligned to the page size (4KB-)

Right. How about inserting the bootconfig at initrd_start if initrd_end could not be trusted?

Quoted 11 lines
Quoted 11 lines

For example, the
following patch works for me:

init/main.c +0 -0
index 130376ec10ba..60fb125d44f4 100644
@@ -273,7 +273,10 @@ static void * __init
 get_boot_config_from_initrd(u32 *_size, u32 *_csum)
        if (!initrd_end)
                return NULL;
 
Quoted 9 lines

init/main.c static void * __init · line 280

Quoted 5 lines
init/main.c +4 -1
-       data = (char *)initrd_end - BOOTCONFIG_MAGIC_LEN;
+       data = memchr((char *)initrd_end - 2 * BOOTCONFIG_MAGIC_LEN,
+                      '#', BOOTCONFIG_MAGIC_LEN);
+       if (!data)
+               return NULL;

So this also does not guarantee that we can find "#" in BOOTCONFIG_MAGIC_LEN. We need to find actual code in the bootloader, what it does.

Quoted 11 lines

Indeed.

Quoted 10 lines
Quoted 7 lines
init/main.c +0 -0
        if (memcmp(data, BOOTCONFIG_MAGIC, BOOTCONFIG_MAGIC_LEN))
                return NULL;
Quoted 4 lines

And could you tell me which platform are you tested?

It is HP ZHAN 99 Mobile Workstation G1 with i5-8300H, Ubuntu 20.04.

Hmm, this means x86 Grub2 does this change. Let me check it.

I found the 4 byte alignment code in the grub (grub_initrd_init()grub-core/loader/linux.c), but that seems to happen only when load a file with newc:/PACKAGE/FILE format. (And this is not documented.) At a glance, u-boot may not do that (but of course user can pass different size directly by command), EDK2 doesn't too. So, we should check at least 3 byte back for grub.

BTW, just out of curious, what is your "initrd" command line in grub.conf? :)

Thank you,

Signature · 1 line
Masami Hiramatsu <[email protected]>
#6 lore raw

PATCH 1/1 bootconfig: Extend the magic check range to the preceding 3 bytes

Since Grub may align the size of initrd to 4 if user pass initrd from cpio, we have to check the preceding 3 bytes as well.

Fixes 85c46b78da58 ("bootconfig: Add bootconfig magic word for indicating bootconfig explicitly")
---
 init/main.c |   14 ++++++++++++--
 1 file changed, 12 insertions(+), 2 deletions(-)
init/main.c +12 -2
index 130376ec10ba..20baced721ad 100644
@@ -269,14 +269,24 @@ static void * __init get_boot_config_from_initrd(u32 *_size, u32 *_csum)
 	u32 size, csum;
 	char *data;
 	u32 *hdr;
+	int i;
 
 	if (!initrd_end)
 		return NULL;
 
 	data = (char *)initrd_end - BOOTCONFIG_MAGIC_LEN;
-	if (memcmp(data, BOOTCONFIG_MAGIC, BOOTCONFIG_MAGIC_LEN))
-		return NULL;
+	/*
+	 * Since Grub may align the size of initrd to 4, we must
+	 * check the preceding 3 bytes as well.
+	 */
+	for (i = 0; i < 4; i++) {
+		if (!memcmp(data, BOOTCONFIG_MAGIC, BOOTCONFIG_MAGIC_LEN))
+			goto found;
+		data--;
+	}
+	return NULL;
 
+found:
 	hdr = (u32 *)(data - 8);
 	size = hdr[0];
 	csum = hdr[1];
author Tested-by on v1 1/1
#7 lore raw

Re: [PATCH] bootconfig: Extend the magic check range to the preceding 3 bytes

Quoted 8 lines · Masami Hiramatsu

Since Grub may align the size of initrd to 4 if user pass initrd from cpio, we have to check the preceding 3 bytes as well.

Fixes 85c46b78da58 ("bootconfig: Add bootconfig magic word for indicating bootconfig explicitly")

---

Works for me, thanks!

Best,
Chenyu

#8 lore raw

Re: [PATCH] bootconfig: Extend the magic check range to the preceding 3 bytes

Quoted 11 lines · On Fri, 13 Nov 2020 09:27:38 +0800 Chen Yu <[email protected]> wrote:
Quoted 8 lines · Masami Hiramatsu

Since Grub may align the size of initrd to 4 if user pass initrd from cpio, we have to check the preceding 3 bytes as well.

Fixes 85c46b78da58 ("bootconfig: Add bootconfig magic word for indicating bootconfig explicitly")

---

Works for me, thanks!

Thank you Chen!

Steve, could you merge this fix?

Thank you,

Quoted 3 lines

Best,
Chenyu

Signature · 1 line
Masami Hiramatsu <[email protected]>
#9 lore raw

Re: [PATCH] bootconfig: Extend the magic check range to the preceding 3 bytes

Quoted 14 lines · Masami Hiramatsu
Quoted 1 line · On Fri, 13 Nov 2020 09:27:38 +0800 Chen Yu <[email protected]> wrote:

On Fri, Nov 13, 2020 at 1:27 AM Masami Hiramatsu

Quoted 5 lines · <[email protected]> wrote:
Quoted 5 lines

Since Grub may align the size of initrd to 4 if user pass initrd from cpio, we have to check the preceding 3 bytes as well.

Fixes 85c46b78da58 ("bootconfig: Add bootconfig magic word for

indicating bootconfig explicitly")

Quoted 3 lines
Quoted 3 lines

---

Quoted 7 lines
Quoted 2 lines

Works for me, thanks!

Thank you Chen!

Steve, could you merge this fix?

I'm testing it now.

-- Steve

Quoted 5 lines

Thank you,

Quoted 3 lines

Best,
Chenyu

Signature · 1 line
Sent from my Android device with K-9 Mail. Please excuse my brevity and top posting.
author
#10 lore raw
In reply to Masami Hiramatsu
Quoted 107 lines · Masami Hiramatsu
Quoted 91 lines · On Thu, 12 Nov 2020 14:49:16 +0800 Chen Yu <[email protected]> wrote:
Quoted 34 lines · Masami Hiramatsu

Hi Chen,

Quoted 28 lines · On Thu, 12 Nov 2020 12:34:36 +0800 Chen Yu <[email protected]> wrote:

Hi Masami,

Quoted 25 lines · Masami Hiramatsu

Hi Chen,

Quoted 3 lines · On Tue, 10 Nov 2020 23:39:53 +0800 Chen Yu <[email protected]> wrote:

Hi Masami,
Thanks for writing bootconfig and it is useful for boot up trace event debugging.

Thanks for testing!

Quoted 10 lines

However it was found that on 5.10-rc2 the bootconfig does not work and it shows "'bootconfig' found on command line, but no bootconfig found"
And the reason for this is the kernel found the magic number to be incorrect. I've added some hack in kernel to dump the first 12 bytes, it shows:
"OTCONFIG". So printed more content ahead we can find "#BOOTCONFIG" ahead. So it looks that there is some alignment during initrd load, and get_boot_config_from_initrd() might also deal with it. That is to say:
data = (char *)initrd_end - BOOTCONFIG_MAGIC_LEN;
might do some alignment?

Hrm, interesting. So initrd_end might be aligned. Could you print out the actuall address of initrd_end?

Quoted 8 lines
Quoted 4 lines

I've done some investigation, it looks like this issue is not related to alignment, but related to
the bootloader that has provided an inaccurate ramdisk size via boot_params.hdr.ramdisk_size.

Yeah, it seems to happen. bootloader can pass wrong (bigger) size to kernel. BTW, what bootloader would you use?

It is

$ grub-install --version
grub-install (GRUB) 2.04-1ubuntu26.2
Quoted 10 lines
Quoted 9 lines

The actual size of initrd is:
ls /boot/initrd.img-5.10.0-rc3-e1000e-hw+ -l
-rw-r--r-- 1 root root 48689230 11月 12 00:08 /boot/initrd.img-5.10.0-rc3-e1000e-hw+
while the ramdisk size provided by bootloader via boot_params.hdr.ramdisk_size is
48689232, which is 2 bytes bigger than the actual size, and this is why the initrd_end
is bigger than expected and causing the missmatch of magic number.

Quoted 3 lines

OK. It seems that the bootloader might cut it up to 16 bytes aligned. (But I think that's wrong behavior, there is no reason to do it)

Agree.

Quoted 9 lines
Quoted 4 lines

Since there is no guarantee that bootloader provides the accurate ramdisk size, an compromised
proposal might be that to search for the magic number a little ahead.

If the bootloader does such wrong behavior, there is no guarantee that the size is "a little" bigger. IOW, it can be aligned to the page size (4KB-)

Right. How about inserting the bootconfig at initrd_start if initrd_end could not be trusted?

Quoted 11 lines
Quoted 11 lines

For example, the
following patch works for me:

init/main.c +0 -0
index 130376ec10ba..60fb125d44f4 100644
@@ -273,7 +273,10 @@ static void * __init
 get_boot_config_from_initrd(u32 *_size, u32 *_csum)
        if (!initrd_end)
                return NULL;
 
Quoted 9 lines

init/main.c static void * __init · line 280

Quoted 5 lines
init/main.c +4 -1
-       data = (char *)initrd_end - BOOTCONFIG_MAGIC_LEN;
+       data = memchr((char *)initrd_end - 2 * BOOTCONFIG_MAGIC_LEN,
+                      '#', BOOTCONFIG_MAGIC_LEN);
+       if (!data)
+               return NULL;

So this also does not guarantee that we can find "#" in BOOTCONFIG_MAGIC_LEN. We need to find actual code in the bootloader, what it does.

Quoted 11 lines

Indeed.

Quoted 10 lines
Quoted 7 lines
init/main.c +0 -0
        if (memcmp(data, BOOTCONFIG_MAGIC, BOOTCONFIG_MAGIC_LEN))
                return NULL;
Quoted 4 lines

And could you tell me which platform are you tested?

It is HP ZHAN 99 Mobile Workstation G1 with i5-8300H, Ubuntu 20.04.

Hmm, this means x86 Grub2 does this change. Let me check it.

Quoted 9 lines

I found the 4 byte alignment code in the grub (grub_initrd_init()grub-core/loader/linux.c), but that seems to happen only when load a file with newc:/PACKAGE/FILE format. (And this is not documented.) At a glance, u-boot may not do that (but of course user can pass different size directly by command), EDK2 doesn't too. So, we should check at least 3 byte back for grub.

BTW, just out of curious, what is your "initrd" command line in grub.conf? :)

It is:
linux /boot/vmlinuz-5.10.0-rc3-e1000e-hw+
root=UUID=21f729c7-4ab0-40a9-b8cf-6f22b3851b9f ro ignore_loglevel no_console_suspend bootconfig
initrd /boot/initrd.img-5.10.0-rc3-e1000e-hw+
Thanks,
Chenyu

Quoted 4 lines

Thank you,

--
Masami Hiramatsu <[email protected]>