On 13.05.2025 11:04, Ross Lagerwall wrote: > On Mon, May 12, 2025 at 1:19 PM Jan Beulich <jbeul...@suse.com> wrote: >> >> On 09.05.2025 18:18, Ross Lagerwall wrote: >>> --- a/docs/misc/livepatch.pandoc >>> +++ b/docs/misc/livepatch.pandoc >>> @@ -917,6 +917,58 @@ The normal sequence of events is to: >>> 3. *XEN_SYSCTL_LIVEPATCH_ACTION* with *LIVEPATCH_ACTION_APPLY* to apply >>> the patch. >>> 4. *XEN_SYSCTL_LIVEPATCH_GET* to check the `->rc`. If in *-XEN_EAGAIN* >>> spin. If zero exit with success. >>> >>> +## Signature Checking >>> + >>> +While loading live patches would generally be restricted to a privileged >>> +process in dom0, in certain cases signature checking in Xen may be >>> required. >>> +For example, when Secure Boot is enabled live patches need to be verified >>> +before being loaded. >>> + >>> +Xen live patches are ELF binaries but there is no standardized mechanism >>> for >>> +signing ELF binaries. One approach used by Linux is to append a signature >>> to >>> +the end of the binary, outside of the ELF container. While this works, it >>> tends >>> +to be fragile since tools that handle ELF binaries do not correctly handle >>> the >>> +signature. Instead, the approach taken here is to use an ELF note for the >>> +signature. >>> + >>> +The ELF note section name shall be `.note.Xen.signature` with note name >>> `Xen` >>> +and type `0`. >>> + >>> +The note data shall contain a header followed by the signature data: >>> + >>> + #define SIGNATURE_SUPPORTED_VERION 1 >> >> I don't think this is a good name (leaving aside the typo); conceptually >> multiple versions could be supported. Otoh live patches are hypervisor >> build specific anyway, so it's hard to see why a version would be needed >> in the first place. Alternatively should version or ... > > How about LIVEPATCH_SIGNATURE_VERSION (analogous to > LIVEPATCH_PAYLOAD_VERSION)?
Fine with me. Jan
