On 11/10/25 6:01 AM, Thomas Huth wrote: > On 05/11/2025 20.21, Zhuoying Cai wrote: >> On 9/26/25 8:38 AM, Thomas Huth wrote: >>> On 18/09/2025 01.21, Zhuoying Cai wrote: >>> ... >>>> crypto/meson.build | 5 +- >>>> crypto/x509-utils.c | 423 +++++++++++++++ >>>> docs/specs/s390x-secure-ipl.rst | 165 ++++++ >>>> docs/system/s390x/secure-ipl.rst | 181 +++++++ >>>> hw/s390x/cert-store.c | 213 ++++++++ >>>> hw/s390x/cert-store.h | 39 ++ >>>> hw/s390x/ipl.c | 62 +++ >>>> hw/s390x/ipl.h | 27 +- >>>> hw/s390x/meson.build | 1 + >>>> hw/s390x/s390-virtio-ccw.c | 52 ++ >>>> hw/s390x/sclp.c | 2 + >>>> include/crypto/x509-utils.h | 131 +++++ >>>> include/hw/s390x/ipl/diag308.h | 34 ++ >>>> include/hw/s390x/ipl/diag320.h | 91 ++++ >>>> include/hw/s390x/ipl/diag508.h | 38 ++ >>>> include/hw/s390x/ipl/qipl.h | 7 +- >>>> include/hw/s390x/s390-virtio-ccw.h | 3 + >>>> include/hw/s390x/sclp.h | 4 +- >>>> pc-bios/s390-ccw/Makefile | 3 +- >>>> pc-bios/s390-ccw/bootmap.c | 107 +++- >>>> pc-bios/s390-ccw/bootmap.h | 11 + >>>> pc-bios/s390-ccw/iplb.h | 96 +++- >>>> pc-bios/s390-ccw/jump2ipl.c | 6 +- >>>> pc-bios/s390-ccw/main.c | 111 +++- >>>> pc-bios/s390-ccw/netmain.c | 8 +- >>>> pc-bios/s390-ccw/s390-ccw.h | 19 + >>>> pc-bios/s390-ccw/sclp.c | 52 ++ >>>> pc-bios/s390-ccw/sclp.h | 7 + >>>> pc-bios/s390-ccw/secure-ipl.c | 781 ++++++++++++++++++++++++++++ >>>> pc-bios/s390-ccw/secure-ipl.h | 212 ++++++++ >>>> qapi/machine-s390x.json | 22 + >>>> qapi/pragma.json | 1 + >>>> qemu-options.hx | 10 +- >>>> target/s390x/cpu_features.c | 7 + >>>> target/s390x/cpu_features.h | 1 + >>>> target/s390x/cpu_features_def.h.inc | 5 + >>>> target/s390x/cpu_models.c | 7 + >>>> target/s390x/diag.c | 555 +++++++++++++++++++- >>>> target/s390x/gen-features.c | 7 + >>>> target/s390x/kvm/kvm.c | 34 ++ >>>> target/s390x/s390x-internal.h | 4 + >>>> target/s390x/tcg/misc_helper.c | 14 + >>>> 42 files changed, 3488 insertions(+), 70 deletions(-) >>>> create mode 100644 docs/specs/s390x-secure-ipl.rst >>>> create mode 100644 docs/system/s390x/secure-ipl.rst >>>> create mode 100644 hw/s390x/cert-store.c >>>> create mode 100644 hw/s390x/cert-store.h >>>> create mode 100644 include/hw/s390x/ipl/diag308.h >>>> create mode 100644 include/hw/s390x/ipl/diag320.h >>>> create mode 100644 include/hw/s390x/ipl/diag508.h >>>> create mode 100644 pc-bios/s390-ccw/secure-ipl.c >>>> create mode 100644 pc-bios/s390-ccw/secure-ipl.h >>> >>> Hi, >>> >>> looking at the file list, there does not seem to be any test in this series >>> ... could you please add some functional tests to make sure that the feature >>> is working as expected? >> >> I’m currently working on the functional tests for secure IPL and have >> encountered a few blockers, so I wanted to reach out for some guidance. >> >> The main challenge is determining how to provide signed components and >> signatures within the tests. In a manual secure IPL setup, we would >> generate certificates, use the sign-file script to sign the components >> (stage3 binary and kernel), and prepare zipl inside the guest. >> Additionally, the signed components would include Secure Code Loading >> Attribute Blocks (SCLABs) appended for further validation. These steps >> are difficult to reproduce in a functional test environment. >> >> Our current idea is to create a bootable image using the SCSI scheme >> with a minimal boot map that includes fake signed components with >> hard-coded signatures (and SCLABs if feasible), similar to the approach >> used in prepare_image() in tests/qtest/cdrom-test.c. However, this >> approach is more complex than expected, and we are unsure how viable it is. >> >> Do you have any suggestions on our current plan or other recommendations >> for how we might approach testing secure IPL? I’d appreciate your guidance. > > Hi, > > would it be possible that you create a real small qcow2 image (e.g. with > buildroot.org), make sure that it gets the right signatures, upload the > image to your github account (or somewhere else), and then add a functional > test to tests/functional/s390x that downloads the image and tests the boot > process with it? I think that would likely be the best solution...? > > HTH, > Thomas >
I'll look into this approach. Thank you for the suggestion!
