Re: [Qemu-devel] [PATCH v4 1/2] tpm: extend TPM emulator with state migration support

[Marc-André Lureau]

Hi

On Thu, Mar 1, 2018 at 8:59 PM, Stefan Berger
 wrote:
> Extend the TPM emulator backend device with state migration support.
>
> The external TPM emulator 'swtpm' provides a protocol over
> its control channel to retrieve its state blobs. We implement
> functions for getting and setting the different state blobs.
> In case the setting of the state blobs fails, we return a
> negative errno code to fail the start of the VM.
>
> Since we have an external TPM emulator, we need to make sure
> that we do not migrate the state for as long as it is busy
> processing a request. We need to wait for notification that
> the request has completed processing.
>
> Signed-off-by: Stefan Berger 
> ---

With this squashed:
Reviewed-by: Marc-André Lureau 



diff --git a/hw/tpm/tpm_emulator.c b/hw/tpm/tpm_emulator.c
index 6d6158deea..ec9c25989b 100644
--- a/hw/tpm/tpm_emulator.c
+++ b/hw/tpm/tpm_emulator.c
@@ -894,6 +894,7 @@ static void tpm_emulator_shutdown(TPMEmulator *tpm_emu)
 static void tpm_emulator_inst_finalize(Object *obj)
 {
 TPMEmulator *tpm_emu = TPM_EMULATOR(obj);
+TPMBlobBuffers *state_blobs = _emu->state_blobs;

 tpm_emulator_shutdown(tpm_emu);

@@ -908,6 +909,10 @@ static void tpm_emulator_inst_finalize(Object *obj)
 error_free(tpm_emu->migration_blocker);
 }

+tpm_sized_buffer_reset(_blobs->volatil);
+tpm_sized_buffer_reset(_blobs->permanent);
+tpm_sized_buffer_reset(_blobs->savestate);
+
 qemu_mutex_destroy(_emu->mutex);

 vmstate_unregister(NULL, _tpm_emulator, obj);


