[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [PATCH v2 1/5] docs: Introduce live patch signing
Remove a never-implemented description of live patch signing from the TODO section and document signing as implemented by the following patches. Signed-off-by: Ross Lagerwall <ross.lagerwall@xxxxxxxxxx> --- In v2: * Use ELF note type and descriptor length rather than a custom header. * Rename SIGNATURE_SUPPORTED_VERION docs/misc/livepatch.pandoc | 106 +++++++++++++++++++------------------ 1 file changed, 54 insertions(+), 52 deletions(-) diff --git a/docs/misc/livepatch.pandoc b/docs/misc/livepatch.pandoc index 04dd5ed7b271..f36de449e992 100644 --- a/docs/misc/livepatch.pandoc +++ b/docs/misc/livepatch.pandoc @@ -917,6 +917,60 @@ 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`. +The note type shall encode the signature version, algorithm, and hash: + +* version - uint16_t, bits 0-15 +* algorithm - uint8_t, bits 16-23 +* hash - uint8_t, bits 24-31 + +All other bits of the note type shall be zero. + +The known values for the above fields are: + + #define LIVEPATCH_SIGNATURE_VERSION 1 + #define SIGNATURE_ALGORITHM_RSA 0 + #define SIGNATURE_HASH_SHA256 0 + +The note descriptor length defines the length of the signature. + +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. However, it may be extended in future to support other +types of signatures and key types. + +Support of signatures in Xen and in live patches is optional. However, certain +features such as Secure Boot may require live patches to be signed. + ## Addendum @@ -1178,58 +1232,6 @@ the function itself. Similar considerations are true to a lesser extent for \__FILE__, but it could be argued that file renaming should be done outside of hotpatches. -## Signature checking requirements. - -The signature checking requires that the layout of the data in memory -**MUST** be same for signature to be verified. This means that the payload -data layout in ELF format **MUST** match what the hypervisor would be -expecting such that it can properly do signature verification. - -The signature is based on the all of the payloads continuously laid out -in memory. The signature is to be appended at the end of the ELF payload -prefixed with the string '`~Module signature appended~\n`', followed by -an signature header then followed by the signature, key identifier, and signers -name. - -Specifically the signature header would be: - - #define PKEY_ALGO_DSA 0 - #define PKEY_ALGO_RSA 1 - - #define PKEY_ID_PGP 0 /* OpenPGP generated key ID */ - #define PKEY_ID_X509 1 /* X.509 arbitrary subjectKeyIdentifier */ - - #define HASH_ALGO_MD4 0 - #define HASH_ALGO_MD5 1 - #define HASH_ALGO_SHA1 2 - #define HASH_ALGO_RIPE_MD_160 3 - #define HASH_ALGO_SHA256 4 - #define HASH_ALGO_SHA384 5 - #define HASH_ALGO_SHA512 6 - #define HASH_ALGO_SHA224 7 - #define HASH_ALGO_RIPE_MD_128 8 - #define HASH_ALGO_RIPE_MD_256 9 - #define HASH_ALGO_RIPE_MD_320 10 - #define HASH_ALGO_WP_256 11 - #define HASH_ALGO_WP_384 12 - #define HASH_ALGO_WP_512 13 - #define HASH_ALGO_TGR_128 14 - #define HASH_ALGO_TGR_160 15 - #define HASH_ALGO_TGR_192 16 - - struct elf_payload_signature { - u8 algo; /* Public-key crypto algorithm PKEY_ALGO_*. */ - u8 hash; /* Digest algorithm: HASH_ALGO_*. */ - u8 id_type; /* Key identifier type PKEY_ID*. */ - u8 signer_len; /* Length of signer's name */ - u8 key_id_len; /* Length of key identifier */ - u8 __pad[3]; - __be32 sig_len; /* Length of signature data */ - }; - -(Note that this has been borrowed from Linux module signature code.). - - ### .bss and .data sections. In place patching writable data is not suitable as it is unclear what should be done -- 2.49.0
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |