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

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.

BR Alexander

> 
> Jan

-- 
Alexander Heinisch
Siemens AG
www.siemens.com