[isar-cip-core][PATCH 0/7] Provide measured boot via fTPM for arm64, early deploy EFI keys

[isar-cip-core][PATCH 0/7] Provide measured boot via fTPM for arm64, early deploy EFI keys

[Jan Kiszka]

Due to some deficits in U-Boot, the fTPM was not recognized and, thus,
its PCRs for measurements were not fed. This led to the disk encryption
key we are storing in the TPM not being sealed properly. Existing
deployments were most likely not affected by this when they locked down
U-Boot to only boot in secure mode (like we did and continue to do).

After fixing this, we are confronted with a practical problem: The QEMU
target for arm64 is set up without pre-deployed UEFI keys. When we now,
with working measurements, switch to secure boot after the initial disk
encryption, unsealing the key will no longer work.

For this but possibly also for other scenarios, the series adds an
initramfs hook which tries to deploy the secure boot keys if the target
is in non-secure mode and no other keys are deployed yet.

With all that in place, we change the policy of the disk encryption
hook to only perform its task when the device is securely booted. If
this should break valid downstream scenarios, we may make it opt-out
later on, but so far none are imaginable.

Jan

Jan Kiszka (7):
  secure-boot-efi-keys: Add recipe to create EFI keys
  cip-initramfs-functions: Add secure_boot_enabled helper
  cip-core-initramfs: Automatically deploy secure boot keys on first
    boot
  u-boot: Add patches to enable measured boot with fTPM
  u-boot: Refactor ftpm-stmm.cfg to enable measured boot for all
  u-boot: Drop obsolete config workaround
  initramfs-crypt-hook: Prevent encryption without secure boot

 ...ement-Fix-compilation-for-non-sandbo.patch |  43 +++++
 ...-out-service-enumeration-and-binding.patch |  95 +++++++++++
 ...pport-for-enumerating-services-that-.patch | 155 ++++++++++++++++++
 ...-warn-about-TEE_ERROR_STORAGE_NOT_AV.patch |  33 ++++
 ...to-optee-after-a-successful-mmc_init.patch |  41 +++++
 ...-MMC-Device-not-found-a-debug-output.patch |  50 ++++++
 recipes-bsp/u-boot/files/ftpm-stmm.cfg        |   7 +-
 recipes-bsp/u-boot/files/qemu-extra.cfg       |   2 +
 recipes-bsp/u-boot/files/secure-boot.cfg      |   2 -
 recipes-bsp/u-boot/files/ti-extra.cfg         |   8 +-
 recipes-bsp/u-boot/u-boot-common-2026.01.inc  |   6 +
 .../single-key-to-efi-keys_0.1.bb             |  41 +++++
 .../cip-core-initramfs/cip-core-initramfs.bb  |   1 +
 .../files/cip-initramfs-functions             |  16 ++
 .../files/local-top-complete                  |   4 +
 .../initramfs-sbkeys-hook/files/hook          |  16 ++
 .../initramfs-sbkeys-hook/files/local-top     |  34 ++++
 .../initramfs-sbkeys-hook/files/mount-stub    |  13 ++
 .../initramfs-sbkeys-hook_0.1.bb              |  32 ++++
 19 files changed, 589 insertions(+), 10 deletions(-)
 create mode 100644 recipes-bsp/u-boot/files/0001-test-boot-measurement-Fix-compilation-for-non-sandbo.patch
 create mode 100644 recipes-bsp/u-boot/files/0002-tee-optee-Factor-out-service-enumeration-and-binding.patch
 create mode 100644 recipes-bsp/u-boot/files/0003-tee-optee-Add-support-for-enumerating-services-that-.patch
 create mode 100644 recipes-bsp/u-boot/files/0004-tee-optee-Do-not-warn-about-TEE_ERROR_STORAGE_NOT_AV.patch
 create mode 100644 recipes-bsp/u-boot/files/0005-mmc-Call-back-to-optee-after-a-successful-mmc_init.patch
 create mode 100644 recipes-bsp/u-boot/files/0006-mmc-Make-MMC-Device-not-found-a-debug-output.patch
 create mode 100644 recipes-devtools/secure-boot-efi-keys/single-key-to-efi-keys_0.1.bb
 create mode 100644 recipes-initramfs/initramfs-sbkeys-hook/files/hook
 create mode 100644 recipes-initramfs/initramfs-sbkeys-hook/files/local-top
 create mode 100755 recipes-initramfs/initramfs-sbkeys-hook/files/mount-stub
 create mode 100644 recipes-initramfs/initramfs-sbkeys-hook/initramfs-sbkeys-hook_0.1.bb

-- 
2.47.3

[isar-cip-core][PATCH 1/7] secure-boot-efi-keys: Add recipe to create EFI keys

[Jan Kiszka]

From: Jan Kiszka <jan.kiszka@siemens.com>

This recipe allows to derive the PK, KEK and db values from a single
signing key as we are using for demonstration/testing purposes and
simple scenarios. The recipe provides abstract "secure-boot-efi-keys"
which could also be offered by an alternative recipe/package that picks
up differently generated keys and/or a proper key hierarchy.

Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
---
 .../single-key-to-efi-keys_0.1.bb             | 41 +++++++++++++++++++
 1 file changed, 41 insertions(+)
 create mode 100644 recipes-devtools/secure-boot-efi-keys/single-key-to-efi-keys_0.1.bb

diff --git a/recipes-devtools/secure-boot-efi-keys/single-key-to-efi-keys_0.1.bb b/recipes-devtools/secure-boot-efi-keys/single-key-to-efi-keys_0.1.bb
new file mode 100644
index 00000000..cfa48b7f
--- /dev/null
+++ b/recipes-devtools/secure-boot-efi-keys/single-key-to-efi-keys_0.1.bb
@@ -0,0 +1,41 @@
+#
+# CIP Core, generic profile
+#
+# Copyright (c) Siemens AG, 2026
+#
+# Authors:
+#  Jan Kiszka <jan.kiszka@siemens.com>
+#
+# SPDX-License-Identifier: MIT
+#
+
+inherit dpkg
+
+MAINTAINER = "cip-dev <cip-dev@lists.cip-project.org>"
+DESCRIPTION = "Generate EFI keys from single secure boot key"
+
+PROVIDES += "secure-boot-efi-keys"
+DEBIAN_PROVIDES = "secure-boot-efi-keys"
+
+DEPENDS = "secure-boot-secrets"
+DEBIAN_BUILD_DEPENDS .= ", secure-boot-secrets, efitools"
+
+do_prepare_build() {
+    deb_debianize
+
+    cat <<EOF > ${S}/debian/${BPN}.install
+db.auth usr/share/secure-boot-efi-keys
+KEK.auth usr/share/secure-boot-efi-keys
+PK.auth usr/share/secure-boot-efi-keys
+EOF
+
+    cat <<EOF >> ${S}/debian/rules
+
+override_dh_auto_build:
+	cert-to-efi-sig-list /usr/share/secure-boot-secrets/secure-boot.pem PK.esl
+	sign-efi-sig-list -k /usr/share/secure-boot-secrets/secure-boot.key \
+	    -c /usr/share/secure-boot-secrets/secure-boot.pem PK PK.esl PK.auth
+	cp PK.auth KEK.auth
+	cp PK.auth db.auth
+EOF
+}
-- 
2.47.3

Re: [isar-cip-core][PATCH 1/7] secure-boot-efi-keys: Add recipe to create EFI keys

[Heinisch, Alexander (FT RPD CED SES-AT)]

Am 26.08.2026 um 07:41 schrieb Jan Kiszka:
> From: Jan Kiszka <jan.kiszka@siemens.com>
> 
> This recipe allows to derive the PK, KEK and db values from a single
> signing key as we are using for demonstration/testing purposes and
> simple scenarios. The recipe provides abstract "secure-boot-efi-keys"
> which could also be offered by an alternative recipe/package that picks
> up differently generated keys and/or a proper key hierarchy.
> 
> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
> ---
>   .../single-key-to-efi-keys_0.1.bb             | 41 +++++++++++++++++++
>   1 file changed, 41 insertions(+)
>   create mode 100644 recipes-devtools/secure-boot-efi-keys/single-key-to-efi-keys_0.1.bb
> 
> diff --git a/recipes-devtools/secure-boot-efi-keys/single-key-to-efi-keys_0.1.bb b/recipes-devtools/secure-boot-efi-keys/single-key-to-efi-keys_0.1.bb
> new file mode 100644
> index 00000000..cfa48b7f
> --- /dev/null
> +++ b/recipes-devtools/secure-boot-efi-keys/single-key-to-efi-keys_0.1.bb
> @@ -0,0 +1,41 @@
> +#
> +# CIP Core, generic profile
> +#
> +# Copyright (c) Siemens AG, 2026
> +#
> +# Authors:
> +#  Jan Kiszka <jan.kiszka@siemens.com>
> +#
> +# SPDX-License-Identifier: MIT
> +#
> +
> +inherit dpkg
> +
> +MAINTAINER = "cip-dev <cip-dev@lists.cip-project.org>"
> +DESCRIPTION = "Generate EFI keys from single secure boot key"
> +
> +PROVIDES += "secure-boot-efi-keys"
The naming confuses actual keys (private portions) with authenticated 
efi signature list) actually holding the secure-boot-certificates - so 
maybe secure-boot-vars-auth, secure-boot-certificates-auth or even 
secure-boot-certificates is more intuitive?


> +DEBIAN_PROVIDES = "secure-boot-efi-keys"
> +
> +DEPENDS = "secure-boot-secrets"
> +DEBIAN_BUILD_DEPENDS .= ", secure-boot-secrets, efitools"
> +
> +do_prepare_build() {
> +    deb_debianize
> +
> +    cat <<EOF > ${S}/debian/${BPN}.install
> +db.auth usr/share/secure-boot-efi-keys
> +KEK.auth usr/share/secure-boot-efi-keys
> +PK.auth usr/share/secure-boot-efi-keys
> +EOF
> +
> +    cat <<EOF >> ${S}/debian/rules
> +
> +override_dh_auto_build:
> +	cert-to-efi-sig-list /usr/share/secure-boot-secrets/secure-boot.pem PK.esl
> +	sign-efi-sig-list -k /usr/share/secure-boot-secrets/secure-boot.key \
> +	    -c /usr/share/secure-boot-secrets/secure-boot.pem PK PK.esl PK.auth
> +	cp PK.auth KEK.auth
> +	cp PK.auth db.auth
> +EOF
> +}

Re: [isar-cip-core][PATCH 1/7] secure-boot-efi-keys: Add recipe to create EFI keys

[Jan Kiszka]

