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
