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

[Jan Beulich <jbeulich@xxxxxxxx>]

On 13.05.2025 11:04, Ross Lagerwall wrote:
> On Mon, May 12, 2025 at 1:19 PM Jan Beulich <jbeulich@xxxxxxxx> 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