lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 22 Mar 2024 21:33:41 -0400
From: "Daniel P. Smith" <dpsmith@...rtussolutions.com>
To: "H. Peter Anvin" <hpa@...or.com>, Ard Biesheuvel <ardb@...nel.org>,
 Ross Philipson <ross.philipson@...cle.com>
Cc: linux-kernel@...r.kernel.org, x86@...nel.org,
 linux-integrity@...r.kernel.org, linux-doc@...r.kernel.org,
 linux-crypto@...r.kernel.org, kexec@...ts.infradead.org,
 linux-efi@...r.kernel.org, tglx@...utronix.de, mingo@...hat.com,
 bp@...en8.de, dave.hansen@...ux.intel.com, mjg59@...f.ucam.org,
 James.Bottomley@...senpartnership.com, peterhuewe@....de, jarkko@...nel.org,
 jgg@...pe.ca, luto@...capital.net, nivedita@...m.mit.edu,
 herbert@...dor.apana.org.au, davem@...emloft.net, kanth.ghatraju@...cle.com,
 trenchboot-devel@...glegroups.com
Subject: Re: [PATCH v8 01/15] x86/boot: Place kernel_info at a fixed offset

On 3/22/24 10:18, H. Peter Anvin wrote:
> On March 21, 2024 6:45:48 AM PDT, "Daniel P. Smith" <dpsmith@...rtussolutions.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@...cle.com> wrote:
>>>>
>>>> From: Arvind Sankar <nivedita@...m.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.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