[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
Michael S. Tsirkin
Re: [Qemu-devel] [PATCH V10 5/5] Add a TPM Passthrough backend driver implementation
Tue, 27 Sep 2011 21:07:33 +0300
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?
> >>+Also, if TPM ownership is released from within a VM then this will
> >>+require a reboot of the host and the user will have to enter the host's
> >>+firmware menu to enable and activate the TPM again.
> > Further, if TPM ownership is released from within a VM,
> > TPM gets deactivated in host.
> Further, if TPM ownership is release from within a VM, the host's
> TPM gets disabled and deactivate.
is release->is released
deactivate -> deactivated?
> > To enable and activate the TPM again afterwards,
> > host has to be rebooted and the user is required to
> > enter the host's firmware menu.
> >>If the TPM is left
> >>+disabled and deactivated most TPM commands will fail.
> >Why do we allow guest to do this then?
> You cannot prevent it. This is due to how the TPM works. We cannot
> intercept the commands, either,
Hmm, they go from guest to qemu to host, no?
> 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?
> 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.
- [Qemu-devel] [PATCH V10 0/5] Qemu Trusted Platform Module (TPM) integration, Stefan Berger, 2011/09/27
- [Qemu-devel] [PATCH V10 2/5] Add TPM (frontend) hardware interface (TPM TIS) to Qemu, Stefan Berger, 2011/09/27
- [Qemu-devel] [PATCH V10 4/5] Build the TPM frontend code, Stefan Berger, 2011/09/27
- [Qemu-devel] [PATCH V10 3/5] Add a debug register, Stefan Berger, 2011/09/27
- [Qemu-devel] [PATCH V10 1/5] Support for TPM command line options, Stefan Berger, 2011/09/27
- [Qemu-devel] [PATCH V10 5/5] Add a TPM Passthrough backend driver implementation, Stefan Berger, 2011/09/27