On 26.08.26 10:31, Heinisch, Alexander (FT RPD CED SES-AT) wrote:
> 
> 
> Am 26.08.2026 um 07:41 schrieb Jan Kiszka:
>> From: Jan Kiszka <jan.kiszka@siemens.com>
>>
>> This recipe allows to derive the PK, KEK and db values from a single
>> signing key as we are using for demonstration/testing purposes and
>> simple scenarios. The recipe provides abstract "secure-boot-efi-keys"
>> which could also be offered by an alternative recipe/package that picks
>> up differently generated keys and/or a proper key hierarchy.
>>
>> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
>> ---
>>   .../single-key-to-efi-keys_0.1.bb             | 41 +++++++++++++++++++
>>   1 file changed, 41 insertions(+)
>>   create mode 100644 recipes-devtools/secure-boot-efi-keys/single-key-
>> to-efi-keys_0.1.bb
>>
>> diff --git a/recipes-devtools/secure-boot-efi-keys/single-key-to-efi-
>> keys_0.1.bb b/recipes-devtools/secure-boot-efi-keys/single-key-to-efi-
>> keys_0.1.bb
>> new file mode 100644
>> index 00000000..cfa48b7f
>> --- /dev/null
>> +++ b/recipes-devtools/secure-boot-efi-keys/single-key-to-efi-keys_0.1.bb
>> @@ -0,0 +1,41 @@
>> +#
>> +# CIP Core, generic profile
>> +#
>> +# Copyright (c) Siemens AG, 2026
>> +#
>> +# Authors:
>> +#  Jan Kiszka <jan.kiszka@siemens.com>
>> +#
>> +# SPDX-License-Identifier: MIT
>> +#
>> +
>> +inherit dpkg
>> +
>> +MAINTAINER = "cip-dev <cip-dev@lists.cip-project.org>"
>> +DESCRIPTION = "Generate EFI keys from single secure boot key"
>> +
>> +PROVIDES += "secure-boot-efi-keys"
> The naming confuses actual keys (private portions) with authenticated
> efi signature list) actually holding the secure-boot-certificates - so
> maybe secure-boot-vars-auth, secure-boot-certificates-auth or even
> secure-boot-certificates is more intuitive?
> 

Agree. How about secure-boot-efi-certs?

Jan

-- 
Siemens AG, Foundational Technologies
Linux Expert Center

Re: [isar-cip-core][PATCH 1/7] secure-boot-efi-keys: Add recipe to create EFI keys

[Heinisch, Alexander (FT RPD CED SES-AT)]

Am 26.08.2026 um 10:44 schrieb Jan Kiszka:
> On 26.08.26 10:31, Heinisch, Alexander (FT RPD CED SES-AT) wrote:
>>
>>
>> Am 26.08.2026 um 07:41 schrieb Jan Kiszka:
>>> From: Jan Kiszka <jan.kiszka@siemens.com>
>>>
>>> This recipe allows to derive the PK, KEK and db values from a single
>>> signing key as we are using for demonstration/testing purposes and
>>> simple scenarios. The recipe provides abstract "secure-boot-efi-keys"
>>> which could also be offered by an alternative recipe/package that picks
>>> up differently generated keys and/or a proper key hierarchy.
>>>
>>> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
>>> ---
>>>    .../single-key-to-efi-keys_0.1.bb             | 41 +++++++++++++++++++
>>>    1 file changed, 41 insertions(+)
>>>    create mode 100644 recipes-devtools/secure-boot-efi-keys/single-key-
>>> to-efi-keys_0.1.bb
>>>
>>> diff --git a/recipes-devtools/secure-boot-efi-keys/single-key-to-efi-
>>> keys_0.1.bb b/recipes-devtools/secure-boot-efi-keys/single-key-to-efi-
>>> keys_0.1.bb
>>> new file mode 100644
>>> index 00000000..cfa48b7f
>>> --- /dev/null
>>> +++ b/recipes-devtools/secure-boot-efi-keys/single-key-to-efi-keys_0.1.bb
>>> @@ -0,0 +1,41 @@
>>> +#
>>> +# CIP Core, generic profile
>>> +#
>>> +# Copyright (c) Siemens AG, 2026
>>> +#
>>> +# Authors:
>>> +#  Jan Kiszka <jan.kiszka@siemens.com>
>>> +#
>>> +# SPDX-License-Identifier: MIT
>>> +#
>>> +
>>> +inherit dpkg
>>> +
>>> +MAINTAINER = "cip-dev <cip-dev@lists.cip-project.org>"
>>> +DESCRIPTION = "Generate EFI keys from single secure boot key"
>>> +
>>> +PROVIDES += "secure-boot-efi-keys"
>> The naming confuses actual keys (private portions) with authenticated
>> efi signature list) actually holding the secure-boot-certificates - so
>> maybe secure-boot-vars-auth, secure-boot-certificates-auth or even
>> secure-boot-certificates is more intuitive?
>>
> 
> Agree. How about secure-boot-efi-certs?

Nice.

> 
> Jan
> 

[isar-cip-core][PATCH 2/7] cip-initramfs-functions: Add secure_boot_enabled helper

[Jan Kiszka]

From: Jan Kiszka <jan.kiszka@siemens.com>

Will allow initramfs hooks to determine whether UEFI secure boot is
enabled. The user is responsible for deploying cmp and mountpoint
binaries into the initramfs.

Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
---
 .../files/cip-initramfs-functions                | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)

diff --git a/recipes-initramfs/initramfs-cip-functions/files/cip-initramfs-functions b/recipes-initramfs/initramfs-cip-functions/files/cip-initramfs-functions
index a4c1fed6..f14956d5 100644
--- a/recipes-initramfs/initramfs-cip-functions/files/cip-initramfs-functions
+++ b/recipes-initramfs/initramfs-cip-functions/files/cip-initramfs-functions
@@ -68,3 +68,19 @@ scan_for_partitions() {
     fi
     return 1
 }
+
+# check if system was securely booted via UEFI
+secure_boot_enabled() {
+    efivars=/sys/firmware/efi/efivars
+    if ! mountpoint -q $efivars; then
+        mount -t efivarfs none $efivars
+    fi
+
+    secure_boot="$efivars/SecureBoot-8be4df61-93ca-11d2-aa0d-00e098032b8c"
+    setup_mode="$efivars/SetupMode-8be4df61-93ca-11d2-aa0d-00e098032b8c"
+    if printf '\001' | cmp -s -i 4:0 $secure_boot &&
+       printf '\000' | cmp -s -i 4:0 $setup_mode; then
+        return 0
+    fi
+    return 1
+}
-- 
2.47.3

Re: [isar-cip-core][PATCH 2/7] cip-initramfs-functions: Add secure_boot_enabled helper

[Heinisch, Alexander (FT RPD CED SES-AT)]

Am 26.08.2026 um 07:41 schrieb Jan Kiszka:
> From: Jan Kiszka <jan.kiszka@siemens.com>
> 
> Will allow initramfs hooks to determine whether UEFI secure boot is
> enabled. The user is responsible for deploying cmp and mountpoint
> binaries into the initramfs.
> 
> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
> ---
>   .../files/cip-initramfs-functions                | 16 ++++++++++++++++
>   1 file changed, 16 insertions(+)
> 
> diff --git a/recipes-initramfs/initramfs-cip-functions/files/cip-initramfs-functions b/recipes-initramfs/initramfs-cip-functions/files/cip-initramfs-functions
> index a4c1fed6..f14956d5 100644
> --- a/recipes-initramfs/initramfs-cip-functions/files/cip-initramfs-functions
> +++ b/recipes-initramfs/initramfs-cip-functions/files/cip-initramfs-functions
> @@ -68,3 +68,19 @@ scan_for_partitions() {
>       fi
>       return 1
>   }
> +
> +# check if system was securely booted via UEFI
> +secure_boot_enabled() {
> +    efivars=/sys/firmware/efi/efivars
> +    if ! mountpoint -q $efivars; then
> +        mount -t efivarfs none $efivars
> +    fi
> +
> +    secure_boot="$efivars/SecureBoot-8be4df61-93ca-11d2-aa0d-00e098032b8c"
> +    setup_mode="$efivars/SetupMode-8be4df61-93ca-11d2-aa0d-00e098032b8c"
> +    if printf '\001' | cmp -s -i 4:0 $secure_boot &&
> +       printf '\000' | cmp -s -i 4:0 $setup_mode; then
What about audit mode?

> +        return 0
> +    fi
> +    return 1
> +}

BR Alexander

Re: [isar-cip-core][PATCH 2/7] cip-initramfs-functions: Add secure_boot_enabled helper

[Jan Kiszka]

