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?
+/* SLR defined bootloaders */
+#define SLR_BOOTLOADER_INVALID 0
+#define SLR_BOOTLOADER_GRUB 1
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.
+} __packed;
Random nit - why are they all packed? Are there circumstances where two
pieces of code with different assumptions about alignment will be
looking at a single instance of a table? It doesn't seem likely we're
going to be doing DRTM in a 32-bit firmware environment while launching
a 64-bit kernel?
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.
[1] https://trenchboot.org/specifications/Secure_Launch/
v/r,
dps
_______________________________________________
kexec mailing list
kexec@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/kexec
