Re: [isar-cip-core][PATCH 0/2] Remove unsupported combinations for factory-reset from Kconfig and document them explicitly

On 10.08.26 14:02, Heinisch, Alexander (FT RPD CED SES-AT) wrote:
> On Mon, 2026-08-10 at 12:39 +0200, Jan Kiszka wrote:
>> On 10.08.26 08:55, Quirin Gylstorff wrote:
>>>
>>>
>>> On 8/7/26 5:44 PM, [email protected] wrote:
>>>> From: Alexander Heinisch <[email protected]>
>>>>
>>>> By default factory reset clears the tpm. Therefore, keys needed
>>>> to
>>>> decrypt the immutable A/B rootfs in full disk encryption setups
>>>> cannot be retrieved anymore. Thus, the boot fails and the device
>>>> cannot be recovered.
>>>>
>>>> This patch series removes such combination from the kconfig and
>>>> documents
>>>> the issue explicitly.
>>>
>>> This was never in scope of the factory reset. You could implement
> 
> Probably, but it was part of the configuration options. Imo, those
> shall serve as a demo for isar-cip-core functionality, and only include
> valid/supported scenarios.
> 
>>> it by
>>> moving the keys into the boot partition. But this move will create
>>> another can of worms.
> 
> Temporarily moving the keys to boot partition, is not an option.
> How are they secured there?
> 
> A reencrypt with new keys stored in TPM after TPM clearing of the
> partitions holding the rootfs after they got unsealed could be an
> option. But yes, that implies major rework of the factory-reset
> workflow in initramfs and potentially has side effects / dependencies
> on crypt hook local-top. And yes, there may be a small chance to brick
> the device when the device powercycles at the wrong time.
> Else, a more graceful removal of keys from TPM could also be an option.
> 
> All things, we need to think about in much more detail, also
> considering the number of use cases for a true factory reset support
> with full disk encryption in place.
> 
>>>
>>
>> We already have an option to skip TPM reset if not desired or
>> problematic. Why not use that, or build smarter on top of it?
> 
> Yes, there is an option to bypass TPM clearing. That's also documented.
> 
> The patchset is only about to document that the default factory-reset
> config does not support full disk encryption setups and not to offer a
> demo config option for this non-supported case.
> 
>>
>> Factory reset has already way too many limitations. I would rather
>> likto
>> work in more cases than in less.
> 
> Without major rework, the only option is to disable TPM-clearing for
> factory-reset in FDE setups, but that hides the fact, that it is no
> complete factory reset. So either Kconfig shall be explicit about that,
> or not offer the option for FDE + factory-reset at all (what I did).
> 

Resetting the TPM is the poor-man's approach to factory reset anyway. It
is not needed to reset the disk encryption keys, also for the data
partition, and we are so far too lazy to identify and delete other
resources in the TPM in a more targeted manner. Or was there anything
technically preventing an "all-objects-except-for" TPM reset?

Jan

-- 
Siemens AG, Foundational Technologies
Linux Expert Center