Messages in this thread | | | Date | Mon, 14 Jan 2013 17:04:25 -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 3:11 PM, Borislav Petkov <bp@alien8.de> wrote: >> >> + /* >> >> + * 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. > > Ok, but this needlessly mentiones some sort of allocation technique > which the bootloader does and which we don't care about. What we do care > about is the sentinel variable and what it means: if the bootloader > copies it accidentally, we use *that* as a trigger. So let's revise it: > > "The sentinel variable is set by the linker script to 0xff. A bootloader > is supposed to only take setup_header and put it into a clean > boot_params buffer. If it turns out that it is clumsy or too generous > with the buffer, it most probably will pick up the sentinel variable > too. The fact that this variable then is still non-zero signals to > us that that we should zero out certain portions of boot_params (see > sanitize_real_mode()) because we assume that they contain garbage."
ok, I changed to :
/* * The sentinel is set to 0xff via the linker script (setup.ld). * A bootloader is supposed to only take setup_header and put * it into a clean boot_params buffer. If it turns out that * it is clumsy or too generous with the buffer, it most * probably will pick up the sentinel variable too. The fact * that this variable then is still 0xff will let kernel * know that some variables in boot_params are invalid and * kernel should zero out certain portions of boot_params * (see sanitize_real_mode()). */
| |