Re: [PATCH v8 01/15] x86/boot: Place kernel_info at a fixed offset

[Daniel P. Smith]

On 8/28/24 13:45, Ard Biesheuvel wrote:
> (cc Stuart)
>
> On Thu, 21 Mar 2024 at 15:46, Daniel P. Smith
> <dpsmith@xxxxxxxxxxxxxxxxxxxx> wrote:
> > 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.
>
> Digging up an old thread here: could you elaborate on this? What do
> you mean by 'Arm entry point' and how does it conflict directly with
> the Arm DRTM specification? The Linux/arm64 port predates that spec by
> about 10 years, so I would expect the latter to take the former into
> account. If that failed to happen, we should fix the spec while we
> still can.

Yes, we have been working with Stuart regarding the specification and 
crafting a compliant implementation approach. It is still very early 
days, we are attempting to draft a plan around the specification with no 
physical implementation to validate against. After some discussion, the 
concern that a separate entry point may be needed has faded and in fact 
it likely will not be needed. As always, the devil is in the details, 
and until we have a hardware that has implemented the specification, and 
we attempt to light it up, we won't know what will be needed for the 
implementation.

In short, at this point it was determined no update to the DRTM spec is 
needed. As hardware becomes available, and we do battle with it, Stuart 
will be kept up to date. We will work with him to ensure any changes are 
captured that will help reduce chances that vendors and developers do 
not misinterpret the spec.

V/r,
Daniel P. Smith