Re: [Xen-devel] PLEASE REVERT URGENTLY: Re: [PATCH v5 2/3] x86/boot: add acpi rsdp address to setup_header

["H. Peter Anvin" <hpa@xxxxxxxxx>]

> 
> 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


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel