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

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

On 06/16/2016 03:24 PM, Dr. David Alan Gilbert wrote:
> * Stefan Berger (stefanb@linux.vnet.ibm.com) wrote:
>> 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.
> Right, so that code isn't in upstream qemu is it?

I was talking about the TPM emulator side that has been extended like 
this, not QEMU.

>
>>> 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.
> Right, so what I'm thinking is:
>     a) QEMU talks to /dev/vtpm-whatever for the normal TPM stuff
>        no/little code is needed to be added to qemu upstream for that

If we talk to /dev/vtpm-whatever, then in my book we would talk to a 
CUSE TPM device. We have compatibility for that via fd passing from libvirt.

>     b) Then you talk to the control side via an fd/socket
>        you need to add your existing code for that.

Not sure what /dev/vtpm-whatever is. If you mean the vtpm proxy driver 
by it then I don't understand why we would need that dependency along 
with the complication of how the setup for this particular device needs 
to be done (run ioctl on /dev/vtpmx to get a front end device and 
backend device file descriptor which then has to be passed to the swtpm 
to read from and write to).

>
> So that doesn't depend on CUSE, it doesn't depend on your particular

If it doesn't depend on CUSE, it depends on a rather novel device driver 
that doesn't need to be used in the QEMU case.

> vTPM implementation (except for the control socket data, but then
> hopefully that's pretty abstract); all good?
Not sure I followed you above.

    Stefan

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