On Mon, May 15, 2023 at 05:15:15PM -0400, Daniel P. Smith wrote: > On 5/12/23 06:55, Matthew Garrett wrote: > > On Thu, May 04, 2023 at 02:50:13PM +0000, Ross Philipson wrote: > > > > > +#define SLR_TABLE_MAGIC 0x4452544d > > > > From convention I'd expect this to be 0x534c5254, but not really an > > issue. > > Apologies, but which convention? Tables in ACPI and UEFI tend to have magic that corresponds to their name, so a table called SLRT would tend to have magic that matches the ASCII values for that. In this case the SLRT has DRTM as its magic, which is a touch unexpected. > > Oof. Having the kernel know about bootloaders has not worked out super > > well for us in the past. If someone writes a new bootloader, are they > > unable to Secure Launch any existing kernels? The pragmatic thing for > > them to do would be to just pretend they're grub, which kind of defeats > > the point of having this definition... > > Actually, this is not for making the kernel know about bootloaders. This is > dealing with the challenge created when the preamble was split for efi-stub, > and similar use cases, where what sets up the preamble, ie. the bootloader, > is separate from what invokes the dynamic launch, ie. the DLE handler. The > reality is that even in the simplest implementation of the DLE handler, a > remnant of GRUB for call back from efi-stub, there is information that is > needed to cross the gap. What if I don't use grub, but use something that behaves equivalently? Which value should be used here? > We wrote the TrenchBoot Secure Launch general spec [1] with as much > forethought as possible for the target environments. Specifically, the > desire is to have a common approach for x86 (Intel and AMD), Arm, and > perhaps down the road the POWER arch. In particular, I do not believe there > is anything in the Arm DRTM beta spec that prohibits a mixed 32/64 bit > environment. In the end it is better to for the spec to be safe for those > environments then having to make changes to the spec later down the road. Ok. _______________________________________________ kexec mailing list kexec@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/kexec
