On Wed, Jan 20, 2016 at 11:06:45AM -0500, Stefan Berger wrote:
"Michael S. Tsirkin" <address@hidden> wrote on 01/20/2016 10:58:02 AM:
From: "Michael S. Tsirkin" <address@hidden>
On Wed, Jan 20, 2016 at 10:36:41AM -0500, Stefan Berger wrote:
"Michael S. Tsirkin" <address@hidden> wrote on 01/20/2016 10:20:58 AM:
From: "Michael S. Tsirkin" <address@hidden>
The CUSE TPM and associated tools can be found here:
https://github.com/stefanberger/swtpm
(please use the latest version)
To use the external CUSE TPM, the CUSE TPM should be started as
follows:
# terminate previously started CUSE TPM
/usr/bin/swtpm_ioctl -s /dev/vtpm-test
# start CUSE TPM
/usr/bin/swtpm_cuse -n vtpm-test
QEMU can then be started using the following parameters:
qemu-system-x86_64 \
[...] \
-tpmdev cuse-tpm,id=tpm0,cancel-path=/dev/null,path=/
dev/vtpm-test
\
-device tpm-tis,id=tpm0,tpmdev=tpm0 \
[...]
Signed-off-by: Stefan Berger <address@hidden>
Cc: Eric Blake <address@hidden>
Before we add a dependency on this interface,
I'd rather see this interface supported in kernel
and not just in CUSE.
For using the single hardware TPM, we have the passthrough type.
It's usage is
limited.
CUSE extends the TPM character device interface with ioctl's. Behind the
character device we can implement a TPM 1.2 and a TPM 2. Both TPM
implementations require large amounts of code, which I don't thinkshould go
into the Linux kernel itself. So I don't know who would implement this
interface inside the Linux kernel.
Stefan
BTW I'm not talking about the code - I'm talking about the interfaces here.
One way would be to add support for these interface support in the kernel.
Maybe others can be replaced with QMP events so management
can take the necessary action.
As long as this is not the case, I suspect this code will have to stay
out of tree :( We can't depend on interfaces provided solely by cuse
devices on github.
Why is that? I know that the existing ioctls cannot be modified anymore once
QEMU accepts the code. So I don't understand it. Some of the ioctls are only
useful when emulating a hardware device,
Maybe they can be replaced with QMP events?
These could be emitted unconditionally, and ignored
by management in passthrough case.
so there's no need for them in a
kernel interface unless one was to put the vTPM code into the Linux kernel, but
I don't see that this is happening. What is better about a kernel interface
versus one implemented by a project on github assuming that the existing ioctls
are stable? What is the real reason here?
Stefan
That someone went to the trouble of reviewing the interface for
long-term maintainability, portability etc. That it obeys some existing
standards for API use, coding style etc and will continue to.