Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Sun, 11 Nov 2018 15:58:16 -0800
User-Agent: K-9 Mail for Android
In-Reply-To: <685b425b-c816-4f65-3393-b48e59d170d8@suse.com>
References: <20181010061456.22238-1-jgross@suse.com> <20181010061456.22238-3-jgross@suse.com> <f7c78ee7-b548-7f04-24da-7321b6c64c97@zytor.com> <685b425b-c816-4f65-3393-b48e59d170d8@suse.com>
MIME-Version: 1.0
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: 8BIT
Subject: Re: PLEASE REVERT URGENTLY: Re: [PATCH v5 2/3] x86/boot: add acpi rsdp address to setup_header
To:     Juergen Gross <jgross@suse.com>, linux-kernel@vger.kernel.org,
        xen-devel@lists.xenproject.org, x86@kernel.org,
        linux-doc@vger.kernel.org
CC:     tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, corbet@lwn.net,
        boris.ostrovsky@oracle.com
From:   hpa@zytor.com
Message-ID: <9A44B94A-AEDC-4638-A8FF-DEE76FE34056@zytor.com>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On November 10, 2018 7:22:29 AM PST, Juergen Gross <jgross@suse.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.