>  hw/tpm/tpm_emulator.c | 312 
> --
>  1 file changed, 302 insertions(+), 10 deletions(-)
>
> diff --git a/hw/tpm/tpm_emulator.c b/hw/tpm/tpm_emulator.c
> index b787aee..da877e5 100644
> --- a/hw/tpm/tpm_emulator.c
> +++ b/hw/tpm/tpm_emulator.c
> @@ -55,6 +55,19 @@
>  #define TPM_EMULATOR_IMPLEMENTS_ALL_CAPS(S, cap) (((S)->caps & (cap)) == 
> (cap))
>
>  /* data structures */
> +
> +/* blobs from the TPM; part of VM state when migrating */
> +typedef struct TPMBlobBuffers {
> +uint32_t permanent_flags;
> +TPMSizedBuffer permanent;
> +
> +uint32_t volatil_flags;
> +TPMSizedBuffer volatil;
> +
> +uint32_t savestate_flags;
> +TPMSizedBuffer savestate;
> +} TPMBlobBuffers;
> +
>  typedef struct TPMEmulator {
>  TPMBackend parent;
>
> @@ -70,6 +83,8 @@ typedef struct TPMEmulator {
>
>  unsigned int established_flag:1;
>  unsigned int established_flag_cached:1;
> +
> +TPMBlobBuffers state_blobs;
>  } TPMEmulator;
>
>
> @@ -301,7 +316,8 @@ static int tpm_emulator_set_buffer_size(TPMBackend *tb,
>  return 0;
>  }
>
> -static int tpm_emulator_startup_tpm(TPMBackend *tb, size_t buffersize)
> +static int _tpm_emulator_startup_tpm(TPMBackend *tb, size_t buffersize,
> + bool is_resume)
>  {
>  TPMEmulator *tpm_emu = TPM_EMULATOR(tb);
>  ptm_init init = {
> @@ -309,12 +325,17 @@ static int tpm_emulator_startup_tpm(TPMBackend *tb, 
> size_t buffersize)
>  };
>  ptm_res res;
>
> +DPRINTF("%s   is_resume: %d", __func__, is_resume);
> +
>  if (buffersize != 0 &&
>  tpm_emulator_set_buffer_size(tb, buffersize, NULL) < 0) {
>  goto err_exit;
>  }
>
> -DPRINTF("%s", __func__);
> +if (is_resume) {
> +init.u.req.init_flags = cpu_to_be32(PTM_INIT_FLAG_DELETE_VOLATILE);
> +}
> +
>  if (tpm_emulator_ctrlcmd(tpm_emu, CMD_INIT, , sizeof(init),
>   sizeof(init)) < 0) {
>  error_report("tpm-emulator: could not send INIT: %s",
> @@ -333,6 +354,11 @@ err_exit:
>  return -1;
>  }
>
> +static int tpm_emulator_startup_tpm(TPMBackend *tb, size_t buffersize)
> +{
> +return _tpm_emulator_startup_tpm(tb, buffersize, false);
> +}
> +
>  static bool tpm_emulator_get_tpm_established_flag(TPMBackend *tb)
>  {
>  TPMEmulator *tpm_emu = TPM_EMULATOR(tb);
> @@ -431,16 +457,21 @@ static size_t tpm_emulator_get_buffer_size(TPMBackend 
> *tb)
>  static int tpm_emulator_block_migration(TPMEmulator *tpm_emu)
>  {
>  Error *err = NULL;
> +ptm_cap caps = PTM_CAP_GET_STATEBLOB | PTM_CAP_SET_STATEBLOB |
> +   PTM_CAP_STOP;
>
> -error_setg(_emu->migration_blocker,
> -   "Migration disabled: TPM emulator not yet migratable");
> -migrate_add_blocker(tpm_emu->migration_blocker, );
> -if (err) {
> -error_report_err(err);
> -error_free(tpm_emu->migration_blocker);
> -tpm_emu->migration_blocker = NULL;
> +if (!TPM_EMULATOR_IMPLEMENTS_ALL_CAPS(tpm_emu, caps)) {
> +error_setg(_emu->migration_blocker,
> +   "Migration disabled: TPM emulator does not support "
> +   "migration");
> +migrate_add_blocker(tpm_emu->migration_blocker, );
> +if (err) {
> +error_report_err(err);
> +

Re: [Qemu-devel] [PATCH v4 1/2] tpm: extend TPM emulator with state migration support

[Stefan Berger]

On 03/02/2018 04:26 AM, Marc-André Lureau wrote:



+return 0;
+}
+
+static const VMStateDescription vmstate_tpm_emulator = {
+.name = "tpm-emulator",
+.version_id = 1,
+.minimum_version_id = 0,

version_id = 1 & minimum_version_id = 0 ?

It's the first version, let's have version_id = 0 (and you could
remove minimum_version).


It doesn't work...  I cannot use version_id 0 in tpm_tis or in 
tpm_emulator. For tpm_tis I get the error 'Missing section footer' upon 
VM resume and for some weird reason it doesn't allocate the blob buffers 
when reading them in tpm_emulator. I get a NULL pointer instead. So, we 
are better off with version_id 1 here... The CRB seems to work as is.


   Stefan

Re: [Qemu-devel] [PATCH v4 1/2] tpm: extend TPM emulator with state migration support

[Stefan Berger]

On 03/05/2018 07:43 AM, Dr. David Alan Gilbert wrote:

* Stefan Berger (stef...@linux.vnet.ibm.com) wrote:

On 03/02/2018 05:14 AM, Dr. David Alan Gilbert wrote:

hw/tpm/tpm_emulator.c:909:tpm_emulator_class_init: Object 0x55f4cbc72680 is
not an instance of type device
Aborted

Can we leave it as it is ?

Oh, not a device, hmmm that's odd; yeh probably best then.


At least it doesn't *need* to be a device that an OS could talk to via 
MMIO or so. That's the TIS or CRB hardware interfaces in this case. If 
we have to convert this 'backend' to a device for some reason, I'd do 
it, but rather leave it as it is if not.


   Stefan

Re: [Qemu-devel] [PATCH v4 1/2] tpm: extend TPM emulator with state migration support

[Dr. David Alan Gilbert]

* Stefan Berger (stef...@linux.vnet.ibm.com) wrote:
> On 03/02/2018 05:14 AM, Dr. David Alan Gilbert wrote:
> > * Marc-André Lureau (marcandre.lur...@gmail.com) wrote:
> > > Hi Stefan
> > > 
> > > On Thu, Mar 1, 2018 at 8:59 PM, Stefan Berger
> > >  wrote:
> > > > Extend the TPM emulator backend device with state migration support.
> > > > 
> > > > The external TPM emulator 'swtpm' provides a protocol over
> > > > its control channel to retrieve its state blobs. We implement
> > > > functions for getting and setting the different state blobs.
> > > > In case the setting of the state blobs fails, we return a
> > > > negative errno code to fail the start of the VM.
> > > > 
> > > > Since we have an external TPM emulator, we need to make sure
> > > > that we do not migrate the state for as long as it is busy
> > > > processing a request. We need to wait for notification that
> > > > the request has completed processing.
> > > Because qemu will have to deal with an external state, managed by the
> > > tpm emulator (different from other storage/nvram):
> > > 
> > > - the emulator statedir must be different between source and dest? Can
> > > it be the same?
> > > - what is the story regarding versionning? Can you migrate from/to any
> > > version, or only the same version?
> > > - can the host source and destination be of different endianess?
> > > - how is suspend and snapshot working?
> > > 
> > > There are probably other complications that I can't think of
> > > immediately, but David or Juan help may help avoid mistakes.
> > Yes, I think that just about covers it.
> > 
> > > It probably deserves a few explanations in docs/specs/tpm.txt.
> > > 
> > > > Signed-off-by: Stefan Berger 
> > > > ---
> > > >   hw/tpm/tpm_emulator.c | 312 
> > > > --
> > > It would be worth to add some basic tests. Either growing our own
> > > tests/tpm-emu.c test emulator
> > > 
> > > or checking that swtpm is present (and of required version?) to
> > > run/skip the test a more complete test.
> > > 
> > > >   1 file changed, 302 insertions(+), 10 deletions(-)
> > > > 
> > > > diff --git a/hw/tpm/tpm_emulator.c b/hw/tpm/tpm_emulator.c
> > > > index b787aee..da877e5 100644
> > > > --- a/hw/tpm/tpm_emulator.c
> > > > +++ b/hw/tpm/tpm_emulator.c
> > > > @@ -55,6 +55,19 @@
> > > >   #define TPM_EMULATOR_IMPLEMENTS_ALL_CAPS(S, cap) (((S)->caps & (cap)) 
> > > > == (cap))
> > > > 
> > > >   /* data structures */
> > > > +
> > > > +/* blobs from the TPM; part of VM state when migrating */
> > > > +typedef struct TPMBlobBuffers {
> > > > +uint32_t permanent_flags;
> > > > +TPMSizedBuffer permanent;
> > > > +
> > > > +uint32_t volatil_flags;
> > > > +TPMSizedBuffer volatil;
> > > > +
> > > > +uint32_t savestate_flags;
> > > > +TPMSizedBuffer savestate;
> > > > +} TPMBlobBuffers;
> > > > +
> > > >   typedef struct TPMEmulator {
> > > >   TPMBackend parent;
> > > > 
> > > > @@ -70,6 +83,8 @@ typedef struct TPMEmulator {
> > > > 
> > > >   unsigned int established_flag:1;
> > > >   unsigned int established_flag_cached:1;
> > > > +
> > > > +TPMBlobBuffers state_blobs;
> > > Suspicious addition, it shouldn't be necessary in running state. It
> > > could be allocated on demand? Even better if the field is removed, but
> > > this may not be possible with VMSTATE macros.
> > > 
> > > >   } TPMEmulator;
> > > > 
> > > > 
> > > > @@ -301,7 +316,8 @@ static int tpm_emulator_set_buffer_size(TPMBackend 
> > > > *tb,
> > > >   return 0;
> > > >   }
> > > > 
> > > > -static int tpm_emulator_startup_tpm(TPMBackend *tb, size_t buffersize)
> > > > +static int _tpm_emulator_startup_tpm(TPMBackend *tb, size_t buffersize,
> > > > + bool is_resume)
> > > Using underscore-prefixed names is discouraged. Call it tpm_emulator_init?
> > > 
> > > >   {
> > > >   TPMEmulator *tpm_emu = TPM_EMULATOR(tb);
> > > >   ptm_init init = {
> > > > @@ -309,12 +325,17 @@ static int tpm_emulator_startup_tpm(TPMBackend 
> > > > *tb, size_t buffersize)
> > > >   };
> > > >   ptm_res res;
> > > > 
> > > > +DPRINTF("%s   is_resume: %d", __func__, is_resume);
> > > > +
> > > extra spaces, you may also add buffersize while at it.
> > Also it would be good to use trace_'s where possible rather than
> > DPRINTFs.
> 
> Here's a branch where I am doing that now:
> 
> https://github.com/stefanberger/qemu-tpm/commits/tracing
> 
> I would leave a DEBUG_TIS in the tpm_tis.c, though.
> 
> > > That TPMSizedBuffer is not really useful. Use GArray or qemu Buffer ?
> > > (and we could drop TPMSizedBuffer).
> > Also, given this is an arbitrary sized chunk, this should probably use
> > g_try_malloc and check the result rather than letting g_malloc assert on
> > failure (especially true on the source side).
> 
> Will fix. Thanks.
> 
> 
> > 
> > > > +n = qemu_chr_fe_read_all(_emu->ctrl_chr, 

Re: [Qemu-devel] [PATCH v4 1/2] tpm: extend TPM emulator with state migration support

[Stefan Berger]

On 03/02/2018 05:14 AM, Dr. David Alan Gilbert wrote:

* Marc-André Lureau (marcandre.lur...@gmail.com) wrote:

Hi Stefan

On Thu, Mar 1, 2018 at 8:59 PM, Stefan Berger
 wrote:

Extend the TPM emulator backend device with state migration support.

The external TPM emulator 'swtpm' provides a protocol over
its control channel to retrieve its state blobs. We implement
functions for getting and setting the different state blobs.
In case the setting of the state blobs fails, we return a
negative errno code to fail the start of the VM.

Since we have an external TPM emulator, we need to make sure
that we do not migrate the state for as long as it is busy
processing a request. We need to wait for notification that
the request has completed processing.

Because qemu will have to deal with an external state, managed by the
tpm emulator (different from other storage/nvram):

- the emulator statedir must be different between source and dest? Can
it be the same?
- what is the story regarding versionning? Can you migrate from/to any
version, or only the same version?
- can the host source and destination be of different endianess?
- how is suspend and snapshot working?

There are probably other complications that I can't think of
immediately, but David or Juan help may help avoid mistakes.

Yes, I think that just about covers it.


It probably deserves a few explanations in docs/specs/tpm.txt.


Signed-off-by: Stefan Berger 
---
  hw/tpm/tpm_emulator.c | 312 --

It would be worth to add some basic tests. Either growing our own
tests/tpm-emu.c test emulator

or checking that swtpm is present (and of required version?) to
run/skip the test a more complete test.


  1 file changed, 302 insertions(+), 10 deletions(-)

diff --git a/hw/tpm/tpm_emulator.c b/hw/tpm/tpm_emulator.c
index b787aee..da877e5 100644
--- a/hw/tpm/tpm_emulator.c
+++ b/hw/tpm/tpm_emulator.c
@@ -55,6 +55,19 @@
  #define TPM_EMULATOR_IMPLEMENTS_ALL_CAPS(S, cap) (((S)->caps & (cap)) == 
(cap))

  /* data structures */
+
+/* blobs from the TPM; part of VM state when migrating */
+typedef struct TPMBlobBuffers {
+uint32_t permanent_flags;
+TPMSizedBuffer permanent;
+
+uint32_t volatil_flags;
+TPMSizedBuffer volatil;
+
+uint32_t savestate_flags;
+TPMSizedBuffer savestate;
+} TPMBlobBuffers;
+
  typedef struct TPMEmulator {
  TPMBackend parent;

@@ -70,6 +83,8 @@ typedef struct TPMEmulator {

  unsigned int established_flag:1;
  unsigned int established_flag_cached:1;
+
+TPMBlobBuffers state_blobs;

Suspicious addition, it shouldn't be necessary in running state. It
could be allocated on demand? Even better if the field is removed, but
this may not be possible with VMSTATE macros.


  } TPMEmulator;


@@ -301,7 +316,8 @@ static int tpm_emulator_set_buffer_size(TPMBackend *tb,
  return 0;
  }

-static int tpm_emulator_startup_tpm(TPMBackend *tb, size_t buffersize)
+static int _tpm_emulator_startup_tpm(TPMBackend *tb, size_t buffersize,
+ bool is_resume)

Using underscore-prefixed names is discouraged. Call it tpm_emulator_init?


  {
  TPMEmulator *tpm_emu = TPM_EMULATOR(tb);
  ptm_init init = {
@@ -309,12 +325,17 @@ static int tpm_emulator_startup_tpm(TPMBackend *tb, 
size_t buffersize)
  };
  ptm_res res;

+DPRINTF("%s   is_resume: %d", __func__, is_resume);
+

extra spaces, you may also add buffersize while at it.

Also it would be good to use trace_'s where possible rather than
DPRINTFs.


Here's a branch where I am doing that now:

https://github.com/stefanberger/qemu-tpm/commits/tracing

I would leave a DEBUG_TIS in the tpm_tis.c, though.


That TPMSizedBuffer is not really useful. Use GArray or qemu Buffer ?
(and we could drop TPMSizedBuffer).

Also, given this is an arbitrary sized chunk, this should probably use
g_try_malloc and check the result rather than letting g_malloc assert on
failure (especially true on the source side).


Will fix. Thanks.





+n = qemu_chr_fe_read_all(_emu->ctrl_chr, tsb->buffer, totlength);
+if (n != totlength) {
+error_report("tpm-emulator: Could not read stateblob (type %d) : %s",
+ type, strerror(errno));
+return -1;
+}
+tsb->size = totlength;
+
+DPRINTF("got state blob type %d, %d bytes, flags 0x%08x\n",
+type, tsb->size, *flags);
+
+return 0;
+}
+
+static int tpm_emulator_get_state_blobs(TPMEmulator *tpm_emu)
+{
+TPMBlobBuffers *state_blobs = _emu->state_blobs;
+
+if (tpm_emulator_get_state_blob(tpm_emu, PTM_BLOB_TYPE_PERMANENT,
+_blobs->permanent,
+_blobs->permanent_flags) < 0 ||
+tpm_emulator_get_state_blob(tpm_emu, PTM_BLOB_TYPE_VOLATILE,
+_blobs->volatil,
+_blobs->volatil_flags) < 0 

Re: [Qemu-devel] [PATCH v4 1/2] tpm: extend TPM emulator with state migration support

[Stefan Berger]

On 03/02/2018 04:26 AM, Marc-André Lureau wrote:

Hi Stefan

On Thu, Mar 1, 2018 at 8:59 PM, Stefan Berger
 wrote:

Extend the TPM emulator backend device with state migration support.

The external TPM emulator 'swtpm' provides a protocol over
its control channel to retrieve its state blobs. We implement
functions for getting and setting the different state blobs.
In case the setting of the state blobs fails, we return a
negative errno code to fail the start of the VM.

Since we have an external TPM emulator, we need to make sure
that we do not migrate the state for as long as it is busy
processing a request. We need to wait for notification that
the request has completed processing.

Because qemu will have to deal with an external state, managed by the
tpm emulator (different from other storage/nvram):

- the emulator statedir must be different between source and dest? Can
it be the same?
- what is the story regarding versionning? Can you migrate from/to any
version, or only the same version?
- can the host source and destination be of different endianess?
- how is suspend and snapshot working?

There are probably other complications that I can't think of
immediately, but David or Juan help may help avoid mistakes.

It probably deserves a few explanations in docs/specs/tpm.txt.


Signed-off-by: Stefan Berger 
---
  hw/tpm/tpm_emulator.c | 312 --

It would be worth to add some basic tests. Either growing our own
tests/tpm-emu.c test emulator

or checking that swtpm is present (and of required version?) to
run/skip the test a more complete test.


  1 file changed, 302 insertions(+), 10 deletions(-)

diff --git a/hw/tpm/tpm_emulator.c b/hw/tpm/tpm_emulator.c
index b787aee..da877e5 100644
--- a/hw/tpm/tpm_emulator.c
+++ b/hw/tpm/tpm_emulator.c
@@ -55,6 +55,19 @@
  #define TPM_EMULATOR_IMPLEMENTS_ALL_CAPS(S, cap) (((S)->caps & (cap)) == 
(cap))

  /* data structures */
+
+/* blobs from the TPM; part of VM state when migrating */
+typedef struct TPMBlobBuffers {
+uint32_t permanent_flags;
+TPMSizedBuffer permanent;
+
+uint32_t volatil_flags;
+TPMSizedBuffer volatil;
+
+uint32_t savestate_flags;
+TPMSizedBuffer savestate;
+} TPMBlobBuffers;
+
  typedef struct TPMEmulator {
  TPMBackend parent;

@@ -70,6 +83,8 @@ typedef struct TPMEmulator {

  unsigned int established_flag:1;
  unsigned int established_flag_cached:1;
+
+TPMBlobBuffers state_blobs;

Suspicious addition, it shouldn't be necessary in running state. It
could be allocated on demand? Even better if the field is removed, but
this may not be possible with VMSTATE macros.


I tried to use GArray *, but offsetof cannot be applied to it by the 
VMSTATE macros (non-constant address).


Now I am trying to use Buffer (util/buffer.c) but here we're missing 
VMSTATE macros. To support it, we would need a VMSTATE_SIZE_T() or so, 
truncating size_t to 32 bits(?). This would be for storing the size 
indicator 'size-t offset' of Buffer preceeding the actual buffer. Then 
of course the VMSTATE_VBUFFER_ALLOC_UINT32 will not work anymore with 
Buffer and we would need something like VMSTATE_QEMU_BUFFER_ALLOC().


Well, the TPMSizedBuffer fit the existing VMSTATE macros quite well and 
was simple. Another approach would be to implement SimpleSizedBuffer, 
which would basically be a renaming of TPMSizedBuffer with the existing 
few TPMSizeBuffer functions wrapping it. Or we go with the plain size_t 
length indicator and char *buffer without wrapping it in any structure - 
but ... is that better?


> +.pre_save = tpm_emulator_pre_save,
> +.post_load = tpm_emulator_post_load,
> +.fields = (VMStateField[]) {
> +VMSTATE_UINT32(state_blobs.permanent_flags, TPMEmulator),
> +VMSTATE_UINT32(state_blobs.permanent.size, TPMEmulator),
> + VMSTATE_VBUFFER_ALLOC_UINT32(state_blobs.permanent.buffer,
> + TPMEmulator, 1, 0,
> + state_blobs.permanent.size),
> +
> +VMSTATE_UINT32(state_blobs.volatil_flags, TPMEmulator),
> +VMSTATE_UINT32(state_blobs.volatil.size, TPMEmulator),
> + VMSTATE_VBUFFER_ALLOC_UINT32(state_blobs.volatil.buffer,
> + TPMEmulator, 1, 0,
> + state_blobs.volatil.size),
> +
> +VMSTATE_UINT32(state_blobs.savestate_flags, TPMEmulator),
> +VMSTATE_UINT32(state_blobs.savestate.size, TPMEmulator),
> + VMSTATE_VBUFFER_ALLOC_UINT32(state_blobs.savestate.buffer,
> + TPMEmulator, 1, 0,
> + state_blobs.savestate.size),
> +
> +VMSTATE_END_OF_LIST()
> +}
> +};
> +

   Stefan



  } TPMEmulator;


@@ -301,7 +316,8 @@ static int tpm_emulator_set_buffer_size(TPMBackend *tb,
  return 0;
  }

-static int tpm_emulator_startup_tpm(TPMBackend *tb, size_t buffersize)
+static int _tpm_emulator_startup_tpm(TPMBackend *tb, size_t buffersize,
+

Re: [Qemu-devel] [PATCH v4 1/2] tpm: extend TPM emulator with state migration support

[Stefan Berger]

On 03/02/2018 04:26 AM, Marc-André Lureau wrote:

Hi Stefan

On Thu, Mar 1, 2018 at 8:59 PM, Stefan Berger
 wrote:

Extend the TPM emulator backend device with state migration support.

The external TPM emulator 'swtpm' provides a protocol over
its control channel to retrieve its state blobs. We implement
functions for getting and setting the different state blobs.
In case the setting of the state blobs fails, we return a
negative errno code to fail the start of the VM.

Since we have an external TPM emulator, we need to make sure
that we do not migrate the state for as long as it is busy
processing a request. We need to wait for notification that
the request has completed processing.

Because qemu will have to deal with an external state, managed by the
tpm emulator (different from other storage/nvram):

- the emulator statedir must be different between source and dest? Can
it be the same?


You mean for local migration? I would suggest it be different 
directories though it may work with the same. I haven't tried it like 
that and the critical case here is local migration between different 
versions of the swtpm and for example downgrading of state from v3 to v1 
being refused.



- what is the story regarding versionning? Can you migrate from/to any
version, or only the same version?


I just redid the state marshalling/unmarshalling of the TPM 2 
implementation. All structures that are written out are ID'ed and 
versioned and accomodate compile-time optional parts. As for migration 
between different versions, I am not sure what to promise about this 
right now. So if you migrate a structure of the TPM 2 from v1 to v2 and 
v2 has some new fields that v1 didn't have, we need default values to 
assign to these new fields, which may or may not be possible depending 
on circumstances and semantics of the fields. In the end it comes down 
to upgradeability of the TPM 2 implementation. The current 
implementation supports revision 146 of the TPM 2 specs. I cannot 
predict the future and what future versions may add to the code and the 
state of the device. Design/development of the TPM 2 is ongoing while 
companies are producing TPM 2 chips following specs of a certain time. 
They also have that problem of having to upgrade a device to a later 
spec but could refuse to do so and tell you to buy a new machine. So in 
our case it may actually be more difficult with the expected upgrade 
path. If the state cannot be upgraded because default values cannot be 
found, we would have to stop at a certain revision.



- can the host source and destination be of different endianess?


Yes. All state is marshalled in big endian format. I have test cases in 
swtpm that cover that. State produced on a x86_64 can be consumed on 
ppc64 big endian.



- how is suspend and snapshot working?


The tpm_emulator backend uses the same mechanisms to store state as all 
the other devices do, except that we retrieve the state via .pre_save 
from an external device where we fill buffers that are part of the 
'normal' state of the device. You have come across the TPMSizedBuffers 
that are being marshalled and those carry that state.


I have tried local migration to a file as well as local migration via 
netcat. Both work.




There are probably other complications that I can't think of
immediately, but David or Juan help may help avoid mistakes.

It probably deserves a few explanations in docs/specs/tpm.txt.


Signed-off-by: Stefan Berger 
---
  hw/tpm/tpm_emulator.c | 312 --

It would be worth to add some basic tests. Either growing our own
tests/tpm-emu.c test emulator

or checking that swtpm is present (and of required version?) to
run/skip the test a more complete test.


Ok, I'll have to look into that. I do have several test cases in swtpm 
for that already.





  1 file changed, 302 insertions(+), 10 deletions(-)

diff --git a/hw/tpm/tpm_emulator.c b/hw/tpm/tpm_emulator.c
index b787aee..da877e5 100644
--- a/hw/tpm/tpm_emulator.c
+++ b/hw/tpm/tpm_emulator.c
@@ -55,6 +55,19 @@
  #define TPM_EMULATOR_IMPLEMENTS_ALL_CAPS(S, cap) (((S)->caps & (cap)) == 
(cap))

  /* data structures */
+
+/* blobs from the TPM; part of VM state when migrating */
+typedef struct TPMBlobBuffers {
+uint32_t permanent_flags;
+TPMSizedBuffer permanent;
+
+uint32_t volatil_flags;
+TPMSizedBuffer volatil;
+
+uint32_t savestate_flags;
+TPMSizedBuffer savestate;
+} TPMBlobBuffers;
+
  typedef struct TPMEmulator {
  TPMBackend parent;

@@ -70,6 +83,8 @@ typedef struct TPMEmulator {

  unsigned int established_flag:1;
  unsigned int established_flag_cached:1;
+
+TPMBlobBuffers state_blobs;

Suspicious addition, it shouldn't be necessary in running state. It
could be allocated on demand? Even better if the field is removed, but
this may not be possible with VMSTATE macros.


This is the field that will carry the 

Re: [Qemu-devel] [PATCH v4 1/2] tpm: extend TPM emulator with state migration support

[Dr. David Alan Gilbert]

* Marc-André Lureau (marcandre.lur...@gmail.com) wrote:
> Hi Stefan
> 
> On Thu, Mar 1, 2018 at 8:59 PM, Stefan Berger
>  wrote:
> > Extend the TPM emulator backend device with state migration support.
> >
> > The external TPM emulator 'swtpm' provides a protocol over
> > its control channel to retrieve its state blobs. We implement
> > functions for getting and setting the different state blobs.
> > In case the setting of the state blobs fails, we return a
> > negative errno code to fail the start of the VM.
> >
> > Since we have an external TPM emulator, we need to make sure
> > that we do not migrate the state for as long as it is busy
> > processing a request. We need to wait for notification that
> > the request has completed processing.
> 
> Because qemu will have to deal with an external state, managed by the
> tpm emulator (different from other storage/nvram):
> 
> - the emulator statedir must be different between source and dest? Can
> it be the same?
> - what is the story regarding versionning? Can you migrate from/to any
> version, or only the same version?
> - can the host source and destination be of different endianess?
> - how is suspend and snapshot working?
> 
> There are probably other complications that I can't think of
> immediately, but David or Juan help may help avoid mistakes.

Yes, I think that just about covers it.

> It probably deserves a few explanations in docs/specs/tpm.txt.
> 
> >
> > Signed-off-by: Stefan Berger 
> > ---
> >  hw/tpm/tpm_emulator.c | 312 
> > --
> 
> It would be worth to add some basic tests. Either growing our own
> tests/tpm-emu.c test emulator
> 
> or checking that swtpm is present (and of required version?) to
> run/skip the test a more complete test.
> 
> >  1 file changed, 302 insertions(+), 10 deletions(-)
> >
> > diff --git a/hw/tpm/tpm_emulator.c b/hw/tpm/tpm_emulator.c
> > index b787aee..da877e5 100644
> > --- a/hw/tpm/tpm_emulator.c
> > +++ b/hw/tpm/tpm_emulator.c
> > @@ -55,6 +55,19 @@
> >  #define TPM_EMULATOR_IMPLEMENTS_ALL_CAPS(S, cap) (((S)->caps & (cap)) == 
> > (cap))
> >
> >  /* data structures */
> > +
> > +/* blobs from the TPM; part of VM state when migrating */
> > +typedef struct TPMBlobBuffers {
> > +uint32_t permanent_flags;
> > +TPMSizedBuffer permanent;
> > +
> > +uint32_t volatil_flags;
> > +TPMSizedBuffer volatil;
> > +
> > +uint32_t savestate_flags;
> > +TPMSizedBuffer savestate;
> > +} TPMBlobBuffers;
> > +
> >  typedef struct TPMEmulator {
> >  TPMBackend parent;
> >
> > @@ -70,6 +83,8 @@ typedef struct TPMEmulator {
> >
> >  unsigned int established_flag:1;
> >  unsigned int established_flag_cached:1;
> > +
> > +TPMBlobBuffers state_blobs;
> 
> Suspicious addition, it shouldn't be necessary in running state. It
> could be allocated on demand? Even better if the field is removed, but
> this may not be possible with VMSTATE macros.
> 
> >  } TPMEmulator;
> >
> >
> > @@ -301,7 +316,8 @@ static int tpm_emulator_set_buffer_size(TPMBackend *tb,
> >  return 0;
> >  }
> >
> > -static int tpm_emulator_startup_tpm(TPMBackend *tb, size_t buffersize)
> > +static int _tpm_emulator_startup_tpm(TPMBackend *tb, size_t buffersize,
> > + bool is_resume)
> 
> Using underscore-prefixed names is discouraged. Call it tpm_emulator_init?
> 
> >  {
> >  TPMEmulator *tpm_emu = TPM_EMULATOR(tb);
> >  ptm_init init = {
> > @@ -309,12 +325,17 @@ static int tpm_emulator_startup_tpm(TPMBackend *tb, 
> > size_t buffersize)
> >  };
> >  ptm_res res;
> >
> > +DPRINTF("%s   is_resume: %d", __func__, is_resume);
> > +
>
> extra spaces, you may also add buffersize while at it.

Also it would be good to use trace_'s where possible rather than
DPRINTFs.

> 
> >  if (buffersize != 0 &&
> >  tpm_emulator_set_buffer_size(tb, buffersize, NULL) < 0) {
> >  goto err_exit;
> >  }
> >
> > -DPRINTF("%s", __func__);
> > +if (is_resume) {
> > +init.u.req.init_flags = cpu_to_be32(PTM_INIT_FLAG_DELETE_VOLATILE);
> > +}
> 
> Since it's a flags, and for future extensibility, I would suggest |=.
> 
> > +
> >  if (tpm_emulator_ctrlcmd(tpm_emu, CMD_INIT, , sizeof(init),
> >   sizeof(init)) < 0) {
> >  error_report("tpm-emulator: could not send INIT: %s",
> > @@ -333,6 +354,11 @@ err_exit:
> >  return -1;
> >  }
> >
> > +static int tpm_emulator_startup_tpm(TPMBackend *tb, size_t buffersize)
> > +{
> > +return _tpm_emulator_startup_tpm(tb, buffersize, false);
> > +}
> > +
> >  static bool tpm_emulator_get_tpm_established_flag(TPMBackend *tb)
> >  {
> >  TPMEmulator *tpm_emu = TPM_EMULATOR(tb);
> > @@ -431,16 +457,21 @@ static size_t tpm_emulator_get_buffer_size(TPMBackend 
> > *tb)
> >  static int tpm_emulator_block_migration(TPMEmulator *tpm_emu)
> >  {
> >  Error *err = NULL;
> > + 

Re: [Qemu-devel] [PATCH v4 1/2] tpm: extend TPM emulator with state migration support

[Marc-André Lureau]

Hi Stefan

On Thu, Mar 1, 2018 at 8:59 PM, Stefan Berger
 wrote:
> Extend the TPM emulator backend device with state migration support.
>
> The external TPM emulator 'swtpm' provides a protocol over
> its control channel to retrieve its state blobs. We implement
> functions for getting and setting the different state blobs.
> In case the setting of the state blobs fails, we return a
> negative errno code to fail the start of the VM.
>
> Since we have an external TPM emulator, we need to make sure
> that we do not migrate the state for as long as it is busy
> processing a request. We need to wait for notification that
> the request has completed processing.

Because qemu will have to deal with an external state, managed by the
tpm emulator (different from other storage/nvram):

- the emulator statedir must be different between source and dest? Can
it be the same?
- what is the story regarding versionning? Can you migrate from/to any
version, or only the same version?
- can the host source and destination be of different endianess?
- how is suspend and snapshot working?

There are probably other complications that I can't think of
immediately, but David or Juan help may help avoid mistakes.

It probably deserves a few explanations in docs/specs/tpm.txt.

>
> Signed-off-by: Stefan Berger 
> ---
>  hw/tpm/tpm_emulator.c | 312 
> --

It would be worth to add some basic tests. Either growing our own
tests/tpm-emu.c test emulator

or checking that swtpm is present (and of required version?) to
run/skip the test a more complete test.

>  1 file changed, 302 insertions(+), 10 deletions(-)
>
> diff --git a/hw/tpm/tpm_emulator.c b/hw/tpm/tpm_emulator.c
> index b787aee..da877e5 100644
> --- a/hw/tpm/tpm_emulator.c
> +++ b/hw/tpm/tpm_emulator.c
> @@ -55,6 +55,19 @@
>  #define TPM_EMULATOR_IMPLEMENTS_ALL_CAPS(S, cap) (((S)->caps & (cap)) == 
> (cap))
>
>  /* data structures */
> +
> +/* blobs from the TPM; part of VM state when migrating */
> +typedef struct TPMBlobBuffers {
> +uint32_t permanent_flags;
> +TPMSizedBuffer permanent;
> +
> +uint32_t volatil_flags;
> +TPMSizedBuffer volatil;
> +
> +uint32_t savestate_flags;
> +TPMSizedBuffer savestate;
> +} TPMBlobBuffers;
> +
>  typedef struct TPMEmulator {
>  TPMBackend parent;
>
> @@ -70,6 +83,8 @@ typedef struct TPMEmulator {
>
>  unsigned int established_flag:1;
>  unsigned int established_flag_cached:1;
> +
> +TPMBlobBuffers state_blobs;

Suspicious addition, it shouldn't be necessary in running state. It
could be allocated on demand? Even better if the field is removed, but
this may not be possible with VMSTATE macros.

>  } TPMEmulator;
>
>
> @@ -301,7 +316,8 @@ static int tpm_emulator_set_buffer_size(TPMBackend *tb,
>  return 0;
>  }
>
> -static int tpm_emulator_startup_tpm(TPMBackend *tb, size_t buffersize)
> +static int _tpm_emulator_startup_tpm(TPMBackend *tb, size_t buffersize,
> + bool is_resume)

Using underscore-prefixed names is discouraged. Call it tpm_emulator_init?

>  {
>  TPMEmulator *tpm_emu = TPM_EMULATOR(tb);
>  ptm_init init = {
> @@ -309,12 +325,17 @@ static int tpm_emulator_startup_tpm(TPMBackend *tb, 
> size_t buffersize)
>  };
>  ptm_res res;
>
> +DPRINTF("%s   is_resume: %d", __func__, is_resume);
> +

extra spaces, you may also add buffersize while at it.

>  if (buffersize != 0 &&
>  tpm_emulator_set_buffer_size(tb, buffersize, NULL) < 0) {
>  goto err_exit;
>  }
>
> -DPRINTF("%s", __func__);
> +if (is_resume) {
> +init.u.req.init_flags = cpu_to_be32(PTM_INIT_FLAG_DELETE_VOLATILE);
> +}

Since it's a flags, and for future extensibility, I would suggest |=.

> +
>  if (tpm_emulator_ctrlcmd(tpm_emu, CMD_INIT, , sizeof(init),
>   sizeof(init)) < 0) {
>  error_report("tpm-emulator: could not send INIT: %s",
> @@ -333,6 +354,11 @@ err_exit:
>  return -1;
>  }
>
> +static int tpm_emulator_startup_tpm(TPMBackend *tb, size_t buffersize)
> +{
> +return _tpm_emulator_startup_tpm(tb, buffersize, false);
> +}
> +
>  static bool tpm_emulator_get_tpm_established_flag(TPMBackend *tb)
>  {
>  TPMEmulator *tpm_emu = TPM_EMULATOR(tb);
> @@ -431,16 +457,21 @@ static size_t tpm_emulator_get_buffer_size(TPMBackend 
> *tb)
>  static int tpm_emulator_block_migration(TPMEmulator *tpm_emu)
>  {
>  Error *err = NULL;
> +ptm_cap caps = PTM_CAP_GET_STATEBLOB | PTM_CAP_SET_STATEBLOB |
> +   PTM_CAP_STOP;
>
> -error_setg(_emu->migration_blocker,
> -   "Migration disabled: TPM emulator not yet migratable");
> -migrate_add_blocker(tpm_emu->migration_blocker, );
> -if (err) {
> -error_report_err(err);
> -error_free(tpm_emu->migration_blocker);
> -tpm_emu->migration_blocker = NULL;
> +if