grub-devel
[Top][All Lists]
Advanced

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

Re: What is this grub_disk_read doing in the i386 linux loader?


From: Daniel Kiper
Subject: Re: What is this grub_disk_read doing in the i386 linux loader?
Date: Thu, 26 Apr 2018 16:19:45 +0200
User-agent: Mutt/1.3.28i

On Wed, Apr 25, 2018 at 12:45:15PM -0700, Andrew Jeddeloh wrote:
> > As Michael said, "0x0202 + byte value at offset 0x0201" is your friend.
>
> I think Michael's message got lost; I think he replied to just you? I
> didn't receive it and I don't see it in the archives.
>
> > AIUI it is. Please look above.
>
> I don't know what you're refering to here by "above".

I am referring to the math above and in general to 32-bit BOOT PROTOCOL
paragraph from https://www.kernel.org/doc/Documentation/x86/boot.txt

> > This is wrong due to grub_e820_mmap.
>
> My understanding is wrong or grub's behavior is wrong? Can you elaborate 
> please?

GRUB behavior is wrong due to grub_e820_mmap.

> > This read is needed
>
> I don't understand why. Again, looking at the zero page documentation,
> there's nothing after the 16 bit boot params that the linux image

I am not sure what do you mean by "16 bit boot params". Anyway, again 32-bit
BOOT PROTOCOL paragraph is pretty clear: ... Then the setup header from
offset 0x01f1 of kernel image on should be loaded into struct boot_params
and examined. The end of setup header can be calculated as follow:
0x0202 + byte value at offset 0x0201 ...

> could know ahead of time. Is your concern that future fields could be
> added that do need to be read?

Exactly.

> Regardless, we can't calculate then length then blindly use it reading
> into a struct. If the length grows larger than the size of the struct
> we'll start corrupting memory when doing the read. Assuming the read

Yep, the end of linux_params.pad2 is the limit. We should not go
over it. So, just simply check that we are not going to read more
than that. Otherwise fail and print an error message.

> is needed, we'll need to malloc the amount that still needs to be read
> then probably copy that into a struct to modify (and ignore the bits
> we don't understand in the case of a new Linux release adding fields
> grub doesn't have yet).
>
> Sorry for all the questions, I want to ensure that I understand what's

No problem.

> supposed to be happening first.

That is good way to go.

Daniel



reply via email to

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