Received-SPF: pass (google.com: domain of linux-crypto+bounces-2826-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1;
Date: Fri, 22 Mar 2024 07:18:58 -0700
From: "H. Peter Anvin" <hpa@zytor.com>
To: "Daniel P. Smith" <dpsmith@apertussolutions.com>,
        Ard Biesheuvel <ardb@kernel.org>,
        Ross Philipson <ross.philipson@oracle.com>
CC: linux-kernel@vger.kernel.org, x86@kernel.org,
        linux-integrity@vger.kernel.org, linux-doc@vger.kernel.org,
        linux-crypto@vger.kernel.org, kexec@lists.infradead.org,
        linux-efi@vger.kernel.org, tglx@linutronix.de, mingo@redhat.com,
        bp@alien8.de, dave.hansen@linux.intel.com, mjg59@srcf.ucam.org,
        James.Bottomley@hansenpartnership.com, peterhuewe@gmx.de,
        jarkko@kernel.org, jgg@ziepe.ca, luto@amacapital.net,
        nivedita@alum.mit.edu, herbert@gondor.apana.org.au,
        davem@davemloft.net, kanth.ghatraju@oracle.com,
        trenchboot-devel@googlegroups.com
Subject: Re: [PATCH v8 01/15] x86/boot: Place kernel_info at a fixed offset
User-Agent: K-9 Mail for Android
In-Reply-To: <9d01a6d2-4dd9-4331-8fc9-b01c07cfdbb5@apertussolutions.com>
References: <20240214221847.2066632-1-ross.philipson@oracle.com> <20240214221847.2066632-2-ross.philipson@oracle.com> <CAMj1kXH3Gvr3vDRLDdXuc0s7ZAQYE6+D7tmCRBjJWwWt2fn4-w@mail.gmail.com> <9d01a6d2-4dd9-4331-8fc9-b01c07cfdbb5@apertussolutions.com>
Message-ID: <32FDA47A-C87F-406F-A0B9-3AA1BB2EBAFB@zytor.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable

On March 21, 2024 6:45:48 AM PDT, "Daniel P=2E Smith" <dpsmith@apertussolut=
ions=2Ecom> wrote:
>Hi Ard!
>
>On 2/15/24 02:56, Ard Biesheuvel wrote:
>> On Wed, 14 Feb 2024 at 23:31, Ross Philipson <ross=2Ephilipson@oracle=
=2Ecom> wrote:
>>>=20
>>> From: Arvind Sankar <nivedita@alum=2Emit=2Eedu>
>>>=20
>>> There are use cases for storing the offset of a symbol in kernel_info=
=2E
>>> For example, the trenchboot series [0] needs to store the offset of th=
e
>>> Measured Launch Environment header in kernel_info=2E
>>>=20
>>=20
>> Why? Is this information consumed by the bootloader?
>
>Yes, the bootloader needs a standardized means to find the offset of the =
MLE header, which communicates a set of meta-data needed by the DCE in orde=
r to set up for and start the loaded kernel=2E Arm will also need to provid=
e a similar metadata structure and alternative entry point (or a complete r=
ewrite of the existing entry point), as the current Arm entry point is in d=
irect conflict with Arm DRTM specification=2E
>
>> I'd like to get away from x86 specific hacks for boot code and boot
>> images, so I would like to explore if we can avoid kernel_info, or at
>> least expose it in a generic way=2E We might just add a 32-bit offset
>> somewhere in the first 64 bytes of the bootable image: this could
>> co-exist with EFI bootable images, and can be implemented on arm64,
>> RISC-V and LoongArch as well=2E
>
>With all due respect, I would not refer to boot params and the kern_info =
extension designed by the x86 maintainers as a hack=2E It is the well-defin=
ed boot protocol for x86, just as Arm has its own boot protocol around Devi=
ce Tree=2E
>
>We would gladly adopt a cross arch/cross image type, zImage and bzImage, =
means to embedded meta-data about the kernel that can be discovered by a bo=
otloader=2E Otherwise, we are relegated to doing a per arch/per image type =
discovery mechanism=2E If you have any suggestions that are cross arch/cros=
s image type that we could explore, we would be grateful and willing to inv=
estigate how to adopt such a method=2E
>
>V/r,
>Daniel

To be fair, the way things are going UEFI, i=2Ee=2E PE/COFF, is becoming t=
he new standard format=2E Yes, ELF would have been better, but=2E=2E=2E