On 09/27/2011 02:07 PM, Michael S. Tsirkin wrote:
On Tue, Sep 27, 2011 at 01:38:52PM -0400, Stefan Berger wrote:
On 09/27/2011 01:13 PM, Michael S. Tsirkin wrote:
On Tue, Sep 27, 2011 at 10:50:48AM -0400, Stefan Berger wrote:
+Since the host's firmware (BIOS/UEFI) has already initialized the TPM,
+the VM's firmware (BIOS/UEFI) will not be able to initialize the
+TPM again and may therefore not show a TPM-specific menu that would
+otherwise allow the user to configure the TPM.
So what happens is guest tries to init tpm, this fails,
and then guest keeps going and as luck would have it
it can actually operate tpm fine?
What happens is that the SeaBIOS extensions will try to initialize the
host's TPM as if it was the libtpms-based TPM using the same standard
initialization sequence that is used for every TPM. However, the host's
TPM cannot be initialized again (host's BIOS did this already) and thus
SeaBIOS assumes that it is talking to a faulty device and at least will
not assume it has an operable TPM and *not* send any more commands to
it. However, the TPM does not shut down because of this attempt to
re-initialize but continues to operate. SeaBIOS will then also not show
the TPM menu where the user has the choice of several commands to for
example activate or enable a TPM or clear ownership. All these commands
would require 'physical presence' to be activated which cannot be done
after the host's BIOS has previously 'released' physical presence before
booting the host OS.
So then Linux boots and, depending on which state the TPM is in, it may
for example allow you to create keys, perform sign operations or modify
its Platform Configuration Registers (PCRs) ('extend' the PCRs) even
though SeaBIOS couldn't initialize the TPM -- in effect one can then use
the TPM from the VM as one could from an application running on the
host. This is the ideal case. However, the TPM has a rather complex
state machine and one can get the TPM into a state called 'disabled'
where several commands don't work anymore and once it's also
'deactivated' you can almost not perform any operations with it. In the
latter case you have to reboot the host to enable and activate the TPM
again. During the reboot I guess the CPU/chipset is going to pulse a
line to the TPM and tell it to restart as well, which then in turn
allows the host's BIOS to run its standard TPM initialization sequence
again. If one enters the BIOS menu it typically indicates physical
presence to the TPM using a command, which in turn allows the user to
then activate and enable the TPM again.
FYI:
The TPM has more than 100 different operations. Some of them are only
possible if the TPM is in a certain state, for example those to
enable/activate the TPM require 'physical presence'. Also being able to
have it create keys for example requires that one has previously taken
ownership of the TPM.
There are also two possible ways to release ownership. One command can
be sent to the TPM from the BIOS with 'physical presence' asserted. The
other can be sent from the OS. In the former case one doesn't need a
password and the assumption is that the owner of the machine may have
forgotten the password and therefore needs to have a way to release
ownership to take ownership again and establish a new password. In the
latter case one needs to know the password for the TPM when issuing the
command -- the encrypted password is part of the command sent to them
TPM. Also, the side-effect of releasing ownership of the TPM is that all
previously generated keys won't work anymore.
and I don't think it makes much
sense. I wrote this part of the docs to make people aware of these
scenarios so they don't come as a surprise.
Can we return an error, or ignore the release
command? If someone really wants this unsafe behaviour
we could make this an option, off by default.
In effect you'd have to parse every command that goes from the VM to
the host and intercept it in the passthrough driver. I don't want to
prevent it since it's a valid usage scenario
That's what I'm asking. Why is this valid and useful?
Someone could take ownership of the TPM from within a VM, create keys,
use them for signing/encryption etc. and then at some point release
ownership from within that VM again. That I think is a valid scenario,
but it has these previously mentioned side-effects.
but it has side effects
(host needs to be rebooted). Even if we were to intercept this
command then the user always has the possibility to send commands in
an encrypted form (using TPM's transport 'tunnel') where one
couldn't intercept this particular command anymore. So, my
suggestion is we leave it as it is but we make people aware of these
scenarios.
Stefan
This looks like a major limitation.
You'd have to eliminate 'transport mode' completely. The only way to do
this would be to work with a black- or white-list of TPM ordinals that
are forbidden/allowed. Well, I am not sure it will make the operation of
the device easier and users would really know the details. The libtpms
based TPM will improve that situation in terms of the usage model being
the same as if one was to use the TPM from the host directly.
Stefan
