On 27/08/2025 23.49, Farhan Ali wrote:
On 8/18/2025 2:43 PM, Zhuoying Cai wrote:
DIAG 320 subcode 1 provides information needed to determine
the amount of storage to store one or more certificates from the
certificate store.
Upon successful completion, this subcode returns information of the current
cert store, such as the number of certificates stored and allowed in the cert
store, amount of space may need to be allocate to store a certificate,
etc for verification-certificate blocks (VCBs).
The subcode value is denoted by setting the left-most bit
of an 8-byte field.
The verification-certificate-storage-size block (VCSSB) contains
the output data when the operation completes successfully. A VCSSB
length of 4 indicates that no certificate are available in the cert
store.
Signed-off-by: Zhuoying Cai <zy...@linux.ibm.com>
---
docs/specs/s390x-secure-ipl.rst | 10 ++++++
include/hw/s390x/ipl/diag320.h | 22 +++++++++++++
target/s390x/diag.c | 56 ++++++++++++++++++++++++++++++++-
3 files changed, 87 insertions(+), 1 deletion(-)
diff --git a/docs/specs/s390x-secure-ipl.rst b/docs/specs/s390x-secure-
ipl.rst
index 70e9a66fe0..ddc15f0322 100644
--- a/docs/specs/s390x-secure-ipl.rst
+++ b/docs/specs/s390x-secure-ipl.rst
@@ -23,3 +23,13 @@ Subcode 0 - query installed subcodes
Returns a 256-bit installed subcodes mask (ISM) stored in the installed
subcodes block (ISB). This mask indicates which sucodes are currently
installed and available for use.
+
+Subcode 1 - query verification certificate storage information
+ Provides the information required to determine the amount of memory
needed to
+ store one or more verification-certificates (VCs) from the
certificate store (CS).
+
+ Upon successful completion, this subcode returns various storage size
values for
+ verification-certificate blocks (VCBs).
+
+ The output is returned in the verification-certificate-storage-size
block (VCSSB).
+ A VCSSB length of 4 indicates that no certificates are available in
the CS.
diff --git a/include/hw/s390x/ipl/diag320.h b/include/hw/s390x/ipl/diag320.h
index aa04b699c6..6e4779c699 100644
--- a/include/hw/s390x/ipl/diag320.h
+++ b/include/hw/s390x/ipl/diag320.h
@@ -11,10 +11,32 @@
#define S390X_DIAG320_H
#define DIAG_320_SUBC_QUERY_ISM 0
+#define DIAG_320_SUBC_QUERY_VCSI 1
#define DIAG_320_RC_OK 0x0001
#define DIAG_320_RC_NOT_SUPPORTED 0x0102
+#define DIAG_320_RC_INVAL_VCSSB_LEN 0x0202
#define DIAG_320_ISM_QUERY_SUBCODES 0x80000000
+#define DIAG_320_ISM_QUERY_VCSI 0x40000000
+
+#define VCSSB_NO_VC 4
+#define VCSSB_MIN_LEN 128
+#define VCE_HEADER_LEN 128
+#define VCB_HEADER_LEN 64
+
+struct VCStorageSizeBlock {
+ uint32_t length;
+ uint8_t reserved0[3];
+ uint8_t version;
+ uint32_t reserved1[6];
+ uint16_t total_vc_ct;
+ uint16_t max_vc_ct;
+ uint32_t reserved3[11];
+ uint32_t max_single_vcb_len;
+ uint32_t total_vcb_len;
+ uint32_t reserved4[10];
+};
+typedef struct VCStorageSizeBlock VCStorageSizeBlock;
Should this be a packed structure? The Linux kernel defines it as packed
https://elixir.bootlin.com/linux/v6.17-rc3/source/arch/s390/kernel/
cert_store.c#L81
Packed structs should be avoided in user space code that might get compiled
on different host architectures, we've hit related problems a couple of
times in the past already (doing a quick search, I came up with
https://lists.gnu.org/archive/html/qemu-devel//2017-03/msg05316.html for
example, but I remember we had similar problems in the s390x code once, too).
In this struct here, all fields are naturally aligned, so the packed should
not be necessary. Just add a size check with QEMU_BUILD_BUG_ON to make sure
that there is really no unexpected padding here.
Thomas