On 26.08.26 09:51, Heinisch, Alexander (FT RPD CED SES-AT) wrote:
> 
> 
> Am 26.08.2026 um 07:41 schrieb Jan Kiszka:
>> From: Jan Kiszka <jan.kiszka@siemens.com>
>>
>> Will allow initramfs hooks to determine whether UEFI secure boot is
>> enabled. The user is responsible for deploying cmp and mountpoint
>> binaries into the initramfs.
>>
>> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
>> ---
>>   .../files/cip-initramfs-functions                | 16 ++++++++++++++++
>>   1 file changed, 16 insertions(+)
>>
>> diff --git a/recipes-initramfs/initramfs-cip-functions/files/cip-
>> initramfs-functions b/recipes-initramfs/initramfs-cip-functions/files/
>> cip-initramfs-functions
>> index a4c1fed6..f14956d5 100644
>> --- a/recipes-initramfs/initramfs-cip-functions/files/cip-initramfs-
>> functions
>> +++ b/recipes-initramfs/initramfs-cip-functions/files/cip-initramfs-
>> functions
>> @@ -68,3 +68,19 @@ scan_for_partitions() {
>>       fi
>>       return 1
>>   }
>> +
>> +# check if system was securely booted via UEFI
>> +secure_boot_enabled() {
>> +    efivars=/sys/firmware/efi/efivars
>> +    if ! mountpoint -q $efivars; then
>> +        mount -t efivarfs none $efivars
>> +    fi
>> +
>> +    secure_boot="$efivars/SecureBoot-8be4df61-93ca-11d2-
>> aa0d-00e098032b8c"
>> +    setup_mode="$efivars/SetupMode-8be4df61-93ca-11d2-aa0d-00e098032b8c"
>> +    if printf '\001' | cmp -s -i 4:0 $secure_boot &&
>> +       printf '\000' | cmp -s -i 4:0 $setup_mode; then
> What about audit mode?

You mean, I should check for != 1 instead? Seems that this is what the
kernel does as well...

Jan

-- 
Siemens AG, Foundational Technologies
Linux Expert Center

Re: [isar-cip-core][PATCH 2/7] cip-initramfs-functions: Add secure_boot_enabled helper

[Heinisch, Alexander (FT RPD CED SES-AT)]

Am 26.08.2026 um 09:54 schrieb Jan Kiszka:
> On 26.08.26 09:51, Heinisch, Alexander (FT RPD CED SES-AT) wrote:
>>
>>
>> Am 26.08.2026 um 07:41 schrieb Jan Kiszka:
>>> From: Jan Kiszka <jan.kiszka@siemens.com>
>>>
>>> Will allow initramfs hooks to determine whether UEFI secure boot is
>>> enabled. The user is responsible for deploying cmp and mountpoint
>>> binaries into the initramfs.
>>>
>>> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
>>> ---
>>>    .../files/cip-initramfs-functions                | 16 ++++++++++++++++
>>>    1 file changed, 16 insertions(+)
>>>
>>> diff --git a/recipes-initramfs/initramfs-cip-functions/files/cip-
>>> initramfs-functions b/recipes-initramfs/initramfs-cip-functions/files/
>>> cip-initramfs-functions
>>> index a4c1fed6..f14956d5 100644
>>> --- a/recipes-initramfs/initramfs-cip-functions/files/cip-initramfs-
>>> functions
>>> +++ b/recipes-initramfs/initramfs-cip-functions/files/cip-initramfs-
>>> functions
>>> @@ -68,3 +68,19 @@ scan_for_partitions() {
>>>        fi
>>>        return 1
>>>    }
>>> +
>>> +# check if system was securely booted via UEFI
>>> +secure_boot_enabled() {
>>> +    efivars=/sys/firmware/efi/efivars
>>> +    if ! mountpoint -q $efivars; then
>>> +        mount -t efivarfs none $efivars
>>> +    fi
>>> +
>>> +    secure_boot="$efivars/SecureBoot-8be4df61-93ca-11d2-
>>> aa0d-00e098032b8c"
>>> +    setup_mode="$efivars/SetupMode-8be4df61-93ca-11d2-aa0d-00e098032b8c"
>>> +    if printf '\001' | cmp -s -i 4:0 $secure_boot &&
>>> +       printf '\000' | cmp -s -i 4:0 $setup_mode; then
>> What about audit mode?
> 
> You mean, I should check for != 1 instead? Seems that this is what the
> kernel does as well...

Got confused by differing PCR measuers wrt. audit and deployed mode.

If the hooks start in audit mode we end up in deployed mode, and if we 
start in setup mode we end up in user mode, which has effects on PCR1 
and PCR7 respectivly, thus disk encryption.
Not an issue, just something to be aware of :-)

I double checked with uefi spec. In audit mode SetupMode == 1 and 
SecureBoot == 0 => your detection already covers both cases.

Sry for the confusion.

> 
> Jan
> 

[isar-cip-core][PATCH 3/7] cip-core-initramfs: Automatically deploy secure boot keys on first boot

[Jan Kiszka]

From: Jan Kiszka <jan.kiszka@siemens.com>

This both simplifies the initial deployment of secure boot to a device
as well as makes sure that we will always seal the disk encryption key
against the right state.

We only deploy if secure boot is off and the db is found empty. So this
hook is not intended to be used for key exchange or key db extensions.
The former will be once handled via SWUpdate packages, the latter might
be considered given a concrete use case.

Note that due to the primitive implementation of efivarfs detection in
efitools, we need to deploy a horrible hack to make it work against the
mount implementation of busybox in the initramfs. A patch to improve
that issue is pending upstream.

Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
---
 .../cip-core-initramfs/cip-core-initramfs.bb  |  1 +
 .../initramfs-sbkeys-hook/files/hook          | 16 +++++++++
 .../initramfs-sbkeys-hook/files/local-top     | 34 +++++++++++++++++++
 .../initramfs-sbkeys-hook/files/mount-stub    | 13 +++++++
 .../initramfs-sbkeys-hook_0.1.bb              | 32 +++++++++++++++++
 5 files changed, 96 insertions(+)
 create mode 100644 recipes-initramfs/initramfs-sbkeys-hook/files/hook
 create mode 100644 recipes-initramfs/initramfs-sbkeys-hook/files/local-top
 create mode 100755 recipes-initramfs/initramfs-sbkeys-hook/files/mount-stub
 create mode 100644 recipes-initramfs/initramfs-sbkeys-hook/initramfs-sbkeys-hook_0.1.bb

diff --git a/recipes-initramfs/cip-core-initramfs/cip-core-initramfs.bb b/recipes-initramfs/cip-core-initramfs/cip-core-initramfs.bb
index b686185c..241e6af6 100644
--- a/recipes-initramfs/cip-core-initramfs/cip-core-initramfs.bb
+++ b/recipes-initramfs/cip-core-initramfs/cip-core-initramfs.bb
@@ -22,6 +22,7 @@ INITRAMFS_INSTALL:append:factory-reset = " initramfs-factory-reset-hook"
 INITRAMFS_INSTALL:append:ftpm-stmm = " initramfs-tee-ftpm-hook"
 INITRAMFS_INSTALL:append:swupdate = " initramfs-abrootfs-hook"
 INITRAMFS_INSTALL:append:swupdate = " initramfs-${RO_ROOTFS_TYPE}-hook"
+INITRAMFS_INSTALL:append:secureboot = " initramfs-sbkeys-hook"
 INITRAMFS_INSTALL:append:secureboot = " initramfs-verity-hook"
 # abrootfs cannot be installed together with verity
 INITRAMFS_INSTALL:remove:secureboot = "initramfs-abrootfs-hook"
diff --git a/recipes-initramfs/initramfs-sbkeys-hook/files/hook b/recipes-initramfs/initramfs-sbkeys-hook/files/hook
new file mode 100644
index 00000000..770d4454
--- /dev/null
+++ b/recipes-initramfs/initramfs-sbkeys-hook/files/hook
@@ -0,0 +1,16 @@
+#
+# CIP Core, generic profile
+#
+# Copyright (c) Siemens AG, 2026
+#
+# Authors:
+#  Jan Kiszka <jan.kiszka@siemens.com>
+#
+# SPDX-License-Identifier: MIT
+#
+
+copy_file binary /usr/share/secure-boot-efi-keys/db.auth
+copy_file binary /usr/share/secure-boot-efi-keys/KEK.auth
+copy_file binary /usr/share/secure-boot-efi-keys/PK.auth
+
+copy_file binary /usr/share/initramfs-sbkeys-hook/mount
diff --git a/recipes-initramfs/initramfs-sbkeys-hook/files/local-top b/recipes-initramfs/initramfs-sbkeys-hook/files/local-top
new file mode 100644
index 00000000..48fe45d4
--- /dev/null
+++ b/recipes-initramfs/initramfs-sbkeys-hook/files/local-top
@@ -0,0 +1,34 @@
+#
+# CIP Core, generic profile
+#
+# Copyright (c) Siemens AG, 2026
+#
+# Authors:
+#  Jan Kiszka <jan.kiszka@siemens.com>
+#
+# SPDX-License-Identifier: MIT
+#
+
+. /scripts/cip-initramfs-functions
+
+if secure_boot_enabled; then 
+	exit 0
+fi
+
+ORIG_PATH="$PATH"
+export PATH="/usr/share/initramfs-sbkeys-hook:$PATH"
+
+if ! efi-readvar -v db | grep -q "has no entries"; then
+	export PATH="$ORIG_PATH"
+	log_warning_msg "Not securely booting, but keys already deployed"
+	exit 0
+fi
+
+log_begin_msg "Deploying EFI secure boot keys"
+efi-updatevar -f /usr/share/secure-boot-efi-keys/db.auth db
+efi-updatevar -f /usr/share/secure-boot-efi-keys/KEK.auth KEK
+efi-updatevar -f /usr/share/secure-boot-efi-keys/PK.auth PK
+log_end_msg
+
+log_success_msg "Rebooting after key deployment..."
+reboot
diff --git a/recipes-initramfs/initramfs-sbkeys-hook/files/mount-stub b/recipes-initramfs/initramfs-sbkeys-hook/files/mount-stub
new file mode 100755
index 00000000..408b584e
--- /dev/null
+++ b/recipes-initramfs/initramfs-sbkeys-hook/files/mount-stub
@@ -0,0 +1,13 @@
+#!/bin/sh
+#
+# CIP Core, generic profile
+#
+# Copyright (c) Siemens AG, 2026
+#
+# Authors:
+#  Jan Kiszka <jan.kiszka@siemens.com>
+#
+# SPDX-License-Identifier: MIT
+#
+
+echo "none on /sys/firmware/efi/efivars type efivarfs"
diff --git a/recipes-initramfs/initramfs-sbkeys-hook/initramfs-sbkeys-hook_0.1.bb b/recipes-initramfs/initramfs-sbkeys-hook/initramfs-sbkeys-hook_0.1.bb
new file mode 100644
index 00000000..bcbaf97b
--- /dev/null
+++ b/recipes-initramfs/initramfs-sbkeys-hook/initramfs-sbkeys-hook_0.1.bb
@@ -0,0 +1,32 @@
+#
+# CIP Core, generic profile
+#
+# Copyright (c) Siemens AG, 2026
+#
+# Authors:
+#  Jan Kiszka <jan.kiszka@siemens.com>
+#
+# SPDX-License-Identifier: MIT
+#
+
+inherit initramfs-hook
+
+MAINTAINER = "cip-dev <cip-dev@lists.cip-project.org>"
+DESCRIPTION = "Initramfs hook to deploy UEFI secure boot keys during early boot"
+
+DEPENDS = "secure-boot-efi-keys initramfs-cip-functions"
+DEBIAN_DEPENDS .= ", secure-boot-efi-keys, efitools, initramfs-cip-functions"
+
+HOOK_COPY_EXECS = "cmp mountpoint efi-readvar efi-updatevar grep"
+
+HOOK_ADD_MODULES = "efivarfs"
+
+SRC_URI += " \
+    file://hook \
+    file://local-top \
+    file://mount-stub"
+
+do_install[cleandirs] += "${D}/usr/share/${BPN}"
+do_install:append() {
+    install "${WORKDIR}/mount-stub" "${D}/usr/share/${BPN}/mount"
+}
-- 
2.47.3

Re: [isar-cip-core][PATCH 3/7] cip-core-initramfs: Automatically deploy secure boot keys on first boot

[Heinisch, Alexander (FT RPD CED SES-AT)]

Am 26.08.2026 um 07:41 schrieb Jan Kiszka:
> From: Jan Kiszka <jan.kiszka@siemens.com>
> 
> This both simplifies the initial deployment of secure boot to a device
> as well as makes sure that we will always seal the disk encryption key
> against the right state.
> 
> We only deploy if secure boot is off and the db is found empty. So this
> hook is not intended to be used for key exchange or key db extensions.
> The former will be once handled via SWUpdate packages, the latter might
> be considered given a concrete use case.
> 
> Note that due to the primitive implementation of efivarfs detection in
> efitools, we need to deploy a horrible hack to make it work against the
> mount implementation of busybox in the initramfs. A patch to improve
> that issue is pending upstream.
> 
> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
> ---
>   .../cip-core-initramfs/cip-core-initramfs.bb  |  1 +
>   .../initramfs-sbkeys-hook/files/hook          | 16 +++++++++
>   .../initramfs-sbkeys-hook/files/local-top     | 34 +++++++++++++++++++
>   .../initramfs-sbkeys-hook/files/mount-stub    | 13 +++++++
>   .../initramfs-sbkeys-hook_0.1.bb              | 32 +++++++++++++++++
>   5 files changed, 96 insertions(+)
>   create mode 100644 recipes-initramfs/initramfs-sbkeys-hook/files/hook
>   create mode 100644 recipes-initramfs/initramfs-sbkeys-hook/files/local-top
>   create mode 100755 recipes-initramfs/initramfs-sbkeys-hook/files/mount-stub
>   create mode 100644 recipes-initramfs/initramfs-sbkeys-hook/initramfs-sbkeys-hook_0.1.bb
> 
> diff --git a/recipes-initramfs/cip-core-initramfs/cip-core-initramfs.bb b/recipes-initramfs/cip-core-initramfs/cip-core-initramfs.bb
> index b686185c..241e6af6 100644
> --- a/recipes-initramfs/cip-core-initramfs/cip-core-initramfs.bb
> +++ b/recipes-initramfs/cip-core-initramfs/cip-core-initramfs.bb
> @@ -22,6 +22,7 @@ INITRAMFS_INSTALL:append:factory-reset = " initramfs-factory-reset-hook"
>   INITRAMFS_INSTALL:append:ftpm-stmm = " initramfs-tee-ftpm-hook"
>   INITRAMFS_INSTALL:append:swupdate = " initramfs-abrootfs-hook"
>   INITRAMFS_INSTALL:append:swupdate = " initramfs-${RO_ROOTFS_TYPE}-hook"
> +INITRAMFS_INSTALL:append:secureboot = " initramfs-sbkeys-hook"
>   INITRAMFS_INSTALL:append:secureboot = " initramfs-verity-hook"
>   # abrootfs cannot be installed together with verity
>   INITRAMFS_INSTALL:remove:secureboot = "initramfs-abrootfs-hook"
> diff --git a/recipes-initramfs/initramfs-sbkeys-hook/files/hook b/recipes-initramfs/initramfs-sbkeys-hook/files/hook
> new file mode 100644
> index 00000000..770d4454
> --- /dev/null
> +++ b/recipes-initramfs/initramfs-sbkeys-hook/files/hook
> @@ -0,0 +1,16 @@
> +#
> +# CIP Core, generic profile
> +#
> +# Copyright (c) Siemens AG, 2026
> +#
> +# Authors:
> +#  Jan Kiszka <jan.kiszka@siemens.com>
> +#
> +# SPDX-License-Identifier: MIT
> +#
> +
> +copy_file binary /usr/share/secure-boot-efi-keys/db.auth
> +copy_file binary /usr/share/secure-boot-efi-keys/KEK.auth
> +copy_file binary /usr/share/secure-boot-efi-keys/PK.auth
> +
> +copy_file binary /usr/share/initramfs-sbkeys-hook/mount
> diff --git a/recipes-initramfs/initramfs-sbkeys-hook/files/local-top b/recipes-initramfs/initramfs-sbkeys-hook/files/local-top
> new file mode 100644
> index 00000000..48fe45d4
> --- /dev/null
> +++ b/recipes-initramfs/initramfs-sbkeys-hook/files/local-top
> @@ -0,0 +1,34 @@
> +#
> +# CIP Core, generic profile
> +#
> +# Copyright (c) Siemens AG, 2026
> +#
> +# Authors:
> +#  Jan Kiszka <jan.kiszka@siemens.com>
> +#
> +# SPDX-License-Identifier: MIT
> +#
> +
> +. /scripts/cip-initramfs-functions
> +
> +if secure_boot_enabled; then
> +	exit 0
> +fi
> +
> +ORIG_PATH="$PATH"
> +export PATH="/usr/share/initramfs-sbkeys-hook:$PATH"
> +
> +if ! efi-readvar -v db | grep -q "has no entries"; then
> +	export PATH="$ORIG_PATH"
> +	log_warning_msg "Not securely booting, but keys already deployed"
> +	exit 0
> +fi
> +
> +log_begin_msg "Deploying EFI secure boot keys"
> +efi-updatevar -f /usr/share/secure-boot-efi-keys/db.auth db
> +efi-updatevar -f /usr/share/secure-boot-efi-keys/KEK.auth KEK
> +efi-updatevar -f /usr/share/secure-boot-efi-keys/PK.auth PK
> +log_end_msg
> +
> +log_success_msg "Rebooting after key deployment..."
> +reboot
> diff --git a/recipes-initramfs/initramfs-sbkeys-hook/files/mount-stub b/recipes-initramfs/initramfs-sbkeys-hook/files/mount-stub
> new file mode 100755
> index 00000000..408b584e
> --- /dev/null
> +++ b/recipes-initramfs/initramfs-sbkeys-hook/files/mount-stub
> @@ -0,0 +1,13 @@
> +#!/bin/sh
> +#
> +# CIP Core, generic profile
> +#
> +# Copyright (c) Siemens AG, 2026
> +#
> +# Authors:
> +#  Jan Kiszka <jan.kiszka@siemens.com>
> +#
> +# SPDX-License-Identifier: MIT
> +#
> +
> +echo "none on /sys/firmware/efi/efivars type efivarfs"
what about "cat /proc/mounts" to get the actual systems mount points 
instead of mocking expected behaviour?

> diff --git a/recipes-initramfs/initramfs-sbkeys-hook/initramfs-sbkeys-hook_0.1.bb b/recipes-initramfs/initramfs-sbkeys-hook/initramfs-sbkeys-hook_0.1.bb
> new file mode 100644
> index 00000000..bcbaf97b
> --- /dev/null
> +++ b/recipes-initramfs/initramfs-sbkeys-hook/initramfs-sbkeys-hook_0.1.bb
> @@ -0,0 +1,32 @@
> +#
> +# CIP Core, generic profile
> +#
> +# Copyright (c) Siemens AG, 2026
> +#
> +# Authors:
> +#  Jan Kiszka <jan.kiszka@siemens.com>
> +#
> +# SPDX-License-Identifier: MIT
> +#
> +
> +inherit initramfs-hook
> +
> +MAINTAINER = "cip-dev <cip-dev@lists.cip-project.org>"
> +DESCRIPTION = "Initramfs hook to deploy UEFI secure boot keys during early boot"
> +
> +DEPENDS = "secure-boot-efi-keys initramfs-cip-functions"
> +DEBIAN_DEPENDS .= ", secure-boot-efi-keys, efitools, initramfs-cip-functions"
> +
> +HOOK_COPY_EXECS = "cmp mountpoint efi-readvar efi-updatevar grep"
> +
> +HOOK_ADD_MODULES = "efivarfs"
> +
> +SRC_URI += " \
> +    file://hook \
> +    file://local-top \
> +    file://mount-stub"
> +
> +do_install[cleandirs] += "${D}/usr/share/${BPN}"
> +do_install:append() {
> +    install "${WORKDIR}/mount-stub" "${D}/usr/share/${BPN}/mount"
> +}

Re: [isar-cip-core][PATCH 3/7] cip-core-initramfs: Automatically deploy secure boot keys on first boot

[Jan Kiszka]

On 26.08.26 10:17, Heinisch, Alexander (FT RPD CED SES-AT) wrote:
> 
> 
> Am 26.08.2026 um 07:41 schrieb Jan Kiszka:
>> From: Jan Kiszka <jan.kiszka@siemens.com>
>>
>> This both simplifies the initial deployment of secure boot to a device
>> as well as makes sure that we will always seal the disk encryption key
>> against the right state.
>>
>> We only deploy if secure boot is off and the db is found empty. So this
>> hook is not intended to be used for key exchange or key db extensions.
>> The former will be once handled via SWUpdate packages, the latter might
>> be considered given a concrete use case.
>>
>> Note that due to the primitive implementation of efivarfs detection in
>> efitools, we need to deploy a horrible hack to make it work against the
>> mount implementation of busybox in the initramfs. A patch to improve
>> that issue is pending upstream.
>>
>> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
>> ---
>>   .../cip-core-initramfs/cip-core-initramfs.bb  |  1 +
>>   .../initramfs-sbkeys-hook/files/hook          | 16 +++++++++
>>   .../initramfs-sbkeys-hook/files/local-top     | 34 +++++++++++++++++++
>>   .../initramfs-sbkeys-hook/files/mount-stub    | 13 +++++++
>>   .../initramfs-sbkeys-hook_0.1.bb              | 32 +++++++++++++++++
>>   5 files changed, 96 insertions(+)
>>   create mode 100644 recipes-initramfs/initramfs-sbkeys-hook/files/hook
>>   create mode 100644 recipes-initramfs/initramfs-sbkeys-hook/files/
>> local-top
>>   create mode 100755 recipes-initramfs/initramfs-sbkeys-hook/files/
>> mount-stub
>>   create mode 100644 recipes-initramfs/initramfs-sbkeys-hook/
>> initramfs-sbkeys-hook_0.1.bb
>>
>> diff --git a/recipes-initramfs/cip-core-initramfs/cip-core-
>> initramfs.bb b/recipes-initramfs/cip-core-initramfs/cip-core-initramfs.bb
>> index b686185c..241e6af6 100644
>> --- a/recipes-initramfs/cip-core-initramfs/cip-core-initramfs.bb
>> +++ b/recipes-initramfs/cip-core-initramfs/cip-core-initramfs.bb
>> @@ -22,6 +22,7 @@ INITRAMFS_INSTALL:append:factory-reset = "
>> initramfs-factory-reset-hook"
>>   INITRAMFS_INSTALL:append:ftpm-stmm = " initramfs-tee-ftpm-hook"
>>   INITRAMFS_INSTALL:append:swupdate = " initramfs-abrootfs-hook"
>>   INITRAMFS_INSTALL:append:swupdate = " initramfs-${RO_ROOTFS_TYPE}-hook"
>> +INITRAMFS_INSTALL:append:secureboot = " initramfs-sbkeys-hook"
>>   INITRAMFS_INSTALL:append:secureboot = " initramfs-verity-hook"
>>   # abrootfs cannot be installed together with verity
>>   INITRAMFS_INSTALL:remove:secureboot = "initramfs-abrootfs-hook"
>> diff --git a/recipes-initramfs/initramfs-sbkeys-hook/files/hook b/
>> recipes-initramfs/initramfs-sbkeys-hook/files/hook
>> new file mode 100644
>> index 00000000..770d4454
>> --- /dev/null
>> +++ b/recipes-initramfs/initramfs-sbkeys-hook/files/hook
>> @@ -0,0 +1,16 @@
>> +#
>> +# CIP Core, generic profile
>> +#
>> +# Copyright (c) Siemens AG, 2026
>> +#
>> +# Authors:
>> +#  Jan Kiszka <jan.kiszka@siemens.com>
>> +#
>> +# SPDX-License-Identifier: MIT
>> +#
>> +
>> +copy_file binary /usr/share/secure-boot-efi-keys/db.auth
>> +copy_file binary /usr/share/secure-boot-efi-keys/KEK.auth
>> +copy_file binary /usr/share/secure-boot-efi-keys/PK.auth
>> +
>> +copy_file binary /usr/share/initramfs-sbkeys-hook/mount
>> diff --git a/recipes-initramfs/initramfs-sbkeys-hook/files/local-top
>> b/recipes-initramfs/initramfs-sbkeys-hook/files/local-top
>> new file mode 100644
>> index 00000000..48fe45d4
>> --- /dev/null
>> +++ b/recipes-initramfs/initramfs-sbkeys-hook/files/local-top
>> @@ -0,0 +1,34 @@
>> +#
>> +# CIP Core, generic profile
>> +#
>> +# Copyright (c) Siemens AG, 2026
>> +#
>> +# Authors:
>> +#  Jan Kiszka <jan.kiszka@siemens.com>
>> +#
>> +# SPDX-License-Identifier: MIT
>> +#
>> +
>> +. /scripts/cip-initramfs-functions
>> +
>> +if secure_boot_enabled; then
>> +    exit 0
>> +fi
>> +
>> +ORIG_PATH="$PATH"
>> +export PATH="/usr/share/initramfs-sbkeys-hook:$PATH"
>> +
>> +if ! efi-readvar -v db | grep -q "has no entries"; then
>> +    export PATH="$ORIG_PATH"
>> +    log_warning_msg "Not securely booting, but keys already deployed"
>> +    exit 0
>> +fi
>> +
>> +log_begin_msg "Deploying EFI secure boot keys"
>> +efi-updatevar -f /usr/share/secure-boot-efi-keys/db.auth db
>> +efi-updatevar -f /usr/share/secure-boot-efi-keys/KEK.auth KEK
>> +efi-updatevar -f /usr/share/secure-boot-efi-keys/PK.auth PK
>> +log_end_msg
>> +
>> +log_success_msg "Rebooting after key deployment..."
>> +reboot
>> diff --git a/recipes-initramfs/initramfs-sbkeys-hook/files/mount-stub
>> b/recipes-initramfs/initramfs-sbkeys-hook/files/mount-stub
>> new file mode 100755
>> index 00000000..408b584e
>> --- /dev/null
>> +++ b/recipes-initramfs/initramfs-sbkeys-hook/files/mount-stub
>> @@ -0,0 +1,13 @@
>> +#!/bin/sh
>> +#
>> +# CIP Core, generic profile
>> +#
>> +# Copyright (c) Siemens AG, 2026
>> +#
>> +# Authors:
>> +#  Jan Kiszka <jan.kiszka@siemens.com>
>> +#
>> +# SPDX-License-Identifier: MIT
>> +#
>> +
>> +echo "none on /sys/firmware/efi/efivars type efivarfs"
> what about "cat /proc/mounts" to get the actual systems mount points
> instead of mocking expected behaviour?
> 

https://git.kernel.org/pub/scm/linux/kernel/git/jejb/efitools.git/tree/lib/kernel_efivars.c#n69

Was my first try as well, before reading that.

Jan

-- 
Siemens AG, Foundational Technologies
Linux Expert Center

[isar-cip-core][PATCH 4/7] u-boot: Add patches to enable measured boot with fTPM

[Jan Kiszka]

From: Jan Kiszka <jan.kiszka@siemens.com>

U-Boot was so far not enumerating the fTPM device, and that caused the
PCRs to stay zero. systemd-cryptenroll was complaining already, just not
loud enough.

With these extra patches (currently under review upstream), we are
getting a TPM right before the EFI loader starts, and we get valid PCR
content as well.

Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
---
 ...ement-Fix-compilation-for-non-sandbo.patch |  43 +++++
 ...-out-service-enumeration-and-binding.patch |  95 +++++++++++
 ...pport-for-enumerating-services-that-.patch | 155 ++++++++++++++++++
 ...-warn-about-TEE_ERROR_STORAGE_NOT_AV.patch |  33 ++++
 ...to-optee-after-a-successful-mmc_init.patch |  41 +++++
 ...-MMC-Device-not-found-a-debug-output.patch |  50 ++++++
 recipes-bsp/u-boot/u-boot-common-2026.01.inc  |   6 +
 7 files changed, 423 insertions(+)
 create mode 100644 recipes-bsp/u-boot/files/0001-test-boot-measurement-Fix-compilation-for-non-sandbo.patch
 create mode 100644 recipes-bsp/u-boot/files/0002-tee-optee-Factor-out-service-enumeration-and-binding.patch
 create mode 100644 recipes-bsp/u-boot/files/0003-tee-optee-Add-support-for-enumerating-services-that-.patch
 create mode 100644 recipes-bsp/u-boot/files/0004-tee-optee-Do-not-warn-about-TEE_ERROR_STORAGE_NOT_AV.patch
 create mode 100644 recipes-bsp/u-boot/files/0005-mmc-Call-back-to-optee-after-a-successful-mmc_init.patch
 create mode 100644 recipes-bsp/u-boot/files/0006-mmc-Make-MMC-Device-not-found-a-debug-output.patch

diff --git a/recipes-bsp/u-boot/files/0001-test-boot-measurement-Fix-compilation-for-non-sandbo.patch b/recipes-bsp/u-boot/files/0001-test-boot-measurement-Fix-compilation-for-non-sandbo.patch
new file mode 100644
index 00000000..c5b920b1
--- /dev/null
+++ b/recipes-bsp/u-boot/files/0001-test-boot-measurement-Fix-compilation-for-non-sandbo.patch
@@ -0,0 +1,43 @@
+From 1d9a066892b73d65129cb899c6ed611eb3d1c3bc Mon Sep 17 00:00:00 2001
+From: Jan Kiszka <jan.kiszka@siemens.com>
+Date: Thu, 20 Aug 2026 17:30:54 +0200
+Subject: [PATCH 1/6] test: boot: measurement: Fix compilation for non-sandbox
+ builds
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+asm/io.h provides map_to_sysmem() only for the sandbox. Other targets
+fail the build with
+
+../test/boot/measurement.c: In function ‘measure’:
+../test/boot/measurement.c:30:33: error: implicit declaration of function ‘map_to_sysmem’; did you mean ‘map_physmem’? [-Wimplicit-function-declaration]
+   30 |         images.os.image_start = map_to_sysmem(kernel);
+      |                                 ^~~~~~~~~~~~~
+      |                                 map_physmem
+
+Use the proper header that will pull asm/io.h only where needed.
+
+Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
+---
+ test/boot/measurement.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/test/boot/measurement.c b/test/boot/measurement.c
+index 71f503f1567..85a01f1fec8 100644
+--- a/test/boot/measurement.c
++++ b/test/boot/measurement.c
+@@ -9,9 +9,9 @@
+ #include <bootm.h>
+ #include <env.h>
+ #include <malloc.h>
++#include <mapmem.h>
+ #include <test/test.h>
+ #include <test/ut.h>
+-#include <asm/io.h>
+ 
+ #define MEASUREMENT_TEST(_name, _flags)	\
+ 	UNIT_TEST(_name, _flags, measurement)
+-- 
+2.47.3
+
diff --git a/recipes-bsp/u-boot/files/0002-tee-optee-Factor-out-service-enumeration-and-binding.patch b/recipes-bsp/u-boot/files/0002-tee-optee-Factor-out-service-enumeration-and-binding.patch
new file mode 100644
index 00000000..b7aef59c
--- /dev/null
+++ b/recipes-bsp/u-boot/files/0002-tee-optee-Factor-out-service-enumeration-and-binding.patch
@@ -0,0 +1,95 @@
+From 70c9bcf676e253ed8c86699237c74e41c86eb34a Mon Sep 17 00:00:00 2001
+From: Jan Kiszka <jan.kiszka@siemens.com>
+Date: Sun, 23 Aug 2026 20:25:03 +0200
+Subject: [PATCH 2/6] tee: optee: Factor out service enumeration and binding
+ functions
+
+This already avoids code duplication between the different enumeration
+commands. It will furthermore allow to implement a third one for
+services with RPMB needs.
+
+Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
+---
+ drivers/tee/optee/core.c          | 33 +++++++++++++++++--------------
+ drivers/tee/optee/optee_private.h |  3 +++
+ 2 files changed, 21 insertions(+), 15 deletions(-)
+
+diff --git a/drivers/tee/optee/core.c b/drivers/tee/optee/core.c
+index 4d67c948ec1..2871760a7b7 100644
+--- a/drivers/tee/optee/core.c
++++ b/drivers/tee/optee/core.c
+@@ -156,7 +156,7 @@ static int enum_services(struct udevice *dev, struct tee_shm **shm, size_t *coun
+ 	return ret;
+ }
+ 
+-static int open_enum_session(struct udevice *dev, u32 *tee_sess)
++int optee_open_enum_session(struct udevice *dev, u32 *tee_sess)
+ {
+ 	const struct tee_optee_ta_uuid pta_uuid = PTA_DEVICE_ENUM;
+ 	struct tee_open_session_arg arg = { };
+@@ -176,31 +176,34 @@ static int open_enum_session(struct udevice *dev, u32 *tee_sess)
+ 	return 0;
+ }
+ 
+-static int bind_service_drivers(struct udevice *dev)
++int optee_bind_services(struct udevice *dev, u32 tee_sess,
++			unsigned int pta_cmd)
+ {
+ 	struct tee_shm *service_list = NULL;
+ 	size_t service_count;
+-	u32 tee_sess;
+-	int ret, ret2;
+-
+-	ret = open_enum_session(dev, &tee_sess);
+-	if (ret)
+-		return ret;
++	int ret;
+ 
+ 	ret = enum_services(dev, &service_list, &service_count, tee_sess,
+-			    PTA_CMD_GET_DEVICES);
++			    pta_cmd);
+ 	if (!ret && service_count)
+ 		ret = bind_service_list(dev, service_list, service_count);
+ 
+ 	tee_shm_free(service_list);
+-	service_list = NULL;
+ 
+-	ret2 = enum_services(dev, &service_list, &service_count, tee_sess,
+-			     PTA_CMD_GET_DEVICES_SUPP);
+-	if (!ret2 && service_count)
+-		ret2 = bind_service_list(dev, service_list, service_count);
++	return ret;
++}
++
++static int bind_service_drivers(struct udevice *dev)
++{
++	u32 tee_sess;
++	int ret, ret2;
+ 
+-	tee_shm_free(service_list);
++	ret = optee_open_enum_session(dev, &tee_sess);
++	if (ret)
++		return ret;
++
++	ret = optee_bind_services(dev, tee_sess, PTA_CMD_GET_DEVICES);
++	ret2 = optee_bind_services(dev, tee_sess, PTA_CMD_GET_DEVICES_SUPP);
+ 
+ 	tee_close_session(dev, tee_sess);
+ 
+diff --git a/drivers/tee/optee/optee_private.h b/drivers/tee/optee/optee_private.h
+index 1f07a27ee4b..25b6b3c3218 100644
+--- a/drivers/tee/optee/optee_private.h
++++ b/drivers/tee/optee/optee_private.h
+@@ -27,6 +27,9 @@ struct optee_msg_arg;
+ 
+ void optee_suppl_cmd(struct udevice *dev, struct tee_shm *shm_arg,
+ 		     void **page_list);
++int optee_open_enum_session(struct udevice *dev, u32 *tee_sess);
++int optee_bind_services(struct udevice *dev, u32 tee_sess,
++			unsigned int pta_cmd);
+ 
+ #ifdef CONFIG_SUPPORT_EMMC_RPMB
+ /**
+-- 
+2.47.3
+
diff --git a/recipes-bsp/u-boot/files/0003-tee-optee-Add-support-for-enumerating-services-that-.patch b/recipes-bsp/u-boot/files/0003-tee-optee-Add-support-for-enumerating-services-that-.patch
new file mode 100644
index 00000000..a037303d
--- /dev/null
+++ b/recipes-bsp/u-boot/files/0003-tee-optee-Add-support-for-enumerating-services-that-.patch
@@ -0,0 +1,155 @@
+From 1794934500e5580309f4a8cb064bd035cb9b23d4 Mon Sep 17 00:00:00 2001
+From: Jan Kiszka <jan.kiszka@siemens.com>
+Date: Fri, 21 Aug 2026 08:39:26 +0200
+Subject: [PATCH 3/6] tee: optee: Add support for enumerating services that
+ only need RPMB
+
+Up to OP-TEE 4.4.0, all services that needed a supplicant where returned
+by PTA_CMD_GET_DEVICES_SUPP. Since then, services that only need a
+supplicant for the purpose of accessing the RPMB are only enumerated by
+the new, separate PTA_CMD_GET_DEVICES_RPMB. U-Boot so far lacks support
+for that, thus no longer finds such services, e.g. fTPM.
+
+Perform the separate enumeration during probe but, as that may fail if
+the MMC is not probed yet, also provide a callback to trigger a retry
+when another MMC device becomes available.
+
+Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
+---
+ drivers/tee/optee/core.c          | 22 +++++++---------------
+ drivers/tee/optee/optee_private.h | 21 +++++++++++++++++++++
+ drivers/tee/optee/rpmb.c          | 19 +++++++++++++++++++
+ include/tee/optee.h               |  6 ++++++
+ 4 files changed, 53 insertions(+), 15 deletions(-)
+
+diff --git a/drivers/tee/optee/core.c b/drivers/tee/optee/core.c
+index 2871760a7b7..ed8f2b6ec74 100644
+--- a/drivers/tee/optee/core.c
++++ b/drivers/tee/optee/core.c
+@@ -27,19 +27,6 @@
+  */
+ #define PTA_DEVICE_ENUM		{ 0x7011a688, 0xddde, 0x4053, \
+ 				  { 0xa5, 0xa9, 0x7b, 0x3c, 0x4d, 0xdf, 0x13, 0xb8 } }
+-/*
+- * PTA_CMD_GET_DEVICES - List services without supplicant dependencies
+- *
+- * [out]    memref[0]: List of the UUIDs of service enumerated by OP-TEE
+- */
+-#define PTA_CMD_GET_DEVICES		0x0
+-
+-/*
+- * PTA_CMD_GET_DEVICES_SUPP - List services depending on tee supplicant
+- *
+- * [out]    memref[0]: List of the UUIDs of service enumerated by OP-TEE
+- */
+-#define PTA_CMD_GET_DEVICES_SUPP	0x1
+ 
+ typedef void (optee_invoke_fn)(unsigned long, unsigned long, unsigned long,
+ 			       unsigned long, unsigned long, unsigned long,
+@@ -195,8 +182,8 @@ int optee_bind_services(struct udevice *dev, u32 tee_sess,
+ 
+ static int bind_service_drivers(struct udevice *dev)
+ {
++	int ret, ret2, ret3 = 0;
+ 	u32 tee_sess;
+-	int ret, ret2;
+ 
+ 	ret = optee_open_enum_session(dev, &tee_sess);
+ 	if (ret)
+@@ -204,13 +191,18 @@ static int bind_service_drivers(struct udevice *dev)
+ 
+ 	ret = optee_bind_services(dev, tee_sess, PTA_CMD_GET_DEVICES);
+ 	ret2 = optee_bind_services(dev, tee_sess, PTA_CMD_GET_DEVICES_SUPP);
++	if (CONFIG_IS_ENABLED(SUPPORT_EMMC_RPMB))
++		ret3 = optee_bind_services(dev, tee_sess,
++					   PTA_CMD_GET_DEVICES_RPMB);
+ 
+ 	tee_close_session(dev, tee_sess);
+ 
+ 	if (ret)
+ 		return ret;
++	if (ret2)
++		return ret2;
+ 
+-	return ret2;
++	return ret3;
+ }
+ 
+ /**
+diff --git a/drivers/tee/optee/optee_private.h b/drivers/tee/optee/optee_private.h
+index 25b6b3c3218..daff3e04493 100644
+--- a/drivers/tee/optee/optee_private.h
++++ b/drivers/tee/optee/optee_private.h
+@@ -9,6 +9,27 @@
+ #include <tee.h>
+ #include <log.h>
+ 
++/*
++ * PTA_CMD_GET_DEVICES - List services without supplicant dependencies
++ *
++ * [out]    memref[0]: List of the UUIDs of service enumerated by OP-TEE
++ */
++#define PTA_CMD_GET_DEVICES		0x0
++
++/*
++ * PTA_CMD_GET_DEVICES_SUPP - List services depending on tee supplicant
++ *
++ * [out]    memref[0]: List of the UUIDs of service enumerated by OP-TEE
++ */
++#define PTA_CMD_GET_DEVICES_SUPP	0x1
++
++/*
++ * PTA_CMD_GET_DEVICES_RPMB - List services only depending on RPMB support
++ *
++ * [out]    memref[0]: List of the UUIDs of service enumerated by OP-TEE
++ */
++#define PTA_CMD_GET_DEVICES_RPMB	0x2
++
+ /**
+  * struct optee_private - OP-TEE driver private data
+  * @rpmb_mmc:		mmc device for the RPMB partition
+diff --git a/drivers/tee/optee/rpmb.c b/drivers/tee/optee/rpmb.c
+index bacced6af6c..f7312d7171c 100644
+--- a/drivers/tee/optee/rpmb.c
++++ b/drivers/tee/optee/rpmb.c
+@@ -191,3 +191,22 @@ void optee_suppl_rpmb_release(struct udevice *dev)
+ {
+ 	release_mmc(dev_get_priv(dev));
+ }
++
++void optee_rpmb_available(void)
++{
++	struct udevice *dev;
++	struct uclass *uc;
++	u32 tee_sess;
++
++	uclass_id_foreach_dev(UCLASS_TEE, dev, uc) {
++		if (strcmp(dev->driver->name, "optee") != 0)
++			continue;
++
++		if (optee_open_enum_session(dev, &tee_sess) != 0)
++			continue;
++
++		optee_bind_services(dev, tee_sess, PTA_CMD_GET_DEVICES_RPMB);
++
++		tee_close_session(dev, tee_sess);
++	}
++}
+diff --git a/include/tee/optee.h b/include/tee/optee.h
+index d1194493780..755533b2c0b 100644
+--- a/include/tee/optee.h
++++ b/include/tee/optee.h
+@@ -74,4 +74,10 @@ static inline bool is_optee_smc_api(void)
+ }
+ #endif
+ 
++#if defined(CONFIG_OPTEE) && defined(CONFIG_SUPPORT_EMMC_RPMB)
++void optee_rpmb_available(void);
++#else
++static inline void optee_rpmb_available(void) {}
++#endif
++
+ #endif /* _OPTEE_H */
+-- 
+2.47.3
+
diff --git a/recipes-bsp/u-boot/files/0004-tee-optee-Do-not-warn-about-TEE_ERROR_STORAGE_NOT_AV.patch b/recipes-bsp/u-boot/files/0004-tee-optee-Do-not-warn-about-TEE_ERROR_STORAGE_NOT_AV.patch
new file mode 100644
index 00000000..41291e21
--- /dev/null
+++ b/recipes-bsp/u-boot/files/0004-tee-optee-Do-not-warn-about-TEE_ERROR_STORAGE_NOT_AV.patch
@@ -0,0 +1,33 @@
+From 13fc430cf440cdbc490bce630031ca49e81e1e13 Mon Sep 17 00:00:00 2001
+From: Jan Kiszka <jan.kiszka@siemens.com>
+Date: Fri, 21 Aug 2026 09:02:23 +0200
+Subject: [PATCH 4/6] tee: optee: Do not warn about
+ TEE_ERROR_STORAGE_NOT_AVAILABLE
+
+This is a transitional error that is resolved once an RPMB becomes
+available. Keep it as debug output only.
+
+Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
+---
+ drivers/tee/optee/core.c | 5 ++++-
+ 1 file changed, 4 insertions(+), 1 deletion(-)
+
+diff --git a/drivers/tee/optee/core.c b/drivers/tee/optee/core.c
+index ed8f2b6ec74..d3b5811afb8 100644
+--- a/drivers/tee/optee/core.c
++++ b/drivers/tee/optee/core.c
+@@ -106,7 +106,10 @@ static int __enum_services(struct udevice *dev, struct tee_shm *shm, size_t *shm
+ 
+ 	ret = tee_invoke_func(dev, &arg, 1, &param);
+ 	if (ret || (arg.ret && arg.ret != TEE_ERROR_SHORT_BUFFER)) {
+-		dev_err(dev, "Enumeration command 0x%x failed: 0x%x\n", pta_cmd, arg.ret);
++		if (arg.ret != TEE_ERROR_STORAGE_NOT_AVAILABLE)
++			dev_err(dev, "Enumeration command 0x%x failed: 0x%x\n", pta_cmd, arg.ret);
++		else
++			dev_dbg(dev, "Enumeration command 0x%x failed due to unavailable storage\n", pta_cmd);
+ 		return -EINVAL;
+ 	}
+ 
+-- 
+2.47.3
+
diff --git a/recipes-bsp/u-boot/files/0005-mmc-Call-back-to-optee-after-a-successful-mmc_init.patch b/recipes-bsp/u-boot/files/0005-mmc-Call-back-to-optee-after-a-successful-mmc_init.patch
new file mode 100644
index 00000000..8976582c
--- /dev/null
+++ b/recipes-bsp/u-boot/files/0005-mmc-Call-back-to-optee-after-a-successful-mmc_init.patch
@@ -0,0 +1,41 @@
+From ddef88ae1677f4c9b793252483f23eae900b89d1 Mon Sep 17 00:00:00 2001
+From: Jan Kiszka <jan.kiszka@siemens.com>
+Date: Fri, 21 Aug 2026 08:49:05 +0200
+Subject: [PATCH 5/6] mmc: Call back to optee after a successful mmc_init
+
+This is needed to that OP-TEE can re-enumerate services which need RPMB
+access that may have become available now.
+
+Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
+---
+CC: Peng Fan <peng.fan@nxp.com>
+CC: Jaehoon Chung <jh80.chung@samsung.com>
+---
+ drivers/mmc/mmc.c | 4 ++++
+ 1 file changed, 4 insertions(+)
+
+diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
+index 670e92ee12b..2463e50cd3c 100644
+--- a/drivers/mmc/mmc.c
++++ b/drivers/mmc/mmc.c
+@@ -27,6 +27,7 @@
+ #include <linux/list.h>
+ #include <linux/printk.h>
+ #include <div64.h>
++#include <tee/optee.h>
+ #include "mmc_private.h"
+ 
+ #define DEFAULT_CMD6_TIMEOUT_MS  500
+@@ -3168,6 +3169,9 @@ int mmc_init(struct mmc *mmc)
+ 				mmc->cfg->name);
+ 	}
+ 
++	if (CONFIG_IS_ENABLED(OPTEE) && mmc->capacity_rpmb > 0)
++		optee_rpmb_available();
++
+ 	return err;
+ }
+ 
+-- 
+2.47.3
+
diff --git a/recipes-bsp/u-boot/files/0006-mmc-Make-MMC-Device-not-found-a-debug-output.patch b/recipes-bsp/u-boot/files/0006-mmc-Make-MMC-Device-not-found-a-debug-output.patch
new file mode 100644
index 00000000..a1533d47
--- /dev/null
+++ b/recipes-bsp/u-boot/files/0006-mmc-Make-MMC-Device-not-found-a-debug-output.patch
@@ -0,0 +1,50 @@
+From 57a99d87a25d42f68f26697b81fafefcae29abad Mon Sep 17 00:00:00 2001
+From: Jan Kiszka <jan.kiszka@siemens.com>
+Date: Fri, 21 Aug 2026 11:00:09 +0200
+Subject: [PATCH 6/6] mmc: Make "MMC Device not found" a debug output
+
+Callers of find_mmc_device are generally processing and informing about
+errors already, e.g.
+
+=> mmc dev 2
+MMC Device 2 not found
+no mmc device at slot 2
+
+Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
+---
+CC: Peng Fan <peng.fan@nxp.com>
+CC: Jaehoon Chung <jh80.chung@samsung.com>
+---
+ drivers/mmc/mmc-uclass.c | 2 +-
+ drivers/mmc/mmc_legacy.c | 2 +-
+ 2 files changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/drivers/mmc/mmc-uclass.c b/drivers/mmc/mmc-uclass.c
+index 698530088fe..ec16899f92e 100644
+--- a/drivers/mmc/mmc-uclass.c
++++ b/drivers/mmc/mmc-uclass.c
+@@ -319,7 +319,7 @@ struct mmc *find_mmc_device(int dev_num)
+ 
+ 	if (ret) {
+ #if !defined(CONFIG_XPL_BUILD) || defined(CONFIG_SPL_LIBCOMMON_SUPPORT)
+-		printf("MMC Device %d not found\n", dev_num);
++		dev_dbg(dev, "MMC Device %d not found\n", dev_num);
+ #endif
+ 		return NULL;
+ 	}
+diff --git a/drivers/mmc/mmc_legacy.c b/drivers/mmc/mmc_legacy.c
+index 8f8ba34be71..573521842f6 100644
+--- a/drivers/mmc/mmc_legacy.c
++++ b/drivers/mmc/mmc_legacy.c
+@@ -45,7 +45,7 @@ struct mmc *find_mmc_device(int dev_num)
+ 	}
+ 
+ #if !defined(CONFIG_XPL_BUILD) || defined(CONFIG_SPL_LIBCOMMON_SUPPORT)
+-	printf("MMC Device %d not found\n", dev_num);
++	dev_dbg(dev, "MMC Device %d not found\n", dev_num);
+ #endif
+ 
+ 	return NULL;
+-- 
+2.47.3
+
diff --git a/recipes-bsp/u-boot/u-boot-common-2026.01.inc b/recipes-bsp/u-boot/u-boot-common-2026.01.inc
index 850847fd..0c864a82 100644
--- a/recipes-bsp/u-boot/u-boot-common-2026.01.inc
+++ b/recipes-bsp/u-boot/u-boot-common-2026.01.inc
@@ -26,6 +26,12 @@ SRC_URI += " \
     file://0001-riscv-create-a-custom-CPU-implementation-for-PolarFi.patch \
     file://0002-riscv-mpfs-move-SoC-level-options-to-the-CPU-Kconfig.patch \
     file://0003-riscv-Add-support-for-BeagleV-Fire.patch \
+    file://0001-test-boot-measurement-Fix-compilation-for-non-sandbo.patch \
+    file://0002-tee-optee-Factor-out-service-enumeration-and-binding.patch \
+    file://0003-tee-optee-Add-support-for-enumerating-services-that-.patch \
+    file://0004-tee-optee-Do-not-warn-about-TEE_ERROR_STORAGE_NOT_AV.patch \
+    file://0005-mmc-Call-back-to-optee-after-a-successful-mmc_init.patch \
+    file://0006-mmc-Make-MMC-Device-not-found-a-debug-output.patch \
     file://rules.tmpl;subdir=debian"
 SRC_URI[sha256sum] = "b60d5865cefdbc75da8da4156c56c458e00de75a49b80c1a2e58a96e30ad0d54"
 
-- 
2.47.3

[isar-cip-core][PATCH 5/7] u-boot: Refactor ftpm-stmm.cfg to enable measured boot for all

[Jan Kiszka]

From: Jan Kiszka <jan.kiszka@siemens.com>

Move the common bits out the ti-extra.cfg into the shared ftpm-stmm.cfg
which is consumed by the am62px unconditionally. Any commands, though,
should be selected at board level because they are not needed for the
fTPM and StMM functionalities.

While at it, fix the header of the ti-extra.cfg so that its bits get
removed before being re-applied.

Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
---
 recipes-bsp/u-boot/files/ftpm-stmm.cfg  | 7 ++++++-
 recipes-bsp/u-boot/files/qemu-extra.cfg | 2 ++
 recipes-bsp/u-boot/files/ti-extra.cfg   | 8 +-------
 3 files changed, 9 insertions(+), 8 deletions(-)

diff --git a/recipes-bsp/u-boot/files/ftpm-stmm.cfg b/recipes-bsp/u-boot/files/ftpm-stmm.cfg
index a6fe2a38..21032d12 100644
--- a/recipes-bsp/u-boot/files/ftpm-stmm.cfg
+++ b/recipes-bsp/u-boot/files/ftpm-stmm.cfg
@@ -4,5 +4,10 @@
 ### Enable OPTEE, fTPM and StMM
 CONFIG_TEE=y
 CONFIG_OPTEE=y
