Bug 11080

Summary:	Enabling testing TPM(v1.2) Support on QEMU
Product:	[Yocto Project Subprojects] IoT Reference OS Kit	Reporter:	Amaranth Valluri <amarnath.valluri>
Component:	intel-iot-refkit-security	Assignee:	Amaranth Valluri <amarnath.valluri>
Status:	RESOLVED FIXED	QA Contact:
Severity:	enhancement
Priority:	Medium	CC:	amarnath.valluri, matti-pekka.sivosuo, mikko.ylinen, patrick.ohly
Version:	unspecified
Target Milestone:	2.3 M4
Hardware:	x86
OS:	Multiple
Whiteboard:
OS type for building Yocto:	---	Type of Regression:	---
Verified:		Documentation change:	No (bug/feature does not impact docs)
Bug Depends on:
Bug Blocks:	11201

Description Amaranth Valluri 2017-02-20 08:15:41 UTC

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.

Comment 1 Amaranth Valluri 2017-04-10 11:00:18 UTC

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.

Comment 2 Mikko Ylinen 2017-04-11 05:13:54 UTC

(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.

Comment 3 Amaranth Valluri 2017-04-11 08:45:32 UTC

(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

Comment 4 Mikko Ylinen 2017-04-18 07:28:57 UTC

Amarnath, this can be set to 'RESOLVED', IMO.

Comment 5 Amaranth Valluri 2017-04-18 07:31:58 UTC

swtpm/meta-security patches are merged to upstream, and qemu changes are submitted upstream and .bbappended in refkit.