All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Daniel P. Smith" <dpsmith@apertussolutions.com>
To: "H. Peter Anvin" <hpa@zytor.com>,
	Ard Biesheuvel <ardb@kernel.org>,
	Ross Philipson <ross.philipson@oracle.com>
Cc: linux-kernel@vger.kernel.org, x86@kernel.org,
	linux-integrity@vger.kernel.org, linux-doc@vger.kernel.org,
	linux-crypto@vger.kernel.org, kexec@lists.infradead.org,
	linux-efi@vger.kernel.org, tglx@linutronix.de, mingo@redhat.com,
	bp@alien8.de, dave.hansen@linux.intel.com, mjg59@srcf.ucam.org,
	James.Bottomley@hansenpartnership.com, peterhuewe@gmx.de,
	jarkko@kernel.org, jgg@ziepe.ca, luto@amacapital.net,
	nivedita@alum.mit.edu, herbert@gondor.apana.org.au,
	davem@davemloft.net, kanth.ghatraju@oracle.com,
	trenchboot-devel@googlegroups.com
Subject: Re: [PATCH v8 01/15] x86/boot: Place kernel_info at a fixed offset
Date: Fri, 22 Mar 2024 21:33:41 -0400	[thread overview]
Message-ID: <e52bbf77-4a80-4ebd-88f2-39e9b4063044@apertussolutions.com> (raw)
In-Reply-To: <32FDA47A-C87F-406F-A0B9-3AA1BB2EBAFB@zytor.com>

On 3/22/24 10:18, H. Peter Anvin wrote:
> On March 21, 2024 6:45:48 AM PDT, "Daniel P. Smith" <dpsmith@apertussolutions.com> wrote:
>> Hi Ard!
>>
>> On 2/15/24 02:56, Ard Biesheuvel wrote:
>>> On Wed, 14 Feb 2024 at 23:31, Ross Philipson <ross.philipson@oracle.com> wrote:
>>>>
>>>> From: Arvind Sankar <nivedita@alum.mit.edu>
>>>>
>>>> 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
> 
> To be fair, the way things are going UEFI, i.e. PE/COFF, is becoming the new standard format. Yes, ELF would have been better, but...

Fully agree with the ELF sentiment. We started looking to see if PE/COFF 
has something similar to a ELF NOTE, but figured maybe this has been 
solved for other cases. If that is not the case or there are not any 
suggestions, then we can see what we can devise.

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

WARNING: multiple messages have this Message-ID (diff)
From: "Daniel P. Smith" <dpsmith@apertussolutions.com>
To: "H. Peter Anvin" <hpa@zytor.com>,
	Ard Biesheuvel <ardb@kernel.org>,
	Ross Philipson <ross.philipson@oracle.com>
Cc: linux-kernel@vger.kernel.org, x86@kernel.org,
	linux-integrity@vger.kernel.org, linux-doc@vger.kernel.org,
	linux-crypto@vger.kernel.org, kexec@lists.infradead.org,
	linux-efi@vger.kernel.org, tglx@linutronix.de, mingo@redhat.com,
	bp@alien8.de, dave.hansen@linux.intel.com, mjg59@srcf.ucam.org,
	James.Bottomley@hansenpartnership.com, peterhuewe@gmx.de,
	jarkko@kernel.org, jgg@ziepe.ca, luto@amacapital.net,
	nivedita@alum.mit.edu, herbert@gondor.apana.org.au,
	davem@davemloft.net, kanth.ghatraju@oracle.com,
	trenchboot-devel@googlegroups.com
Subject: Re: [PATCH v8 01/15] x86/boot: Place kernel_info at a fixed offset
Date: Fri, 22 Mar 2024 21:33:41 -0400	[thread overview]
Message-ID: <e52bbf77-4a80-4ebd-88f2-39e9b4063044@apertussolutions.com> (raw)
In-Reply-To: <32FDA47A-C87F-406F-A0B9-3AA1BB2EBAFB@zytor.com>

On 3/22/24 10:18, H. Peter Anvin wrote:
> On March 21, 2024 6:45:48 AM PDT, "Daniel P. Smith" <dpsmith@apertussolutions.com> wrote:
>> Hi Ard!
>>
>> On 2/15/24 02:56, Ard Biesheuvel wrote:
>>> On Wed, 14 Feb 2024 at 23:31, Ross Philipson <ross.philipson@oracle.com> wrote:
>>>>
>>>> From: Arvind Sankar <nivedita@alum.mit.edu>
>>>>
>>>> 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
> 
> To be fair, the way things are going UEFI, i.e. PE/COFF, is becoming the new standard format. Yes, ELF would have been better, but...