-CONFIG_CMD_OPTEE_RPMB=y
+CONFIG_OPTEE_SERVICE_DISCOVERY=y
 CONFIG_EFI_MM_COMM_TEE=y
+CONFIG_TPM=y
+CONFIG_TPM_V2=y
+CONFIG_TPM2_FTPM_TEE=y
+CONFIG_MEASURED_BOOT=y
+CONFIG_EFI_TCG2_PROTOCOL=y
diff --git a/recipes-bsp/u-boot/files/qemu-extra.cfg b/recipes-bsp/u-boot/files/qemu-extra.cfg
index 5380ad83..867cafac 100644
--- a/recipes-bsp/u-boot/files/qemu-extra.cfg
+++ b/recipes-bsp/u-boot/files/qemu-extra.cfg
@@ -10,3 +10,5 @@ CONFIG_MMC_SDHCI=y
 CONFIG_CMD_MMC=y
 CONFIG_CMD_MMC_REG=y
 CONFIG_EFI_SCROLL_ON_CLEAR_SCREEN=y
+CONFIG_CMD_OPTEE_RPMB=y
+CONFIG_CMD_TPM=y
diff --git a/recipes-bsp/u-boot/files/ti-extra.cfg b/recipes-bsp/u-boot/files/ti-extra.cfg
index 9500055f..38d12dd0 100644
--- a/recipes-bsp/u-boot/files/ti-extra.cfg
+++ b/recipes-bsp/u-boot/files/ti-extra.cfg
@@ -1,17 +1,11 @@
 #
 # SPDX-License-Identifier: MIT
 #
