UC20 - Recovery ReInstall mode and TPM

device
#1

Hi,

I wanted to discuss the way the ReInstall Recovery Mode currently works.

It seems like the current status is, if you want to trigger a ReInstall [ which for all intents and purposes is equivalent to a “Factory Reset” ], and you are running in Secured mode [ SB and FDE ], you are responsible to also clearing the TPM.

I have a couple of questions and points on this.

If you are running a Secured Image, and you trigger a ReInstall, it would never work without clearing the TPM. In which case, would it not be reasonable for snapd to do the TPM clearing just before reboot ?

I understand that some platform may behave slightly differently, and even require some user input on the console when you request a TPM clear, but may don’t and it could even be an optional arg to make the clear request when asking snapd to ReInstall.

For our use cases we have tested requesting a TPM clearance [ via mgmt root login ], then triggering a ReInstall, it works.

Perhaps getting snapd to request a clear was considered a security concern. If so, can you expand on that ?

We have our own system agent that talks to snapd. We can try and orchestrate the TPM clearing in or agent instead of snapd. However, looking at the current snap interface definition for TPM, it seems like it does not give access to /sys/class/tpm/tpm0/ppi/request , which is how we have been clearing the TPM. Am I missing something here ? Can we request a reset via /dev/tpm instead somehow ?

Thanks !

Cheers,
Just

#2

As far as I know, no, the PPI should be used.

The main reasons we haven’t implemented triggering the TPM reset in the first iteration are:

  • depending on the device it might require user intervention
  • doing it early from the running system before a reboot means that one might end without access to the old run system but possibly also failing to boot into the recovery for the re-install
  • doing it after having rebooted into the re-install recovery system might imply an extra reboot

The best course of action might be device/application dependent. We understand though that the current situation is not ideal. We can work or are working on various things that can help with this:

  • We could add an option to both the API and “snap reboot” to explicitly ask for an early reset.
  • We are considering turning the TPM interface superprivileged, mostly to help avoid bad interactions with the FDE functionality. But with that we could give PPI access to it.
  • We are working on supporting a set of device installation hooks in the gadget; for some devices those could be a place from which to drive TPM reset and necessary reboots.
  • We will add separately from from-scratch re-install also factory reset which in many usage scenarios will not require a TPM reset.
#3

Thanks for taking the to respond with some detail @pedronis :+1:

Our main use case is for operational folk to be able trigger a “factory reset” in the field if deemed necessary. Ideally, that would be remotely [ via a framework and agent we have ]. Someone clicks on a button in a management GUI somewhere and the device does the factory reset. But we would also like to be able to do it via the keyboard and pressing 1 on boot etc, if the device was degraded in some way.

It sounds like from everything you laid out above, this is our best option for the long term.

What does seem to be problem for us right now though is, if we can’t access /sys/class/tpm/tpm0/ppi/request from a snap and implement the reset ourselves in the meantime, we are a bit stuck.

Is there any point in me requesting adding /sys/class/tpm/tpm0/ppi/request to the interface in the interim ? I presume not ?
Also, I will mention this to our Canonical account guys, but how best to vote for this in the meantime via the community ?

Cheers,
Just

#4

you could use system-files for that access as an interim measure

#5

Good call - that is a reasonable compromise I think.

Cheers,
Just