Hi On Wed, Mar 1, 2017 at 6:50 PM Stefan Berger <stef...@linux.vnet.ibm.com> wrote:
On 03/01/2017 09:17 AM, Marc-André Lureau wrote: Hi On Wed, Mar 1, 2017 at 5:26 PM Stefan Berger <stef...@us.ibm.com> wrote: "Daniel P. Berrange" <berra...@redhat.com> wrote on 03/01/2017 07:54:14 AM: > > On Wed, Mar 01, 2017 at 07:25:28AM -0500, Stefan Berger wrote: > > 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 (stef...@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 > > > > We still need the control channel with the vTPM to reset it upon VM reset, > > for getting and setting the state of the vTPM upon snapshot/suspend/resume, > > changing locality, etc. > > You ultimately need the same mechanisms if using in-kernel vTPM with > containers as containers can support snapshot/suspend/resume/etc too. The vTPM running on the backend side of the vTPM proxy driver is essentially the same as the CUSE TPM used for QEMU. I has the same control channel through sockets. So on that level we would have support for the operations but not integrated with anything that would support container migration. Ah that might explain why you added the socket control channel, but there is no user yet? (or some private product perhaps). Could you tell if control and data channels need to be synchronized in any ways? In the general case, synchronization would have to happen, yes. So a lock that is held while the TPM processes data would have to lock out control channel commands that operate on the TPM data. That may be missing. In case of QEMU being the client, not much concurrency would be expected there just by the way QEMU interacts with it. Could the data channel be muxed in with the control channel? )that is only use one control socket) A detail: A corner case is live-migration with the TPM emulation being busy processing a command, like creation of a key. In that case QEMU would keep on running and only start streaming device state to the recipient side after the TPM command processing finishes and has returned the result. QEMU wouldn't want to get stuck in a lock between data and control channel, so would have other means of determining when the backend processing is done. Getting back to the original out-of-process design: qemu links with many libraries already, perhaps a less controversial approach would be to have a linked in solution before proposing out-of-process? This would be easier to deal with for I had already proposed a linked-in version before I went to the out-of-process design. Anthony's concerns back then were related to the code not being trusted and a segfault in the code could bring down all of QEMU. That we have test suites running over it didn't work as an argument. Some of the test suite are private, though. I think Anthony argument is valid for anything running in qemu :) So I don't see why TPM would be an exception now. Could you say how much is covered by the public test suite? About tests, is there any test for qemu TIS? management layers etc. This wouldn't be the most robust solution, but could get us somewhere at least for easier testing and development. Hm. In terms of external process it's basically 'there', so I don't related to the 'easier testing and development.' The various versions with QEMU + CUSE TPM driver patches applied are here. https://github.com/stefanbergToo bader/qemu-tpm/tree/v2.8.0+tpm <https://github.com/stefanberger/qemu-tpm/tree/v2.8.0+tpm> Some people may want to use simulated TPM with qemu without the need for security, just to do development/testing. Dealing with external processes makes also qemu development and testing more difficult. Changing the IPC interface is more complicated than having linked in solution. Testing is easier if you can just start/kill one qemu process. I can't say if it's really needed to ease progress, but at least it would avoid that CUSE/IPC discussion for now. I have an older version of libvirt that has the necessary patches applied to start QEMU with the external TPM. There's also virt-manager support. Ok, I think it would be worth to list all the up to date trees in http://www.qemu-project.org/Features/TPM (btw, that page is 5y old, would be nice if you could refresh it, I bet some changed happened) If CUSE is the wrong interface, then there's a discussion about this here. Alternatively UnixIO for data and control channel could be used. https://github.com/stefanberger/swtpm/issues/4 If there is no strong argument for CUSE, I would go without it (I'd also suggest a similar approach to vhost-user backend I proposed in http://lists.nongnu.org/archive/html/qemu-devel/2016-06/msg01014.html, it spawns a backend and pass an extra socketpair fd to it) Stefan thanks -- Marc-André Lureau -- Marc-André Lureau
