> > Unfortunately there are many major distros shipping boot loaders which > write crap data past the end of setup_header. > Yes. We know that and it is resolved by: a) the length field in setup_header; b) the "sentinel" field which catches legacy non-compliant bootloaders. >> >> This field thus belongs in struct boot_params, not struct setup_header. > > Okay, I can change that. Hoping that all boot loaders really write > zeroes to that field in case they don't know it. > This is what we added the sentinel field for: bootloaders which don't zero unknown fields (read: Grub) will trigger the sentinel, and we wipe most of this structure. >> >> Fields in struct boot_params are to be initialized to zero. > > See above. grub2 in Debian, RHEL, ... doesn't do that reliably. > See above. >> There is a field called "sentinel" which attempts to detect broken >> bootloaders which do not do this correctly; however, when enabling new >> bootloaders the Right Thing to do is to make sure they adhere to the >> protocol as defined, rather than pushing a new hack onto the kernel. >> >> Thus: >> >> 1. Please revert this patch immediately, and destroy any boot loaders >> which tries to implement this.> 2. Add the acpi_rsdp_addr to struct boot_params. >> 3. DO NOT modify the boot protocol version header field. Instead >> make sure that the bootloader follows the protocol and zeroes >> all unknown fields in struct boot_params. > > How can I do this for boot loaders shipped since several years? Once again, you are adding new functionality; that is when you should fix their implementation. The sentinel handles legacy bootloaders. >> 4. Possibly make the kernel panic if it notices that the boot version >> header has been mucked with, in case some of these boot loaders >> have already escaped into the field. > > So don't let a new kernel boot from a disk with above grub2? > > I don't think so. If there are any grubs which escaped with this broken protocol hack only. -hpa
