Re: [PATCH 2/2] tpm: add backend for mssim

[Stefan Berger <stefanb@linux.ibm.com>]

On 1/9/23 14:01, Stefan Berger wrote:
> 
> 
> On 1/9/23 13:51, James Bottomley wrote:
>> On Mon, 2023-01-09 at 13:34 -0500, Stefan Berger wrote:
>>> 
>>> 
>>> On 1/9/23 12:55, James Bottomley wrote:
>>>> On Mon, 2023-01-09 at 17:52 +0000, Dr. David Alan Gilbert 
>>>> wrote:
>>>>> * James Bottomley (jejb@linux.ibm.com) wrote:
>>>> [...]
>>>>>> external MSSIM TPM emulator has to be kept running to 
>>>>>> preserve the state.  If you restart it, the migration will 
>>>>>> fail.
>>>>> 
>>>>> Document that and we're getting there.
>>>> 
>>>> 
>>>> The documentation in the current patch series says
>>>> 
>>>> ---- The mssim backend supports snapshotting and migration,
>>>> but the state of the Microsoft Simulator server must be
>>>> preserved (or the server kept running) outside of QEMU for
>>>> restore to be successful. ----
>>>> 
>>>> What, beyond this would you want to see?
>>> 
>>> mssim today lacks the functionality of marshalling and 
>>> unmarshalling the permanent and volatile state of the TPM 2, 
>>> which are both needed for snapshot support. How does this work 
>>> with mssim?
>> 
>> You preserve the state by keeping the simulator running as the 
>> above says.  As long as you can preserve the state, there's no 
>> maximum time between snapshots.  There's no need of 
>> marshal/unmarshal if you do this
> 
> From 
> https://lists.gnu.org/archive/html/qemu-devel/2022-12/msg03146.html
> 
> "VM snapshotting is basically VM suspend / resume on steroids 
> requiring permanent and volatile state to be saved and restoreable 
> from possible very different points in time with possibly different 
> seeds, NVRAM locations etc. How the mssim protocol does this is 
> non-obvious to me and how one coordinates the restoring and saving
> of the TPM's state without direct coordination by QEMU is also 
> non-obvious."

One thing, though: I am aware of the issues that may arise due to
support for TPM state migration. However, whether TPM state migration becomes an issue
depends on how you use the TPM 2.

If the use case is to use the TPM 2 as a local crypto device then state migration
is  likely not an issue. You may have different keys in the TPM 2 at
different points in time and even snapshotting may not be an issue but possibly
quite a welcome feature to have along with support of scenarios of VM suspend + host
upgrade + host reboot + VM resume.

If you use TPM 2 for attestation then certain TPM 2 state migration scenarios
may become problematic. One could construct a scenario where attestation preceeds
some action that requires trust to have been established in the system in the
preceeding attestation step and support for snapshotting the state of the TPM 2
could become an issue if I was to wait for the attestation to have been concluded
and then I quickly restart a different snapshot that is not trustworthy and the client
proceeds thinking that the system is trustworthy (maybe a few SYNs from the client
went into the void)

Eliminating TPM 2 state migration is probably not a good idea, because  environments
where attestation may occur may also support VM suspend/resume along  with upgrading
a host and rebooting the host or VM migration for some sort of host evacuation
before upgrade.


When it comes to snapshotting and using the TPM 2 as a crypto device just saying that
VM snapshot is supported by leaving the TPM 2 running and not touching it doesn't make
this function correctly for all scenarios where the TPM 2 may have had different keys
loaded. It is even a worse idea for attestation where I could construct a snapshot A
and wait until the attestation has passed and then resume with a snapshot A' that runs
untrustworty software but uses the state of the TPM 2 from snapshot A times and remains
happy to quote the state of the PCRs from before. If launching a snapshot also restores
the state of the PCRs that goes along with the state of the system at that time then
that at least allows for quotes to have valid contents of PCRs that reflects the
system state at snapshot A'.

Kexec also comes to mind in this context where I could quickly start a new system
post attestation. So physical system could possibly be used for fooling clients as well.

A solution for how to resolve this may involve some sort of protocol and a  connection
that may not be broken *while* the system needs to be in a trusted state. The protocol
would have to help detection of substantial changes of state such as resume of some
snapshot or kexec into a system. Repeated attestation (with correctly restored TPM 2 state)
  may also help resolve the issue.

Cheers!
   Stefan




> 
> 
> Stefan .
>> 
>> James
>>

>