-### FTPM + RPMB + StandaloneMM setup
-CONFIG_OPTEE_SERVICE_DISCOVERY=y
-CONFIG_TPM=y
-CONFIG_TPM_V2=y
+### TI extra config
 CONFIG_CMD_TPM=y
-CONFIG_TPM2_FTPM_TEE=y
 CONFIG_SUPPORT_EMMC_RPMB=y
-CONFIG_MEASURED_BOOT=y
 CONFIG_CMD_NVEDIT_EFI=y
 CONFIG_CMD_MMC_RPMB=y
-CONFIG_EFI_TCG2_PROTOCOL=n
 
 # workaround for v2025.07
 CONFIG_USB_STORAGE=y
-- 
2.47.3

[isar-cip-core][PATCH 6/7] u-boot: Drop obsolete config workaround

[Jan Kiszka]

From: Jan Kiszka <jan.kiszka@siemens.com>

We moved to a newer U-Boot version meanwhile which resolved that issue.

Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
---
 recipes-bsp/u-boot/files/secure-boot.cfg | 2 --
 1 file changed, 2 deletions(-)

diff --git a/recipes-bsp/u-boot/files/secure-boot.cfg b/recipes-bsp/u-boot/files/secure-boot.cfg
index 7b09a53e..15a2bdf3 100644
--- a/recipes-bsp/u-boot/files/secure-boot.cfg
+++ b/recipes-bsp/u-boot/files/secure-boot.cfg
@@ -17,5 +17,3 @@ CONFIG_FS_FAT=y
 CONFIG_EFI_SECURE_BOOT=y
 # overruled by CONFIG_EFI_MM_COMM_TEE where available
 CONFIG_EFI_VARIABLES_PRESEED=y
