[Top][All Lists]

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

Re: [Qemu-devel] [PATCH v5 1/4] Provide support for the CUSE TPM

From: Stefan Berger
Subject: Re: [Qemu-devel] [PATCH v5 1/4] Provide support for the CUSE TPM
Date: Thu, 16 Jun 2016 11:20:27 -0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.1

On 06/16/2016 04:25 AM, Daniel P. Berrange wrote:
On Thu, Jun 16, 2016 at 09:05:20AM +0100, Dr. David Alan Gilbert wrote:
* Stefan Berger (address@hidden) wrote:
On 06/15/2016 03:30 PM, Dr. David Alan Gilbert wrote:

So what was the multi-instance vTPM proxy driver patch set about?
That's for containers.
Why have the two mechanisms? Can you explain how the multi-instance
proxy works; my brief reading when I saw your patch series seemed
to suggest it could be used instead of CUSE for the non-container case.
One of the key things that was/is not appealing about this CUSE approach
is that it basically invents a new ioctl() mechanism for talking to
a TPM chardev. With in-kernel vTPM support, QEMU probably doesn't need
to have any changes at all - its existing driver for talking to TPM
char devices ought to just work. All that would be required is libvirt
support too configure the vTPM instances.

The issue here is mainly the control channel as stated in the other email.

The CUSE TPM allows users to provide the name of the device that will appear in /dev. Since the kernel TPM driver basically owns the /dev/tpm%d names, a CUSE TPM should use a different name. I don't quite understand why such a device should not be able to offer an ioctl interface for its control channel? In case of the CUSE TPM it's not a hardware device underneath but a software emulation of a hardware device that needs an additional control channel to allow certain functionality to be reached that is typically hidden by the device driver. It just happens to have a compatible data channel that works just like /dev/tpm%d.

The ioctl interface is in my opinion only a problem in so far as the control channel commands can be larger than what the Linux CUSE driver supports so that the implementation had to work around this restriction. As stated in the other email, there's the possibility of using the TPM emulator with socket interfaces where the data and control channels can now use any combination of UnixIO and TCP sockets, so two UnixIO sockets (for data and control) are possible.


reply via email to

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