[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH V10 5/5] Add a TPM Passthrough backend driver im

From: Stefan Berger
Subject: Re: [Qemu-devel] [PATCH V10 5/5] Add a TPM Passthrough backend driver implementation
Date: Tue, 27 Sep 2011 14:53:01 -0400
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20110621 Fedora/3.1.11-1.fc14 Lightning/1.0b3pre Thunderbird/3.1.11

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.

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

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]