FYI: QEMU model is working fine, upstreaming started, feedback welcome.
Jan
On 24.08.25 09:18, Jan Kiszka wrote:
This closes an old gap in system integration testing for the very complex ARM firmware stacks by adding fairly advanced Replay Protected Memory Block (RPMB) emulation to the eMMC device model. Key programming and message authentication are working, so is the write counter. Known users are happy with the result. What is missing, but not only for RPMB- related registers, is state persistence across QEMU restarts. This is OK at this stage for most test scenarios, though, and could still be added later on.
What can already be done with it is demonstrated in the WIP branch of isar-cip-core at [1]: TF-A + OP-TEE + StandaloneMM TA + fTPM TA, used by U-Boot and Linux for UEFI variable storage and TPM scenarios. If you want to try: build qemu-arm64 target for trixie with 6.12-cip *head* kernel, enable secure boot and disk encryption, then run
$ QEMU_PATH=/path/to/qemu-build/ ./start-qemu.sh
Deploy snakeoil keys into PK, KEK and db after first boot to enable secure booting:
root@demo:~# cert-to-efi-sig-list PkKek-1-snakeoil.pem PK.esl root@demo:~# sign-efi-sig-list -k PkKek-1-snakeoil.key -c PkKek-1-snakeoil.pem PK PK.esl PK.auth root@demo:~# efi-updatevar -f PK.auth db root@demo:~# efi-updatevar -f PK.auth KEK root@demo:~# efi-updatevar -f PK.auth PK
Note that emulation is a bit slow in general, and specifically the partition encryption on first boot is taking 20 min. - we should probably reduce its size or understand if there is still something to optimize.
Jan
[1] https://gitlab.com/cip-project/cip-core/isar-cip-core/-/commits/wip/qemu-rpm...
Cc: "Daniel P. Berrangé" berrange@redhat.com
Jan Kiszka (8): hw/sd/sdcard: Fix size check for backing block image hw/sd/sdcard: Add validation for boot-partition-size hw/sd/sdcard: Allow user-instantiated eMMC hw/sd/sdcard: Refactor sd_bootpart_offset hw/sd/sdcard: Add basic support for RPMB partition crypto/hmac: Allow to build hmac over multiple qcrypto_gnutls_hmac_bytes[v] calls hw/sd/sdcard: Handle RPMB MAC field scripts: Add helper script to generate eMMC block device images
crypto/hmac-gcrypt.c | 4 +- crypto/hmac-glib.c | 4 +- crypto/hmac-gnutls.c | 4 +- crypto/hmac-nettle.c | 4 +- hw/sd/sd.c | 314 ++++++++++++++++++++++++++++++++++++++--- hw/sd/sdmmc-internal.h | 24 +++- hw/sd/trace-events | 2 + include/crypto/hmac.h | 12 ++ scripts/mkemmc.sh | 185 ++++++++++++++++++++++++ 9 files changed, 530 insertions(+), 23 deletions(-) create mode 100755 scripts/mkemmc.sh
On Sun, Aug 24, 2025 at 09:41:06AM +0200, Jan Kiszka via OP-TEE wrote:
FYI: QEMU model is working fine, upstreaming started, feedback welcome.
Thanks Jan for sharing, it really enhances the testing capability around RPMB based secure storage.
Jan
On 24.08.25 09:18, Jan Kiszka wrote:
This closes an old gap in system integration testing for the very complex ARM firmware stacks by adding fairly advanced Replay Protected Memory Block (RPMB) emulation to the eMMC device model. Key programming and message authentication are working, so is the write counter. Known users are happy with the result. What is missing, but not only for RPMB- related registers, is state persistence across QEMU restarts. This is OK at this stage for most test scenarios, though, and could still be added later on.
What can already be done with it is demonstrated in the WIP branch of isar-cip-core at [1]: TF-A + OP-TEE + StandaloneMM TA + fTPM TA, used by U-Boot and Linux for UEFI variable storage and TPM scenarios. If you want to try: build qemu-arm64 target for trixie with 6.12-cip *head* kernel, enable secure boot and disk encryption, then run
$ QEMU_PATH=/path/to/qemu-build/ ./start-qemu.sh
Deploy snakeoil keys into PK, KEK and db after first boot to enable secure booting:
root@demo:~# cert-to-efi-sig-list PkKek-1-snakeoil.pem PK.esl root@demo:~# sign-efi-sig-list -k PkKek-1-snakeoil.key -c PkKek-1-snakeoil.pem PK PK.esl PK.auth root@demo:~# efi-updatevar -f PK.auth db root@demo:~# efi-updatevar -f PK.auth KEK root@demo:~# efi-updatevar -f PK.auth PK
Note that emulation is a bit slow in general, and specifically the partition encryption on first boot is taking 20 min. - we should probably reduce its size or understand if there is still something to optimize.
Can you try with KVM enabled? I suppose that should allow you to use Armv8 CPU Crypto Extensions. However, do you host a Qemu branch with these patches applied? I think that would enable folks to use that in OP-TEE build setup.
-Sumit
Jan
[1] https://gitlab.com/cip-project/cip-core/isar-cip-core/-/commits/wip/qemu-rpm...
Cc: "Daniel P. Berrangé" berrange@redhat.com
Jan Kiszka (8): hw/sd/sdcard: Fix size check for backing block image hw/sd/sdcard: Add validation for boot-partition-size hw/sd/sdcard: Allow user-instantiated eMMC hw/sd/sdcard: Refactor sd_bootpart_offset hw/sd/sdcard: Add basic support for RPMB partition crypto/hmac: Allow to build hmac over multiple qcrypto_gnutls_hmac_bytes[v] calls hw/sd/sdcard: Handle RPMB MAC field scripts: Add helper script to generate eMMC block device images
crypto/hmac-gcrypt.c | 4 +- crypto/hmac-glib.c | 4 +- crypto/hmac-gnutls.c | 4 +- crypto/hmac-nettle.c | 4 +- hw/sd/sd.c | 314 ++++++++++++++++++++++++++++++++++++++--- hw/sd/sdmmc-internal.h | 24 +++- hw/sd/trace-events | 2 + include/crypto/hmac.h | 12 ++ scripts/mkemmc.sh | 185 ++++++++++++++++++++++++ 9 files changed, 530 insertions(+), 23 deletions(-) create mode 100755 scripts/mkemmc.sh
-- Siemens AG, Foundational Technologies Linux Expert Center
On 26.08.25 12:57, Sumit Garg wrote:
On Sun, Aug 24, 2025 at 09:41:06AM +0200, Jan Kiszka via OP-TEE wrote:
FYI: QEMU model is working fine, upstreaming started, feedback welcome.
Thanks Jan for sharing, it really enhances the testing capability around RPMB based secure storage.
Jan
On 24.08.25 09:18, Jan Kiszka wrote:
This closes an old gap in system integration testing for the very complex ARM firmware stacks by adding fairly advanced Replay Protected Memory Block (RPMB) emulation to the eMMC device model. Key programming and message authentication are working, so is the write counter. Known users are happy with the result. What is missing, but not only for RPMB- related registers, is state persistence across QEMU restarts. This is OK at this stage for most test scenarios, though, and could still be added later on.
What can already be done with it is demonstrated in the WIP branch of isar-cip-core at [1]: TF-A + OP-TEE + StandaloneMM TA + fTPM TA, used by U-Boot and Linux for UEFI variable storage and TPM scenarios. If you want to try: build qemu-arm64 target for trixie with 6.12-cip *head* kernel, enable secure boot and disk encryption, then run
$ QEMU_PATH=/path/to/qemu-build/ ./start-qemu.sh
Deploy snakeoil keys into PK, KEK and db after first boot to enable secure booting:
root@demo:~# cert-to-efi-sig-list PkKek-1-snakeoil.pem PK.esl root@demo:~# sign-efi-sig-list -k PkKek-1-snakeoil.key -c PkKek-1-snakeoil.pem PK PK.esl PK.auth root@demo:~# efi-updatevar -f PK.auth db root@demo:~# efi-updatevar -f PK.auth KEK root@demo:~# efi-updatevar -f PK.auth PK
Note that emulation is a bit slow in general, and specifically the partition encryption on first boot is taking 20 min. - we should probably reduce its size or understand if there is still something to optimize.
Can you try with KVM enabled? I suppose that should allow you to use Armv8 CPU Crypto Extensions.
Worth a try - will pull out some raspi or so and let you know.
However, do you host a Qemu branch with these patches applied? I think that would enable folks to use that in OP-TEE build setup.
https://github.com/siemens/qemu/commits/queues/emmc/
Jan
On 27.08.25 07:55, Jan Kiszka via OP-TEE wrote:
On 24.08.25 09:18, Jan Kiszka wrote:
This closes an old gap in system integration testing for the very complex ARM firmware stacks by adding fairly advanced Replay Protected Memory Block (RPMB) emulation to the eMMC device model. Key programming and message authentication are working, so is the write counter. Known users are happy with the result. What is missing, but not only for RPMB- related registers, is state persistence across QEMU restarts. This is OK at this stage for most test scenarios, though, and could still be added later on.
What can already be done with it is demonstrated in the WIP branch of isar-cip-core at [1]: TF-A + OP-TEE + StandaloneMM TA + fTPM TA, used by U-Boot and Linux for UEFI variable storage and TPM scenarios. If you want to try: build qemu-arm64 target for trixie with 6.12-cip *head* kernel, enable secure boot and disk encryption, then run
$ QEMU_PATH=/path/to/qemu-build/ ./start-qemu.sh
Deploy snakeoil keys into PK, KEK and db after first boot to enable secure booting:
root@demo:~# cert-to-efi-sig-list PkKek-1-snakeoil.pem PK.esl root@demo:~# sign-efi-sig-list -k PkKek-1-snakeoil.key -c PkKek-1-snakeoil.pem PK PK.esl PK.auth root@demo:~# efi-updatevar -f PK.auth db root@demo:~# efi-updatevar -f PK.auth KEK root@demo:~# efi-updatevar -f PK.auth PK
Note that emulation is a bit slow in general, and specifically the partition encryption on first boot is taking 20 min. - we should probably reduce its size or understand if there is still something to optimize.
Can you try with KVM enabled? I suppose that should allow you to use Armv8 CPU Crypto Extensions.
Worth a try - will pull out some raspi or so and let you know.
I finally found the time to set everything up - just to get this:
qemu-system-aarch64: mach-virt: KVM does not support providing Security extensions (TrustZone) to the guest CPU
Jan
Hi Jan,
On 8/24/25 09:41, Jan Kiszka via OP-TEE wrote:
FYI: QEMU model is working fine, upstreaming started, feedback welcome.
This is awesome. I pulled the various bits (QEMU v10.1.0 + your patches, U-Boot next, Buildroot 2025.10-rc3 with mmc-utils v1.0) and was able to run the OP-TEE OS tests successfully ("make check"), using the in-kernel RPMB routing. TBH there is one failure with the TPM test (xtest regression_1041) which I will need to figure out in due time but I am already very happy with the situation. As soon as everything is upstream I'll update the OP-TEE dev environment and add a job to the optee_os CI.
Many thanks for your work and for sharing it!
op-tee@lists.trustedfirmware.org
-
Jan Kiszka -
Jerome Forissier -
Sumit Garg