Fully agree with the ELF sentiment. We started looking to see if PE/COFF 
has something similar to a ELF NOTE, but figured maybe this has been 
solved for other cases. If that is not the case or there are not any 
suggestions, then we can see what we can devise.

  reply	other threads:[~2024-03-23  1:34 UTC|newest]

Thread overview: 116+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-14 22:18 [PATCH v8 00/15] x86: Trenchboot secure dynamic launch Linux kernel support Ross Philipson
2024-02-14 22:18 ` Ross Philipson
2024-02-14 22:18 ` [PATCH v8 01/15] x86/boot: Place kernel_info at a fixed offset Ross Philipson
2024-02-14 22:18   ` Ross Philipson
2024-02-15  7:56   ` Ard Biesheuvel
2024-02-15  7:56     ` Ard Biesheuvel
2024-02-15 10:56     ` Daniel Kiper
2024-02-15 10:56       ` Daniel Kiper
2024-03-21 13:45     ` Daniel P. Smith
2024-03-21 13:45       ` Daniel P. Smith
2024-03-22 14:18       ` H. Peter Anvin
2024-03-22 14:18         ` H. Peter Anvin
2024-03-23  1:33         ` Daniel P. Smith [this message]
2024-03-23  1:33           ` Daniel P. Smith
2024-02-14 22:18 ` [PATCH v8 02/15] Documentation/x86: Secure Launch kernel documentation Ross Philipson
2024-02-14 22:18   ` Ross Philipson
2024-02-14 22:18 ` [PATCH v8 03/15] x86: Secure Launch Kconfig Ross Philipson
2024-02-14 22:18   ` Ross Philipson
2024-02-15  7:59   ` Ard Biesheuvel
2024-02-15  7:59     ` Ard Biesheuvel
2024-02-15 22:20     ` ross.philipson
2024-02-15 22:20       ` ross.philipson
2024-02-14 22:18 ` [PATCH v8 04/15] x86: Secure Launch Resource Table header file Ross Philipson
2024-02-14 22:18   ` Ross Philipson
2024-02-15  8:08   ` Ard Biesheuvel
2024-02-15  8:08     ` Ard Biesheuvel
2024-02-22  2:03     ` Andrew Cooper
2024-02-22  2:03       ` Andrew Cooper
2024-02-22  2:10       ` ross.philipson
2024-02-22  2:10         ` ross.philipson
2024-02-22 17:49     ` ross.philipson
2024-02-22 17:49       ` ross.philipson
2024-03-29 22:38   ` Kim Phillips
2024-03-29 22:38     ` Kim Phillips
2024-03-29 22:38     ` Kim Phillips
2024-03-29 22:38     ` Kim Phillips
2024-03-29 22:38     ` Kim Phillips
2024-03-29 22:38     ` Kim Phillips
2024-04-01 18:25     ` ross.philipson
2024-04-01 18:25       ` ross.philipson
2024-02-14 22:18 ` [PATCH v8 05/15] x86: Secure Launch main " Ross Philipson
2024-02-14 22:18   ` Ross Philipson
2024-02-14 22:18 ` [PATCH v8 06/15] x86: Add early SHA support for Secure Launch early measurements Ross Philipson
2024-02-14 22:18   ` Ross Philipson
2024-02-15  8:17   ` Ard Biesheuvel
2024-02-15  8:17     ` Ard Biesheuvel
2024-02-22  3:04     ` Andrew Cooper
2024-02-22  3:04       ` Andrew Cooper
2024-02-22  9:34       ` Ard Biesheuvel
2024-02-22  9:34         ` Ard Biesheuvel
2024-02-22 12:30         ` Andrew Cooper
2024-02-22 12:30           ` Andrew Cooper
2024-02-23  9:27           ` Ard Biesheuvel
2024-02-23  9:27             ` Ard Biesheuvel
2024-02-23 16:42             ` Andrew Cooper
2024-02-23 16:42               ` Andrew Cooper
2024-02-23 17:54               ` Eric Biggers
2024-02-23 17:54                 ` Eric Biggers
2024-02-23 18:20                 ` Andrew Cooper
2024-02-23 18:20                   ` Andrew Cooper
2024-02-23 18:30                   ` Eric Biggers
2024-02-23 18:30                     ` Eric Biggers
2024-04-03 16:32                     ` Andy Lutomirski
2024-04-03 16:32                       ` Andy Lutomirski
2024-04-03 23:56                       ` Eric Biggers
2024-04-03 23:56                         ` Eric Biggers
2024-04-04  4:55                         ` ross.philipson
2024-04-04  4:55                           ` ross.philipson
2024-04-04 14:55                         ` Jarkko Sakkinen
2024-04-04 14:55                           ` Jarkko Sakkinen
2024-02-14 22:18 ` [PATCH v8 07/15] x86: Secure Launch kernel early boot stub Ross Philipson
2024-02-14 22:18   ` Ross Philipson
2024-02-15  8:29   ` Ard Biesheuvel
2024-02-15  8:29     ` Ard Biesheuvel
2024-02-15 22:26     ` ross.philipson
2024-02-15 22:26       ` ross.philipson
2024-02-14 22:18 ` [PATCH v8 08/15] x86: Secure Launch kernel late " Ross Philipson
2024-02-14 22:18   ` Ross Philipson
2024-02-14 22:18 ` [PATCH v8 09/15] x86: Secure Launch SMP bringup support Ross Philipson
2024-02-14 22:18   ` Ross Philipson
2024-02-14 22:18 ` [PATCH v8 10/15] kexec: Secure Launch kexec SEXIT support Ross Philipson
2024-02-14 22:18   ` Ross Philipson
2024-02-14 22:18 ` [PATCH v8 11/15] reboot: Secure Launch SEXIT support on reboot paths Ross Philipson
2024-02-14 22:18   ` Ross Philipson
2024-02-14 22:18 ` [PATCH v8 12/15] tpm: Add ability to set the preferred locality the TPM chip uses Ross Philipson
2024-02-14 22:18   ` Ross Philipson
2024-02-14 22:18 ` [PATCH v8 13/15] tpm: Add sysfs interface to allow setting and querying the preferred locality Ross Philipson
2024-02-14 22:18   ` Ross Philipson
2024-02-14 22:18 ` [PATCH v8 14/15] x86: Secure Launch late initcall platform module Ross Philipson
2024-02-14 22:18   ` Ross Philipson
2024-02-15  8:40   ` Ard Biesheuvel
2024-02-15  8:40     ` Ard Biesheuvel
2024-02-22 13:57     ` Daniel P. Smith
2024-02-22 13:57       ` Daniel P. Smith
2024-02-23  9:36       ` Ard Biesheuvel
2024-02-23  9:36         ` Ard Biesheuvel
2024-03-21 14:11         ` Daniel P. Smith
2024-03-21 14:11           ` Daniel P. Smith
2024-02-16  1:53   ` kernel test robot
2024-02-16  1:53     ` kernel test robot
2024-02-17  7:53   ` kernel test robot
2024-02-17  7:53     ` kernel test robot
2024-02-14 22:18 ` [PATCH v8 15/15] x86: EFI stub DRTM launch support for Secure Launch Ross Philipson
2024-02-14 22:18   ` Ross Philipson
2024-02-15  9:01   ` Ard Biesheuvel
2024-02-15  9:01     ` Ard Biesheuvel
2024-02-21 20:17     ` ross.philipson
2024-02-21 20:17       ` ross.philipson
2024-02-21 20:37       ` H. Peter Anvin
2024-02-21 20:37         ` H. Peter Anvin
2024-02-21 23:24         ` Ard Biesheuvel
2024-02-21 23:24           ` Ard Biesheuvel
2024-02-17  7:31   ` kernel test robot
2024-02-17  7:31     ` kernel test robot
2024-02-17 20:06   ` kernel test robot
2024-02-17 20:06     ` kernel test robot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=e52bbf77-4a80-4ebd-88f2-39e9b4063044@apertussolutions.com \
    --to=dpsmith@apertussolutions.com \
    --cc=James.Bottomley@hansenpartnership.com \
    --cc=ardb@kernel.org \
    --cc=bp@alien8.de \
    --cc=dave.hansen@linux.intel.com \
    --cc=davem@davemloft.net \
    --cc=herbert@gondor.apana.org.au \
    --cc=hpa@zytor.com \
    --cc=jarkko@kernel.org \
    --cc=jgg@ziepe.ca \
    --cc=kanth.ghatraju@oracle.com \
    --cc=kexec@lists.infradead.org \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-efi@vger.kernel.org \
    --cc=linux-integrity@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@amacapital.net \
    --cc=mingo@redhat.com \
    --cc=mjg59@srcf.ucam.org \
    --cc=nivedita@alum.mit.edu \
    --cc=peterhuewe@gmx.de \
    --cc=ross.philipson@oracle.com \
    --cc=tglx@linutronix.de \
    --cc=trenchboot-devel@googlegroups.com \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.