[isar-cip-core][PATCH] encrypt_partition: evict stale systemd SRK handle before enrollment

[isar-cip-core][PATCH] encrypt_partition: evict stale systemd SRK handle before enrollment

[Sari, Sercan]

systemd-cryptenroll persists its TPM2 SRK at handle 0x81000001
evict any stale handle before enrollment to avoid
"Failed to seal to TPM2: State not recoverable".

Signed-off-by: Sercan Sari <sari.sercan@siemens.com>
---
 .../files/encrypt_partition.systemd.script                   | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/recipes-initramfs/initramfs-crypt-hook/files/encrypt_partition.systemd.script b/recipes-initramfs/initramfs-crypt-hook/files/encrypt_partition.systemd.script
index 1b7c83b..841219c 100644
--- a/recipes-initramfs/initramfs-crypt-hook/files/encrypt_partition.systemd.script
+++ b/recipes-initramfs/initramfs-crypt-hook/files/encrypt_partition.systemd.script
@@ -26,6 +26,11 @@ enroll_tpm2_token() {
 	#tpm_key_algorithm="$4"
 	#pcr_bank_hash_type="$5"
 
+	# systemd-cryptenroll persists its TPM2 SRK at handle 0x81000001
+	# evict any stale handle before enrollment to avoid
+	# "Failed to seal to TPM2: State not recoverable".
+	tpm2_evictcontrol -C o -c 0x81000001 2>/dev/null || true
+
 	# check systemd version and export password if necessary
 	if [ -x /usr/bin/systemd-cryptenroll ]; then
 		systemd_version=$(systemd-cryptenroll --version | \
-- 
2.25.1

Re: [isar-cip-core][PATCH] encrypt_partition: evict stale systemd SRK handle before enrollment

[Jan Kiszka]

On 06.04.26 15:39, Sari, Sercan wrote:
> systemd-cryptenroll persists its TPM2 SRK at handle 0x81000001

Is that handle number officially documented? Or was it retrieved from
the code?

> evict any stale handle before enrollment to avoid
> "Failed to seal to TPM2: State not recoverable".
> 
> Signed-off-by: Sercan Sari <sari.sercan@siemens.com>
> ---
>  .../files/encrypt_partition.systemd.script                   | 5 +++++
>  1 file changed, 5 insertions(+)
> 
> diff --git a/recipes-initramfs/initramfs-crypt-hook/files/encrypt_partition.systemd.script b/recipes-initramfs/initramfs-crypt-hook/files/encrypt_partition.systemd.script
> index 1b7c83b..841219c 100644
> --- a/recipes-initramfs/initramfs-crypt-hook/files/encrypt_partition.systemd.script
> +++ b/recipes-initramfs/initramfs-crypt-hook/files/encrypt_partition.systemd.script
> @@ -26,6 +26,11 @@ enroll_tpm2_token() {
>  	#tpm_key_algorithm="$4"
>  	#pcr_bank_hash_type="$5"
>  
> +	# systemd-cryptenroll persists its TPM2 SRK at handle 0x81000001
> +	# evict any stale handle before enrollment to avoid
> +	# "Failed to seal to TPM2: State not recoverable".
> +	tpm2_evictcontrol -C o -c 0x81000001 2>/dev/null || true

"|| true" is always a bit fragile and bad for debugging. Can't we test
for the handle first and actually fail if eviction is then not successful?

> +
>  	# check systemd version and export password if necessary
>  	if [ -x /usr/bin/systemd-cryptenroll ]; then
>  		systemd_version=$(systemd-cryptenroll --version | \

Jan

-- 
Siemens AG, Foundational Technologies
Linux Expert Center

Re: [isar-cip-core][PATCH] encrypt_partition: evict stale systemd SRK handle before enrollment

[Quirin Gylstorff]

On 4/16/26 4:30 PM, Jan Kiszka wrote:
> On 06.04.26 15:39, Sari, Sercan wrote:
>> systemd-cryptenroll persists its TPM2 SRK at handle 0x81000001
> 
> Is that handle number officially documented? Or was it retrieved from
> the code?
> 
>> evict any stale handle before enrollment to avoid
>> "Failed to seal to TPM2: State not recoverable".

Could you also write when this error occurs.

Quirin

>>
>> Signed-off-by: Sercan Sari <sari.sercan@siemens.com>
>> ---
>>   .../files/encrypt_partition.systemd.script                   | 5 +++++
>>   1 file changed, 5 insertions(+)
>>
>> diff --git a/recipes-initramfs/initramfs-crypt-hook/files/encrypt_partition.systemd.script b/recipes-initramfs/initramfs-crypt-hook/files/encrypt_partition.systemd.script
>> index 1b7c83b..841219c 100644
>> --- a/recipes-initramfs/initramfs-crypt-hook/files/encrypt_partition.systemd.script
>> +++ b/recipes-initramfs/initramfs-crypt-hook/files/encrypt_partition.systemd.script
>> @@ -26,6 +26,11 @@ enroll_tpm2_token() {
>>   	#tpm_key_algorithm="$4"
>>   	#pcr_bank_hash_type="$5"
>>   
>> +	# systemd-cryptenroll persists its TPM2 SRK at handle 0x81000001
>> +	# evict any stale handle before enrollment to avoid
>> +	# "Failed to seal to TPM2: State not recoverable".
>> +	tpm2_evictcontrol -C o -c 0x81000001 2>/dev/null || true
> 
> "|| true" is always a bit fragile and bad for debugging. Can't we test
> for the handle first and actually fail if eviction is then not successful?
> 
>> +
>>   	# check systemd version and export password if necessary
>>   	if [ -x /usr/bin/systemd-cryptenroll ]; then
>>   		systemd_version=$(systemd-cryptenroll --version | \
> 
> Jan
> 

Re: [isar-cip-core][PATCH] encrypt_partition: evict stale systemd SRK handle before enrollment

[Jan Kiszka]

On 16.04.26 16:56, Quirin Gylstorff wrote:
> 
> 
> On 4/16/26 4:30 PM, Jan Kiszka wrote:
>> On 06.04.26 15:39, Sari, Sercan wrote:
>>> systemd-cryptenroll persists its TPM2 SRK at handle 0x81000001
>>
>> Is that handle number officially documented? Or was it retrieved from
>> the code?
>>
>>> evict any stale handle before enrollment to avoid
>>> "Failed to seal to TPM2: State not recoverable".
> 
> Could you also write when this error occurs.
> 

But then we would parse an error string and re-run the cryptenroll -
does not sound very appealing this way.

Jan

-- 
Siemens AG, Foundational Technologies
Linux Expert Center

Re: [isar-cip-core][PATCH] encrypt_partition: evict stale systemd SRK handle before enrollment

[sari.sercan]

[-- Attachment #1: Type: text/plain, Size: 1575 bytes --]

On Thu, Apr 16, 2026 at 05:30 PM, Jan Kiszka wrote:

> 
> On 06.04.26 15:39, Sari, Sercan wrote:
> 
>> systemd-cryptenroll persists its TPM2 SRK at handle 0x81000001
> 
> Is that handle number officially documented? Or was it retrieved from
> the code?

Yes, officially documented in man page.

> 
> 
>> evict any stale handle before enrollment to avoid
>> "Failed to seal to TPM2: State not recoverable".
>> 
>> Signed-off-by: Sercan Sari <sari.sercan@...>
>> ---
>> .../files/encrypt_partition.systemd.script | 5 +++++
>> 1 file changed, 5 insertions(+)
>> 
>> diff --git
>> a/recipes-initramfs/initramfs-crypt-hook/files/encrypt_partition.systemd.script
>> b/recipes-initramfs/initramfs-crypt-hook/files/encrypt_partition.systemd.script
>> 
>> index 1b7c83b..841219c 100644
>> ---
>> a/recipes-initramfs/initramfs-crypt-hook/files/encrypt_partition.systemd.script
>> 
>> +++
>> b/recipes-initramfs/initramfs-crypt-hook/files/encrypt_partition.systemd.script
>> 
>> @@ -26,6 +26,11 @@ enroll_tpm2_token() {
>> #tpm_key_algorithm="$4"
>> #pcr_bank_hash_type="$5"
>> 
>> + # systemd-cryptenroll persists its TPM2 SRK at handle 0x81000001
>> + # evict any stale handle before enrollment to avoid
>> + # "Failed to seal to TPM2: State not recoverable".
>> + tpm2_evictcontrol -C o -c 0x81000001 2>/dev/null || true
> 
> "|| true" is always a bit fragile and bad for debugging. Can't we test
> for the handle first and actually fail if eviction is then not successful?

Agreed, better to look at with tpm2_getcap first, then evict.

[-- Attachment #2: Type: text/html, Size: 1676 bytes --]

Re: [isar-cip-core][PATCH] encrypt_partition: evict stale systemd SRK handle before enrollment

[sari.sercan]

[-- Attachment #1: Type: text/plain, Size: 741 bytes --]

On Thu, Apr 16, 2026 at 07:03 PM, Jan Kiszka wrote:

> 
> On 16.04.26 16:56, Quirin Gylstorff wrote:
> 
>> 
>>> 
>>>> evict any stale handle before enrollment to avoid
>>>> "Failed to seal to TPM2: State not recoverable".
>>> 
>>> 
>> 
>> Could you also write when this error occurs.
> 
> 

This occurs when systemd-cryptenroll tries to create a new primary key
at the same time the same handle is occupied. with trixie shipping systemd >= v255,
this issue is easy reproduce in consecutive installations.

> 
> But then we would parse an error string and re-run the cryptenroll -
> does not sound very appealing this way.

By checking tpm2_getcap before evicting we can overcome this. I'll send a new version of it.

[-- Attachment #2: Type: text/html, Size: 907 bytes --]