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: <9A44B94A-AEDC-4638-A8FF-DEE76FE34056@zytor.com>
Date:   Sun, 11 Nov 2018 15:58:16 -0800
From:   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

On November 10, 2018 7:22:29 AM PST, Juergen Gross <jgross@...e.com> wrote:
>On 09/11/2018 23:23, H. Peter Anvin wrote:
>> I just noticed this patch -- I missed it because the cover message
>> seemed far more harmless so I didn't notice this change.
>> 
>> THIS PATCH IS FATALLY WRONG AND NEEDS TO BE IMMEDIATELY REVERTED
>BEFORE
>> ANYONE STARTS RELYING ON IT; IT HAS THE POTENTIAL OF BREAKING THE
>> BOOTLOADER PROTOCOL FOR ALL FUTURE.
>> 
>> It seems to be based on fundamental misconceptions about the various
>> data structures in the protocol, and does so in a way that completely
>> breaks the way the protocol is designed to work.
>> 
>> The protocol is specifically designed such that fields are not
>version
>> dependencies. The version number is strictly to inform the boot
>loader
>> about which capabilities the kernel has, so that the boot loader can
>> know if a certain data field is meaningful and/or honored.
>> 
>>> +Protocol 2.14:	(Kernel 4.20) Added acpi_rsdp_addr holding the
>physical
>>> +		address of the ACPI RSDP table.
>>> +		The bootloader updates version with:
>>> +		0x8000 | min(kernel-version, bootloader-version)
>>> +		kernel-version being the protocol version supported by
>>> +		the kernel and bootloader-version the protocol version
>>> +		supported by the bootloader.
>> 
>> [...]
>> 
>>>  **** MEMORY LAYOUT
>>>
>>>  The traditional memory map for the kernel loader, used for Image or
>>> @@ -197,6 +209,7 @@ Offset	Proto	Name		Meaning
>>>  0258/8	2.10+	pref_address	Preferred loading address
>>>  0260/4	2.10+	init_size	Linear memory required during initialization
>>>  0264/4	2.11+	handover_offset	Offset of handover entry point
>>> +0268/8	2.14+	acpi_rsdp_addr	Physical address of RSDP table
>> 
>> NO.
>> 
>> That is not how struct setup_header works, nor does this belong here.
>> 
>> struct setup_header contains *initialized data*, and has a length
>byte
>> at offset 0x201.  The bootloader is responsible for copying the full
>> structure into the appropriate offset (0x1f1) in struct boot_params.
>> 
>> The length byte isn't actually a requirement, since the maximum
>possible
>> size of this structure is 144 bytes, and the kernel will (obviously)
>not
>> look at the older fields anyway, but it is good practice. The kernel
>or
>> any other entity is free to zero out the bytes past this length
>pointer.
>> 
>> There are only 24 bytes left in this structure, and this would occupy
>8
>> of them for no valid reason.  The *only* valid reason to put a
>> zero-initialized field in struct setup_header is if it used by the
>> 16-bit legacy BIOS boot, which is obviously not the case here.
>> 
>> This field thus belongs in struct boot_params, not struct
>setup_header.
>
>Would you be okay with putting acpi_rsdp_addr at offset 0x0cc (_pad4)?
>
>
>Juergen

I'd prefer if you used __pad3 offset 0x70 to keep the large block, and that way your field is also aligned.

However, if you have some specific reason to prefer __pad4 it's no big deal, although I'm curious what it would be.
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.