-# workaround for v2025.07
-CONFIG_CMD_DHCP=y
-- 
2.47.3

[isar-cip-core][PATCH 7/7] initramfs-crypt-hook: Prevent encryption without secure boot

[Jan Kiszka]

From: Jan Kiszka <jan.kiszka@siemens.com>

We so far allowed to run first-boot encryption in any secure boot state.
This remained unnoticed because the QEMU x86 machine is started with
keys provisioned, and the QEMU arm64 machine does not support measured
boot yet. The latter is fixed, and we also deploy keys during first boot
now if they aren't pre-deployed. Time to raise the bar and reject
generally insecure states.

Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
---
 .../initramfs-crypt-hook/files/local-top-complete             | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/recipes-initramfs/initramfs-crypt-hook/files/local-top-complete b/recipes-initramfs/initramfs-crypt-hook/files/local-top-complete
index 7bc08e55..3312e632 100755
--- a/recipes-initramfs/initramfs-crypt-hook/files/local-top-complete
+++ b/recipes-initramfs/initramfs-crypt-hook/files/local-top-complete
@@ -297,6 +297,10 @@ for partition_set in $partition_sets; do
 		continue
 	fi
 
+	if ! secure_boot_enabled; then
+		panic "Secure boot disabled! Must be enabled to ensure correct key sealing."
+	fi
+
 	# check if we are trying to mount root, set ROOT to decrypted partition:
 	if [ "$partition_mountpoint" = "/" ]; then
 		echo "ROOT=$decrypted_part" >/conf/param.conf
