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