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

On 12.08.26 11:25, Heinisch, Alexander (FT RPD CED SES-AT) wrote:
> On Tue, 2026-08-11 at 09:37 +0200, Jan Kiszka wrote:
>> 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...
> 
> How to proceed with this patch set?
> 
> Currently, FDE + factory-reset is broken => shouldn't be included in
> Kconfig and should be documented until fixed.
> 

...and I would like it to be fixed. At least factory-resetting without
TPM clearing should work, and then we could use that path for now. And
we would also fix the currently borken combination of data-encryption +
factory-reset + TPM-reset-off.

Jan

-- 
Siemens AG, Foundational Technologies
Linux Expert Center