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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Kernel]     [Gnu Classpath]     [Gnu Crypto]     [DM Crypt]     [Netfilter]     [Bugtraq]
  Powered by Linux