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

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

On 06/16/2016 01:54 PM, Dr. David Alan Gilbert wrote:
> * Stefan Berger (stefanb@linux.vnet.ibm.com) wrote:
>> On 06/16/2016 11:22 AM, Dr. David Alan Gilbert wrote:
>>> * Stefan Berger (stefanb@linux.vnet.ibm.com) wrote:
>>>> On 06/16/2016 04:05 AM, 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.
>>>> The multi-instance vtpm proxy driver basically works through usage of an
>>>> ioctl() on /dev/vtpmx that is used to spawn a new front- and backend pair.
>>>> The front-end is a new /dev/tpm%d device that then can be moved into the
>>>> container (mknod + device cgroup setup). The backend is an anonymous file
>>>> descriptor that is to be passed to a TPM emulator for reading TPM requests
>>>> coming in from that /dev/tpm%d and returning responses to. Since it is
>>>> implemented as a kernel driver, we can hook it into the Linux Integrity
>>>> Measurement Architecture (IMA) and have it be used by IMA in place of a
>>>> hardware TPM driver. There's ongoing work in the area of namespacing support
>>>> for IMA to have an independent IMA instance per container so that this can
>>>> be used.
>>>>
>>>> A TPM does not only have a data channel (/dev/tpm%d) but also a control
>>>> channel, which is primarily implemented in its hardware interface and is
>>>> typically not fully accessible to user space. The vtpm proxy driver _only_
>>>> supports the data channel through which it basically relays TPM commands and
>>>> responses from user space to the TPM emulator. The control channel is
>>>> provided by the software emulator through an additional TCP or UnixIO socket
>>>> or in case of CUSE through ioctls. The control channel allows to reset the
>>>> TPM when the container/VM is being reset or set the locality of a command or
>>>> retrieve the state of the vTPM (for suspend) and set the state of the vTPM
>>>> (for resume) among several other things. The commands for the control
>>>> channel are defined here:
>>>>
>>>> https://github.com/stefanberger/swtpm/blob/master/include/swtpm/tpm_ioctl.h
>>>>
>>>> For a container we would require that its management stack initializes and
>>>> resets the vTPM when the container is rebooted. (These are typically
>>>> operations that are done through pulses on the motherboard.)
>>>>
>>>> In case of QEMU we would need to have more access to the control channel,
>>>> which includes initialization and reset of the vTPM, getting and setting its
>>>> state for suspend/resume/migration, setting the locality of commands, etc.,
>>>> so that all low-level functionality is accessible to the emulator (QEMU).
>>>> The proxy driver does not help with this but we should use the swtpm
>>>> implementation that either has that CUSE interface with control channel
>>>> (through ioctls) or provides UnixIO and TCP sockets for the control channel.
>>> OK, that makes sense; does the control interface need to be handled by QEMU
>>> or by libvirt or both?
>> The control interface needs to be handled primarily by QEMU.
>>
>> In case of the libvirt implementation I am running an external program
>> swtpm_ioctl that uses the control channel to gracefully shut down any
>> existing running TPM emulator whose device name happens to have the same
>> name as the device of the TPM emulator that is to be created. So it cleans
>> up before starting a new TPM emulator just to make sure that that new TPM
>> instance can be started. Detail...
>>
>>> Either way, I think you're saying that with your kernel interface + a UnixIO
>>> socket you can avoid the CUSE stuff?
>> So in case of QEMU you don't need that new kernel device driver -- it's
>> primarily meant for containers. For QEMU one would start the TPM emulator
>> and make sure that QEMU has access to the data and control channels, which
>> are now offered as
>>
>> - CUSE interface with ioctl
>> - TCP + TCP
>> - UnixIO + TCP
>> - TCP + UnioIO
>> - UnixIO + UnixIO
>> - file descriptors passed from invoker
> OK, I'm trying to remember back; I'll admit to not having
> liked using CUSE, but didn't using TCP/Unix/fd for the actual TPM
> side require a lot of code to add a qemu interface that wasn't
> ioctl?

Adding these additional interface to the TPM was a bigger effort, yes.

> Doesn't using the kernel driver give you the benefit of both worlds,
> i.e. the non-control side in QEMU is unchanged.

Yes. I am not sure what you are asking, though. A control channel is 
necessary no matter what. The kernel driver talks to /dev/vtpm-<VM uuid> 
via a file descriptor and uses commands sent through ioctl for the 
control channel. Whether QEMU now uses an fd that is a UnixIO or TCP 
socket to send the commands to the TPM or an fd that uses CUSE, doesn't 
matter much on the side of QEMU. The control channel may be a bit 
different when using ioctl versus an fd (for UnixIO or TCP) or ioctl. I 
am not sure why we would send commands through that vTPM proxy driver in 
case of QEMU rather than talking to the TPM emulator directly.

   Stefan

>
> Dave
>
>>    Stefan
>>
> --
> Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
>