Re: [PATCH v2 20/22] x86/slaunch: support EFI boot

[Demi Marie Obenour <demiobenour@xxxxxxxxx>]

On 5/14/25 10:24 AM, Sergii Dmytruk wrote:
> On Tue, May 13, 2025 at 09:25:44PM -0400, Demi Marie Obenour wrote:
>> On 5/13/25 1:05 PM, Sergii Dmytruk wrote:
>>> When running on an EFI-enabled system, Xen needs to have access to Boot
>>> Services in order to initialize itself properly and reach a state in
>>> which a dom0 kernel can operate without issues.
>>>
>>> This means that DRTM must be started in the middle of Xen's
>>> initialization process.  This effect is achieved via a callback into
>>> bootloader (GRUB) which is responsible for initiating DRTM and
>>> continuing Xen's initialization process.  The latter is done by
>>> branching in Slaunch entry point on a flag to switch back into long mode
>>> before calling the same function which Xen would execute as the next
>>> step without DRTM.
>>
>> Depending on the bootloader for this unnecessarily ties DRTM to GRUB.
>> Instead, it would be much better for Xen to be able to perform DRTM
>> itself, which would allow DRTM to work without GRUB.  Pop! OS already
>> uses systemd-boot and the trend seems to be from GRUB to systemd-boot.
>> Furthermore, this would allow DRTM with Xen launched directly from
>> the UEFI firmware.
>> --
>> Sincerely,
>> Demi Marie Obenour (she/her/hers)
> 
> That sentence in the commit message is worth rewording.  GRUB isn't a
> requirement, any TrenchBoot-enabled bootloader (or anything that wants
> to act as a bootloader) can be used.  systemd-boot could implement
> Secure Launch specification [0] and start Xen/Linux/something else via
> DRTM.  Usage without a real bootloader could be implemented similarly
> via some EFI stub that has binaries embedded into it or that can load
> them from a drive.
> 
> Mind that at least Intel and AMD DRTM implementations require a DCE [1]
> binary that depends on a vendor, firmware version or a CPU generation.
> So even embedding all code into every kernel-like software won't produce
> self-contained DRTM-capable images.
> 
> [0]: https://trenchboot.org/specifications/Secure_Launch/
> [1]: 
> https://trenchboot.org/theory/Glossary/#dynamic-configuration-environment-dce

Why is it better for Xen to rely on the bootloader to implement the
specification, instead of xen.efi itself implementing secure launch?
That would make secure launch significantly more usable.  For an
initial implementation it makes sense to rely on the bootloader, but
in the future it would be better for xen.efi to have its own
implementation.

Is the code being added to GRUB for secure launch under a license
that would allow it to be used in Xen as well?
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)

Attachment: OpenPGP_0xB288B55FFF9C22C1.asc
Description: OpenPGP public key

Attachment: OpenPGP_signature.asc
Description: OpenPGP digital signature