-- 
2.47.3

Re: [isar-cip-core][PATCH 7/7] initramfs-crypt-hook: Prevent encryption without secure boot

[Quirin Gylstorff]

On 8/26/26 7:41 AM, Jan Kiszka wrote:
> From: Jan Kiszka <jan.kiszka@siemens.com>
> 
> We so far allowed to run first-boot encryption in any secure boot state.
> This remained unnoticed because the QEMU x86 machine is started with
> keys provisioned, and the QEMU arm64 machine does not support measured
> boot yet. The latter is fixed, and we also deploy keys during first boot
> now if they aren't pre-deployed. Time to raise the bar and reject
> generally insecure states.
> 
> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
> ---
>   .../initramfs-crypt-hook/files/local-top-complete             | 4 ++++
>   1 file changed, 4 insertions(+)
> 
> diff --git a/recipes-initramfs/initramfs-crypt-hook/files/local-top-complete b/recipes-initramfs/initramfs-crypt-hook/files/local-top-complete
> index 7bc08e55..3312e632 100755
> --- a/recipes-initramfs/initramfs-crypt-hook/files/local-top-complete
> +++ b/recipes-initramfs/initramfs-crypt-hook/files/local-top-complete
> @@ -297,6 +297,10 @@ for partition_set in $partition_sets; do
>   		continue
>   	fi
>   
> +	if ! secure_boot_enabled; then
> +		panic "Secure boot disabled! Must be enabled to ensure correct key sealing."
> +	fi
> +
Why is this check execute for each encrypted partiton.
We could test this in front of the loop?

Quirin

>   	# check if we are trying to mount root, set ROOT to decrypted partition:
>   	if [ "$partition_mountpoint" = "/" ]; then
>   		echo "ROOT=$decrypted_part" >/conf/param.conf

Re: [isar-cip-core][PATCH 7/7] initramfs-crypt-hook: Prevent encryption without secure boot

[Jan Kiszka]

On 01.10.26 11:41, Quirin Gylstorff wrote:
> 
> 
> On 8/26/26 7:41 AM, Jan Kiszka wrote:
>> From: Jan Kiszka <jan.kiszka@siemens.com>
>>
>> We so far allowed to run first-boot encryption in any secure boot state.
>> This remained unnoticed because the QEMU x86 machine is started with
>> keys provisioned, and the QEMU arm64 machine does not support measured
>> boot yet. The latter is fixed, and we also deploy keys during first boot
>> now if they aren't pre-deployed. Time to raise the bar and reject
>> generally insecure states.
>>
>> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
>> ---
>>   .../initramfs-crypt-hook/files/local-top-complete             | 4 ++++
>>   1 file changed, 4 insertions(+)
>>
>> diff --git a/recipes-initramfs/initramfs-crypt-hook/files/local-top-
>> complete b/recipes-initramfs/initramfs-crypt-hook/files/local-top-
>> complete
>> index 7bc08e55..3312e632 100755
>> --- a/recipes-initramfs/initramfs-crypt-hook/files/local-top-complete
>> +++ b/recipes-initramfs/initramfs-crypt-hook/files/local-top-complete
>> @@ -297,6 +297,10 @@ for partition_set in $partition_sets; do
>>           continue
>>       fi
>>   +    if ! secure_boot_enabled; then
>> +        panic "Secure boot disabled! Must be enabled to ensure
>> correct key sealing."
>> +    fi
>> +
> Why is this check execute for each encrypted partiton.
> We could test this in front of the loop?
> 

We only want to enforce this rule when there is actually encryption
requested, and that requires to iterate over the entries.

Jan

-- 
Siemens AG, Foundational Technologies
Linux Expert Center

[isar-cip-core][PATCH 8/7] doc: Update README.secureboot regarding recent deployment enhancements

[Jan Kiszka]

From: Jan Kiszka <jan.kiszka@siemens.com>

Explain the automatic certificates deployment and its dependencies.
There is no longer the need to explain manual key creation, we can
simply reference the new single-key-to-efi-certs package. Keep the
manual deployment method for special causes.

Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
---
 doc/README.secureboot.md | 39 +++++++++++++++++++++++++++++----------
 1 file changed, 29 insertions(+), 10 deletions(-)

diff --git a/doc/README.secureboot.md b/doc/README.secureboot.md
index 3bcb3f58..2a387f07 100644
--- a/doc/README.secureboot.md
+++ b/doc/README.secureboot.md
@@ -273,32 +273,51 @@ lrwxrwxrwx 1 root root 0 Jun 30 13:20 sda5 -> ../../../../pci0000:00/0000:00:1f.
 Secureboot for a generic UEFI x86 target works similar to the QEMU target,
 except the enrollment of the secure boot keys.
 
-### Generate keys from Debian snakeoil keys
+### Generate keys from a single signing key
 
-For testing purposes, the snakeoil keys from OVMF package can be used to
-convert the certificate into a efi authority file use the following commands:
+The recipe `single-key-to-efi-certs` can be used to generate a Debian package
+that contains the required EFI certificates for enabling secure boot. It uses
+a single key/cert pair as basis. Unless otherwise configured, this pair will
+be taken from the corresponding Debian snakeoil set which is fine only for
+testing purposes. The package will contain the `.auth` files required for
+manual deployment:
 
-```bash
-cert-to-efi-sig-list recipes-devtools/secure-boot-secrets/files/bookworm/PkKek-1-snakeoil.pem PK.esl
-sign-efi-sig-list -k recipes-devtools/secure-boot-secrets/files/bookworm/PkKek-1-snakeoil.key -c recipes-devtools/secure-boot-secrets/files/bookworm/PkKek-1-snakeoil.pem PK PK.esl PK.auth
+```
+$ dpkg -c build/tmp/deploy/isar-apt/cip-core-trixie/apt/cip-core-trixie/pool/main/s/single-key-to-efi-certs/single-key-to-efi-certs_0.1_arm64.deb
+[...]
+-rw-r--r-- root/root      2549 1970-01-01 02:00 ./usr/share/secure-boot-efi-certs/KEK.auth
+-rw-r--r-- root/root      2549 1970-01-01 02:00 ./usr/share/secure-boot-efi-certs/PK.auth
+-rw-r--r-- root/root      2549 1970-01-01 02:00 ./usr/share/secure-boot-efi-certs/db.auth
 ```
 
-The package `efitools` needs to be installed for this.
+### Automatic secure boot certificate enrollment
 
-In this case, the PK.esl can be used as DB and KEK keys. The PK.auth file is for PK key.
+By default, isar-cip-core images contain an early boot service
+(initramfs-sbcerts-hook) which will deploy the required EFI certificates during
+first boot and restart the machine into secure boot afterwards. This will only
+happen when the machine is in Setup Mode and no other certificates have been
+deployed to the Allowed Signature Database yet. This also ensures that disk
+encryption on first boot will only take place when the machine was securely
+booted so that the encryption key is sealed against this state in the TPM.
 
-### Secure boot key enrollment
+The certificates needed for this auto-enrollment are taken from a package that
+provides `secure-boot-efi-certs`. The `single-key-to-efi-certs` package is the
+default provider of this in isar-cip-core.
+
+### Manual secure boot certificate enrollment
 
 > :exclamation:**IMPORTANT** This document is not for generating a Machine Owner Key(MOK).
 
 > :exclamation:**IMPORTANT** Enrollment of secure boot keys must occur
 > in a secure environment.
 
-The following keys need to be enrolled onto the device:
+The certificates for the following keys need to be enrolled onto the device:
  - The Platform Key (PK)
  - The Key Exchange Key (KEK)
  - Allowed Signatures Database
 
+You can obtain them from the single-key-to-efi-certs package described before.
+
 The enrollment can typically be achieved with the help of
 [efi-updatevar](https://manpages.debian.org/bookworm/efitools/efi-updatevar.1.en.html)
 on the device.
-- 
2.47.3