11080 2017-02-20 08:15:41 +0000 Enabling testing TPM(v1.2) Support on QEMU 2017-04-18 07:31:58 +0000 1 1 6 Yocto Project Subprojects IoT Reference OS Kit intel-iot-refkit-security unspecified x86 Multiple RESOLVED FIXED Medium enhancement 2.3 M4 11201 1 amarnath.valluri amarnath.valluri amarnath.valluri matti-pekka.sivosuo mikko.ylinen patrick.ohly --- --- No (bug/feature does not impact docs) oldest_to_newest 70822 0 amarnath.valluri 2017-02-20 08:15:41 +0000 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. 72205 1 amarnath.valluri 2017-04-10 11:00:18 +0000 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. 72268 2 mikko.ylinen 2017-04-11 05:13:54 +0000 (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. 72273 3 amarnath.valluri 2017-04-11 08:45:32 +0000 (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 72575 4 mikko.ylinen 2017-04-18 07:28:57 +0000 Amarnath, this can be set to 'RESOLVED', IMO. 72576 5 amarnath.valluri 2017-04-18 07:31:58 +0000 swtpm/meta-security patches are merged to upstream, and qemu changes are submitted upstream and .bbappended in refkit.