Hi Ard!
On 2/15/24 02:56, 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?
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
order to set up for and start the loaded kernel. Arm will also need to
provide a similar metadata structure and alternative entry point (or a
complete rewrite of the existing entry point), as the current Arm entry
point is in direct conflict with Arm DRTM specification.
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.
With all due respect, I would not refer to boot params and the kern_info
extension designed by the x86 maintainers as a hack. It is the
well-defined boot protocol for x86, just as Arm has its own boot
protocol around Device Tree.
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
bootloader. Otherwise, we are relegated to doing a per arch/per image
type discovery mechanism. If you have any suggestions that are cross
arch/cross image type that we could explore, we would be grateful and
willing to investigate how to adopt such a method.
V/r,
Daniel
_______________________________________________
kexec mailing list
kexec@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/kexec
