[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH v5.2 for 2.13 3/4] docs: tpm: add VM save/restor
From: |
Dr. David Alan Gilbert |
Subject: |
Re: [Qemu-devel] [PATCH v5.2 for 2.13 3/4] docs: tpm: add VM save/restore example and troubleshooting guide |
Date: |
Fri, 23 Mar 2018 20:13:44 +0000 |
User-agent: |
Mutt/1.9.2 (2017-12-15) |
* Stefan Berger (address@hidden) wrote:
> On 03/21/2018 02:42 PM, Dr. David Alan Gilbert wrote:
> > * Stefan Berger (address@hidden) wrote:
> > > Extend the docs related to TPM with specs related to VM save and
> > > restore and a troubleshooting guide for TPM migration.
> > >
> > > Signed-off-by: Stefan Berger <address@hidden>
> > This seems ok, so:
> >
> > Reviewed-by: Dr. David Alan Gilbert <address@hidden>
> >
> > but comments below:
> >
> > > ---
> > > docs/specs/tpm.txt | 106
> > > +++++++++++++++++++++++++++++++++++++++++++++++++++++
> > > 1 file changed, 106 insertions(+)
> > >
> > > diff --git a/docs/specs/tpm.txt b/docs/specs/tpm.txt
> > > index d1d7157..c230c4c 100644
> > > --- a/docs/specs/tpm.txt
> > > +++ b/docs/specs/tpm.txt
> > > @@ -200,3 +200,109 @@ crw-------. 1 root root 10, 224 Jul 11 10:11
> > > /dev/tpm0
> > > PCR-00: 35 4E 3B CE 23 9F 38 59 ...
> > > ...
> > > PCR-23: 00 00 00 00 00 00 00 00 ...
> > > +
> > > +
> > > +=== Migration with the TPM emulator ===
> > > +
> > > +The TPM emulator supports the following types of virtual machine
> > > migration:
> > > +
> > > +- VM save / restore (migration into a file)
> > > +- Network migration
> > > +- Snapshotting (migration into storage like QoW2 or QED)
> > > +
> > > +The following command sequences can be used to test VM save / restore.
> > > +
> > > +
> > > +In a 1st terminal start an instance of a swtpm using the following
> > > command:
> > > +
> > > +mkdir /tmp/mytpm1
> > > +swtpm socket --tpmstate dir=/tmp/mytpm1 \
> > > + --ctrl type=unixio,path=/tmp/mytpm1/swtpm-sock \
> > > + --log level=20 --tpm2
> > > +
> > > +In a 2nd terminal start the VM:
> > > +
> > > +qemu-system-x86_64 -display sdl -enable-kvm \
> > > + -m 1024 -boot d -bios bios-256k.bin -boot menu=on \
> > > + -chardev socket,id=chrtpm,path=/tmp/mytpm1/swtpm-sock \
> > > + -tpmdev emulator,id=tpm0,chardev=chrtpm \
> > > + -device tpm-tis,tpmdev=tpm0 \
> > > + -monitor stdio \
> > > + test.img
> > > +
> > > +Verify that the attached TPM is working as expected using applications
> > > inside
> > > +the VM.
> > > +
> > > +To store the state of the VM use the following command in the QEMU
> > > monitor in
> > > +the 2nd terminal:
> > > +
> > > +(qemu) migrate "exec:cat > testvm.bin"
> > > +(qemu) quit
> > > +
> > > +At this point a file called 'testvm.bin' should exists and the swtpm and
> > > QEMU
> > > +processes should have ended.
> > > +
> > > +To test 'VM restore' you have to start the swtpm with the same parameters
> > > +as before. If previously a TPM 2 [--tpm2] was saved, --tpm2 must now be
> > > +passed again on the command line.
> > > +
> > > +In the 1st terminal restart the swtpm with the same command line as
> > > before:
> > > +
> > > +swtpm socket --tpmstate dir=/tmp/mytpm1 \
> > > + --ctrl type=unixio,path=/tmp/mytpm1/swtpm-sock \
> > > + --log level=20 --tpm2
> > > +
> > > +In the 2nd terminal restore the state of the VM using the additonal
> > > +'-incoming' option.
> > > +
> > > +qemu-system-x86_64 -display sdl -enable-kvm \
> > > + -m 1024 -boot d -bios bios-256k.bin -boot menu=on \
> > > + -chardev socket,id=chrtpm,path=/tmp/mytpm1/swtpm-sock \
> > > + -tpmdev emulator,id=tpm0,chardev=chrtpm \
> > > + -device tpm-tis,tpmdev=tpm0 \
> > > + -incoming "exec:cat < testvm.bin" \
> > > + test.img
> > > +
> > > +
> > > +Troubleshooting migration:
> > > +
> > > +There are several reasons why migration may fail. In case of problems,
> > > +please ensure that the command lines adhere to the following rules and,
> > > +if possible, that identical versions of QEMU and swtpm are used at all
> > > +times.
> > > +
> > > +VM save and restore:
> > > + - QEMU command line parameters should be identical apart from the
> > > + '-incoming' option on VM restore
> > > + - swtpm command line parameters should be identical
> > > +
> > > +VM migration to 'localhost':
> > > + - QEMU command line parameters should be identical apart from the
> > > + '-incoming' option on the destination side
> > > + - swtpm command line parameters should point to two different
> > > + directories on the source and destination swtpm (--tpmstate dir=...)
> > > + (especially if different versions of libtpms were to be used on the
> > > + same machine).
> > > +
> > > +VM migration across the network:
> > > + - QEMU command line parameters should be identical apart from the
> > > + '-incoming' option on the destination side
> > > + - swtpm command line parameters should be identical
> > > +
> > > +VM Snapshotting:
> > > + - QEMU command line parameters should be identical
> > Well, they don't actually need to be identical; they just need to be
> > identically configured as far as the state goes. For example all the
> > paths to storage can be completely different on the two QEMUs.
>
> There is some leeway here in the parameters. For troubleshooting purposes it
> may be the easiest to keep parameters the same and then slowly adjust them
> to where one wants to have them. I don't want to go there , though.
>
> > > + - swtpm command line parameters should be identical
> > > +
> > > +
> > > +Besides that, migration failure reasons on the swtpm level may include
> > > +the following:
> > > +
> > > + - the versions of the swtpm on the source and destination sides are
> > > + incompatible
> > > + - downgrading of TPM state may not be supported
> > > + - the source and destination libtpms were compiled with different
> > > + compile-time options and the destination side refuses to accept the
> > > + state
> > > + - different migration keys are used on the source and destination side
> > > + and the destination side cannot decrypt the migrated state
> > > + (swtpm ... --migration-key ... )
> > Are there particular error messages swtpm will produce in these cases
> > to make it easy for people to tell which has happened?
>
> There are some error messages that libtpms will write if for example the
> checksum of the state was incorrect:
>
> Volatile state checksum error: 0x83
>
> Generally, the error code will also propagate back to this part in QEMU and
> at least that error code will be display with the message indicating the
> type of blob that was not accepted:
>
> "tpm-emulator: Setting the stateblob (type %d) failed with a TPM error 0x%x",
> type, tpm_result
>
>
> The tpm_result may be one of several error codes that could occur, like a
> hash was tried to be set that the implementation does not support, which
> would result in error code 0x83 (TPM_RC_HASH), or an RSA scheme is used by
> the imported blob that is not supported, which would result in error code
> 0x84 (TPM_RC_VALUE). There are many more. The question is what would one do
> with the additional knowledge of the error code. Under normal circumstances
> these error conditions wouldn't be encountered, unless someone deliberately
> resumed a VM after having compiled libtpms with a 'non-standard' set of
> compile-time options...
OK, that's fine; although when we find out the mistakes people make in
practice, it might be a good place to put the explanations of what not
to do!
Dave
> Stefan
>
>
> >
> > Dave
> >
> > > --
> > > 2.5.5
> > >
> > --
> > Dr. David Alan Gilbert / address@hidden / Manchester, UK
> >
>
--
Dr. David Alan Gilbert / address@hidden / Manchester, UK
Re: [Qemu-devel] [PATCH v5.2 for 2.13 0/4] tpm: Extend TPM with state migration support, Dr. David Alan Gilbert, 2018/03/21