Re: [PATCH 1/4] docs: Introduce live patch signing

[Jan Beulich <jbeulich@xxxxxxxx>]

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 ...

> +    #define SIGNATURE_ALGORITHM_RSA 0
> +    #define SIGNATURE_HASH_SHA256 0

... these two be encoded in the note's type, instead of leaving that
effectively unused?

> +    struct payload_signature {
> +        uint16_t version;
> +        uint8_t algo;        /* Public-key crypto algorithm */
> +        uint8_t hash;        /* Digest algorithm */
> +        uint32_t sig_len;    /* Length of signature data */

Should there be a minimum length specified, to ensure security at least
for the moment (before e.g. quantum computers can break things)?

> +    };
> +
> +To sign a live patch:
> +
> +1) Add a new note section with a populated payload signature and zeroed out
> +   signature.
> +2) Generate a detached signature over the entire binary.
> +3) Fill in the signature in the note section.
> +
> +During live patch load, Xen shall verify the signature using the following
> +steps:
> +
> +1) Copy the signature out of the note section.
> +2) Zero the signature.
> +3) Generate a detached signature over the entire binary.
> +4) Compare against the signature from (1).
> +
> +Initially, to avoid including DER / X.509 parsing of certificates, handling
> +chains, etc. Xen shall verify signatures against a compiled in RSA key in
> +exponent/modulus form.

And this is sufficient to satisfy (Microsoft's?) requirements?

Jan