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

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

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 (stefanb@linux.vnet.ibm.com) wrote:
>>> On 06/15/2016 03:30 PM, Dr. David Alan Gilbert wrote:
>> <snip>
>>
>>>> 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.

     Stefan