On Thu, Feb 15, 2024 at 08:56:25AM +0100, Ard Biesheuvel wrote: > On Wed, 14 Feb 2024 at 23:31, Ross Philipson <ross.philipson@xxxxxxxxxx> wrote: > > > > From: Arvind Sankar <nivedita@xxxxxxxxxxxx> > > > > There are use cases for storing the offset of a symbol in kernel_info. > > For example, the trenchboot series [0] needs to store the offset of the > > Measured Launch Environment header in kernel_info. > > > > Why? Is this information consumed by the bootloader? The bootloader stuffs this info, plus some offset IIRC, into special structure and finally it is consumed by SINIT ACM after GETSEC[SENTER] call. Sadly this data is Intel specific and it is even not compatible with AMD. So, if I am not mistaken, we will need additional member for the AMD in the kernel_info. > 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. 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. The other architectures may or may not have need for such data due to differences in DRTM implementation. Anyway, whatever we do I want to be sure the DRTM can be used on UEFI and non-UEFI platforms. So, I am not entirely convinced the address/pointer to additional DRTM data should be part of the MS-DOS and/or PE header. Though I am not against building something generic shared among various architectures either. Daniel
