Re: [PATCH] docs: UEFI Secure Boot security policy

[Jan Beulich <jbeulich@xxxxxxxx>]

On 12.06.2025 23:32, Stefano Stabellini wrote:
> On Thu, 12 Jun 2025, Andrew Cooper wrote:
>> +Support in Xen
>> +--------------
>> +
>> +There are multiple ways to achieve this security goal, with differing
>> +tradeoffs for the eventual system.
>> +
>> +On one end of the spectrum is the Unified Kernel Image.  e.g. Xen is bundled
>> +with the dom0 kernel and init-ramdisk, with an embedded command line, and 
>> with
>> +livepatching and kexec compiled out, and suitably signed.  The signature is
>> +checked by the bootloader and, as this covers all the privileged code, Xen
>> +doesn't need to perform further checks itself.
>> +
>> +On the other end of the spectrum is maintaining the features of existing
>> +deployments.  e.g. Xen needs signature checking capabilities for the dom0
>> +kernel, livepatches and kexec kernels, and needs to allow the use of safe
>> +command line options while disallowing unsafe ones.
> 
> I just wanted to mention that there is one more option which I used in
> the past: the firmware/bootloader loads Xen, the Dom0 kernel, and other
> binaries, check their signatures, then boot Xen.
> 
> This is similar to the "Unified Kernel Image" approach in the sense that
> Xen doesn't need to do any signature checking for the dom0 kernel, but
> it doesn't require all the binaries to be glued together.
> 
> Assuming that the firmware/bootloader is capable of loading multiple
> binaries and checking the signature of multiple binaries before booting
> the next element, it works fine.

How would an initrd, a ucode blob, or an XSM policy blob be signed?

Jan