From: Jan Kiszka <jan.kiszka@siemens.com>
To: Sumit Garg <sumit.garg@kernel.org>
Cc: OP-TEE TrustedFirmware <op-tee@lists.trustedfirmware.org>,
cip-dev <cip-dev@lists.cip-project.org>
Subject: Re: [PATCH 0/8] sd: Add RPMB emulation to eMMC model
Date: Sun, 19 Oct 2025 18:35:34 +0200 [thread overview]
Message-ID: <48eeceea-9f19-4f53-bccc-7dc566af11f9@siemens.com> (raw)
In-Reply-To: <d9939ae1-b511-494c-8382-fe6b36af6744@siemens.com>
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
--
Siemens AG, Foundational Technologies
Linux Expert Center
WARNING: multiple messages have this Message-ID (diff)
From: Jan Kiszka via OP-TEE <op-tee@lists.trustedfirmware.org>
To: Sumit Garg <sumit.garg@kernel.org>
Cc: OP-TEE TrustedFirmware <op-tee@lists.trustedfirmware.org>,
cip-dev <cip-dev@lists.cip-project.org>
Subject: Re: [PATCH 0/8] sd: Add RPMB emulation to eMMC model
Date: Sun, 19 Oct 2025 18:35:34 +0200 [thread overview]
Message-ID: <48eeceea-9f19-4f53-bccc-7dc566af11f9@siemens.com> (raw)
In-Reply-To: <d9939ae1-b511-494c-8382-fe6b36af6744@siemens.com>
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
--
Siemens AG, Foundational Technologies
Linux Expert Center
next prev parent reply other threads:[~2025-10-19 16:35 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-24 7:18 [PATCH 0/8] sd: Add RPMB emulation to eMMC model Jan Kiszka
2025-08-24 7:18 ` [PATCH 1/8] hw/sd/sdcard: Fix size check for backing block image Jan Kiszka
2025-08-25 9:39 ` Philippe Mathieu-Daudé
2025-08-24 7:18 ` [PATCH 2/8] hw/sd/sdcard: Add validation for boot-partition-size Jan Kiszka
2025-08-24 7:18 ` [PATCH 3/8] hw/sd/sdcard: Allow user-instantiated eMMC Jan Kiszka
2025-08-24 7:18 ` [PATCH 4/8] hw/sd/sdcard: Refactor sd_bootpart_offset Jan Kiszka
2025-08-25 9:41 ` Philippe Mathieu-Daudé
2025-08-24 7:18 ` [PATCH 5/8] hw/sd/sdcard: Add basic support for RPMB partition Jan Kiszka
2025-08-24 7:18 ` [PATCH 6/8] crypto/hmac: Allow to build hmac over multiple qcrypto_gnutls_hmac_bytes[v] calls Jan Kiszka
2025-08-25 9:43 ` Philippe Mathieu-Daudé
2025-08-24 7:18 ` [PATCH 7/8] hw/sd/sdcard: Handle RPMB MAC field Jan Kiszka
2025-08-25 9:47 ` Philippe Mathieu-Daudé
2025-08-25 16:12 ` Jan Kiszka
2025-08-25 16:30 ` Philippe Mathieu-Daudé
2025-08-26 10:18 ` Daniel P. Berrangé
2025-08-27 5:53 ` Jan Kiszka
2025-08-27 9:53 ` Daniel P. Berrangé
2025-09-09 14:39 ` Jerome Forissier
2025-08-24 7:18 ` [PATCH 8/8] scripts: Add helper script to generate eMMC block device images Jan Kiszka
2025-08-25 9:51 ` Philippe Mathieu-Daudé
2025-09-09 14:25 ` Jerome Forissier
2025-09-14 12:23 ` Jan Kiszka
2025-08-24 7:41 ` [PATCH 0/8] sd: Add RPMB emulation to eMMC model Jan Kiszka
2025-08-24 7:41 ` Jan Kiszka via OP-TEE
2025-08-26 10:57 ` Sumit Garg via OP-TEE
2025-08-27 5:55 ` Jan Kiszka
2025-08-27 5:55 ` Jan Kiszka via OP-TEE
2025-10-19 16:35 ` Jan Kiszka [this message]
2025-10-19 16:35 ` Jan Kiszka via OP-TEE
2025-09-03 14:35 ` Jerome Forissier
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=48eeceea-9f19-4f53-bccc-7dc566af11f9@siemens.com \
--to=jan.kiszka@siemens.com \
--cc=cip-dev@lists.cip-project.org \
--cc=op-tee@lists.trustedfirmware.org \
--cc=sumit.garg@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.