On 12/8/2025 1:32 PM, Zhuoying Cai wrote:
From: Collin Walling <[email protected]>
DIAG 508 subcode 1 performs signature-verification on signed components.
A signed component may be a Linux kernel image, or any other signed
binary. **Verification of initrd is not supported.**
The instruction call expects two item-pairs: an address of a device
component, an address of the analogous signature file (in PKCS#7 DER format),
and their respective lengths. All of this data should be encapsulated
within a Diag508SigVerifBlock.
The DIAG handler will read from the provided addresses
to retrieve the necessary data, parse the signature file, then
perform the signature-verification. Because there is no way to
correlate a specific certificate to a component, each certificate
in the store is tried until either verification succeeds, or all
certs have been exhausted.
A return code of 1 indicates success, and the index and length of the
corresponding certificate will be set in the Diag508SigVerifBlock.
The following values indicate failure:
0x0102: no certificates are available in the store
0x0202: component data is invalid
0x0302: PKCS#7 format signature is invalid
0x0402: signature-verification failed
0x0502: length of Diag508SigVerifBlock is invalid
Signed-off-by: Collin Walling <[email protected]>
Signed-off-by: Zhuoying Cai <[email protected]>
---
docs/specs/s390x-secure-ipl.rst | 17 ++++++
include/hw/s390x/ipl/diag508.h | 26 ++++++++
target/s390x/diag.c | 103 +++++++++++++++++++++++++++++++-
3 files changed, 145 insertions(+), 1 deletion(-)
diff --git a/docs/specs/s390x-secure-ipl.rst b/docs/specs/s390x-secure-ipl.rst
index 84a1691e1b..be98dc143d 100644
--- a/docs/specs/s390x-secure-ipl.rst
+++ b/docs/specs/s390x-secure-ipl.rst
@@ -69,3 +69,20 @@ that requires assistance from QEMU.
Subcode 0 - query installed subcodes
Returns a 64-bit mask indicating which subcodes are supported.
+
+Subcode 1 - perform signature verification
+ Perform signature-verification on a signed component, using certificates
+ from the certificate store and leveraging qcrypto libraries to perform
+ this operation.
+
+ Note: verification of initrd is not supported.
+
+ A return code of 1 indicates success, and the index and length of the
+ corresponding certificate will be set in the Diag508SigVerifBlock.
+ The following values indicate failure:
+
+ * ``0x0102``: no certificates are available in the store
+ * ``0x0202``: component data is invalid
+ * ``0x0302``: PKCS#7 format signature is invalid
+ * ``0x0402``: signature-verification failed
+ * ``0x0502``: length of Diag508SigVerifBlock is invalid
diff --git a/include/hw/s390x/ipl/diag508.h b/include/hw/s390x/ipl/diag508.h
index 6281ad8299..9c493f7273 100644
--- a/include/hw/s390x/ipl/diag508.h
+++ b/include/hw/s390x/ipl/diag508.h
@@ -11,5 +11,31 @@
#define S390X_DIAG508_H
#define DIAG_508_SUBC_QUERY_SUBC 0x0000
+#define DIAG_508_SUBC_SIG_VERIF 0x8000
+
+#define DIAG_508_RC_OK 0x0001
+#define DIAG_508_RC_NO_CERTS 0x0102
+#define DIAG_508_RC_INVAL_COMP_DATA 0x0202
+#define DIAG_508_RC_INVAL_PKCS7_SIG 0x0302
+#define DIAG_508_RC_FAIL_VERIF 0x0402
+#define DIAG_508_RC_INVAL_LEN 0x0502
+
+#define DIAG_508_MAX_COMP_LEN 0x10000000
+#define DIAG_508_MAX_SIG_LEN 4096
+
Based on my understanding, these values for component and signature
length are based on the max that is possible today (v6 discussion
https://lore.kernel.org/all/[email protected]/).
These values are not defined in the architecture and its possible we may
have to update them in the future.Maybe we can add a comment for this?
<..snip..>
+static int handle_diag508_sig_verif(uint64_t addr)
+{
+ int verified;
+ uint32_t svb_len;
+ uint64_t comp_len, comp_addr;
+ uint64_t sig_len, sig_addr;
+ g_autofree uint8_t *comp = NULL;
+ g_autofree uint8_t *sig = NULL;
+ g_autofree Diag508SigVerifBlock *svb = NULL;
+ size_t svb_size = sizeof(Diag508SigVerifBlock);
+ S390IPLCertificateStore *qcs = s390_ipl_get_certificate_store();
+
+ if (!qcs->count) {
+ return DIAG_508_RC_NO_CERTS;
+ }
+
+ svb = g_new0(Diag508SigVerifBlock, 1);
+ cpu_physical_memory_read(addr, svb, svb_size);
+
+ svb_len = be32_to_cpu(svb->length);
+ if (svb_len != svb_size) {
+ return DIAG_508_RC_INVAL_LEN;
+ }
+
+ comp_len = be64_to_cpu(svb->comp_len);
+ comp_addr = be64_to_cpu(svb->comp_addr);
+ sig_len = be64_to_cpu(svb->sig_len);
+ sig_addr = be64_to_cpu(svb->sig_addr);
+
+ if (!comp_len || comp_len > DIAG_508_MAX_COMP_LEN || !comp_addr) {
+ return DIAG_508_RC_INVAL_COMP_DATA;
+ }
+
+ if (!sig_len || sig_len > DIAG_508_MAX_SIG_LEN || !sig_addr) {
+ return DIAG_508_RC_INVAL_PKCS7_SIG;
+ }
And maybe a warning to indicate the failure is due to
signature/component length being larger than our currently defined ones?
+
+ comp = g_malloc0(comp_len);
+ cpu_physical_memory_read(comp_addr, comp, comp_len);
+
+ sig = g_malloc0(sig_len);
+ cpu_physical_memory_read(sig_addr, sig, sig_len);
+
+ for (int i = 0; i < qcs->count; i++) {
+ verified = diag_508_verify_sig(qcs->certs[i].raw,
+ qcs->certs[i].size,
+ comp, comp_len,
+ sig, sig_len);
+ if (verified) {
+ svb->cert_store_index = i;
+ svb->cert_len = cpu_to_be64(qcs->certs[i].der_size);
+ cpu_physical_memory_write(addr, svb, svb_size);
+ return DIAG_508_RC_OK;
+ }
+ }
+
+ return DIAG_508_RC_FAIL_VERIF;
+}
+
;
<..snip..>
