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

On 11.08.26 08:58, Heinisch, Alexander (FT RPD CED SES-AT) wrote:
> On Mon, 2026-08-10 at 15:06 +0200, Jan Kiszka wrote:
>> 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.
> Yes, but without TPM reset current disk wiping strategy is to weak.
> 

One of the limitations of the current approach. Let's fix it so that
TPM-wiping-off will not cause too many surprises.

>> 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?
>>
> 
> Is it a reset so one can hand off the device to someone else? Is it a
> reset so same customer can start over again cleanly? Or is it a
> decommissioning without device reuse?
> 
> Currently, the key exposure is not limited to the initramfs hook
> implementing the crypt setup. So depending on the system, users may
> retrieve the keys of their system. If such device is recycled and
> potentially shipped to another customer, either a key exchange for the
> disk encryption is needed or the key stored in TPM must be sealed so it
> cannot be used after the crypt setup.
> 
> Not sure about the actual requirements that led to the factory-reset
> implementation. If keeping TPM keys for disk-encryption is ok, a clean
> wipe of the contents would simplify things.
> Do we even want to support FDE use cases for factory-reset? systemd
> (which served as a blueprint for the API afaik) does not.
> 

All valid questions...

Jan

-- 
Siemens AG, Foundational Technologies
Linux Expert Center