linux-kernel - Re: PLEASE REVERT URGENTLY: Re: [PATCH v5 2/3] x86/boot: add acpi rsdp address to setup

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <2934552c-d150-0afb-6fa9-9398cb94d86a@zytor.com>
Date:   Fri, 9 Nov 2018 22:32:10 -0800
From:   "H. Peter Anvin" <hpa@...or.com>
To:     Juergen Gross <jgross@...e.com>, linux-kernel@...r.kernel.org,
        xen-devel@...ts.xenproject.org, x86@...nel.org,
        linux-doc@...r.kernel.org
Cc:     tglx@...utronix.de, mingo@...hat.com, bp@...en8.de, corbet@....net,
        boris.ostrovsky@...cle.com
Subject: Re: PLEASE REVERT URGENTLY: Re: [PATCH v5 2/3] x86/boot: add acpi
 rsdp address to setup_header

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