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

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.

> 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.


BR Alexander

> Jan

-- 
Alexander Heinisch
Siemens AG
www.siemens.com