Using 'swtpm(Software TPM Emulator)' with QEMU is currently depends on starting swtpm as root before each runqemu invocation. This is neither user-friendly nor compatible with some automated testing environments where 'no-root' is required. The reason for this is that swtpm emulates /dev/vtpm0 via CUSE (character device in user space) and needs root privileges for setting that up. qemu communicates with swtpm in two ways: 1) read/write calls 2) ioctl calls. A better solution would be to connect qemu to swtpm through a unix domain datagram socket (no root rights needed). Read/write can work as before. ioctls could be mapped to out-of-band messages.
Patch set submitted to upstream, currently under review: http://lists.nongnu.org/archive/html/qemu-devel/2017-04/msg01287.html From QEMU upstream getting some resistance against using of 'swtpm' for TPM emulation, as it is foreign project to qemu. And suggesting to define a private/protocol protocol specification. So it is not realistic that the current proposal accepted by upstream with in the M4 time frame.
(In reply to comment #1) > From QEMU upstream getting some resistance against using of 'swtpm' for TPM > emulation, as it is foreign project to qemu. And suggesting to define a > private/protocol protocol specification. So it is not realistic that the > current proposal accepted by upstream with in the M4 time frame. One may argue whether the upstream acceptance is a criteria to deliver this feature. I think not. Especially if we follow the dependency logic: it would not be possible to deliver bug #11070 either if this was not closed. AFAICS, the swtpm part is done. Have you submitted a meta-security patch to update the SRCREV? Also, the qemu part we'd need to maintain in a bbappend until the upstream patch is merged. The upstream status shall be tracked in the patch Upstream-Status.
(In reply to comment #2) > (In reply to comment #1) > > > From QEMU upstream getting some resistance against using of 'swtpm' for TPM > > emulation, as it is foreign project to qemu. And suggesting to define a > > private/protocol protocol specification. So it is not realistic that the > > current proposal accepted by upstream with in the M4 time frame. > > One may argue whether the upstream acceptance is a criteria to deliver this > feature. I think not. Especially if we follow the dependency logic: it would > not be possible to deliver bug #11070 either if this was not closed. > > AFAICS, the swtpm part is done. Have you submitted a meta-security patch to > update the SRCREV? I have submitted the PR: https://lists.yoctoproject.org/pipermail/yocto/2017-April/035572.html
Amarnath, this can be set to 'RESOLVED', IMO.
swtpm/meta-security patches are merged to upstream, and qemu changes are submitted upstream and .bbappended in refkit.