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
