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

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

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