Messages in this thread | | | Date | Mon, 14 Jan 2013 14:38:36 -0800 | Subject | Re: [PATCH v7u1 22/31] x86, boot: add fields to support load bzImage and ramdisk above 4G | From | Yinghai Lu <> |
| |
On Mon, Jan 14, 2013 at 12:26 PM, Borislav Petkov <bp@alien8.de> wrote: > On Mon, Jan 14, 2013 at 12:14:18PM -0800, Yinghai Lu wrote: >> no, no, no. >> >> bootloader does not need to know sentinel, and they only need to do: >> clearing boot_param buffer and copying setup_header only >> >> even new bootloader is not supposed to know sentinel ... > > Ah, ok. I thought something was fishy because if bootloaders would know > about it, they'd copy setup_header and zero out the sentinel only, to > force the kernel to use crappy ext_* etc. values. > > How about this: > > "The sentinel variable is set by the linker script to 0xff. It is > supposed to be used for catching bootloaders which just copy the > setup_header portion and don't clear the whole boot_params buffer as > they are supposed to. Such bootloaders will leave the sentinel to its > initial value of 0xff and in this case, the kernel will assume that some > fields in boot_params have invalid values and zero them out." > still not clear ...
in the kernel image, we only have setup_header, and it is around with other codes.
bootloader could prepare boot_param several ways. 1. allocate boot_param, and memset it to 0, and copy setup_header from kernel image to the middle boot_param. 2. allocate buffer equal to whole setup section include code and setup_header. and copy whole setup section to buffer, and use that buffer as boot_params. a. use setup_code to do real mode booting. or b. clear used fields or store value in boot_param to use 32bit entry or 64bit entry.
so now hope you understand my changes.
>> + /* >> + * kernel have sentinel to set as 0xff in setup link scripts, >> + * so if bootloader just copy whole page from kernel image to >> + * get setup_header instead of clearing boot_param buffer and >> + * copying setup_header only, will leave sentinel as 0xff. >> + * With that, we can tell some fields in boot_param have >> + * invalid values, and we need to zero them in kernel. >> + */
| |