qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v5 1/4] Provide support for the CUSE TPM


From: Stefan Berger
Subject: Re: [Qemu-devel] [PATCH v5 1/4] Provide support for the CUSE TPM
Date: Wed, 20 Jan 2016 10:54:47 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0

On 01/20/2016 10:46 AM, Daniel P. Berrange wrote:
On Wed, Jan 20, 2016 at 10:31:56AM -0500, Stefan Berger wrote:
"Daniel P. Berrange" <address@hidden> wrote on 01/20/2016 10:00:41
AM:


process at all - it would make sense if there was a single
swtpm_cuse shared across all QEMU's, but if there's one per
QEMU device, it feels like it'd be much simpler to just have
the functionality linked in QEMU.  That avoids the problem
I tried having it linked in QEMU before. It was basically rejected.
I remember an impl you did many years(?) ago now, but don't recall
the results of the discussion. Can you elaborate on why it was
rejected as an approach ? It just doesn't make much sense to me
to have to create an external daemon, a CUSE device and comms
protocol, simply to be able to read/write a plain file containing
the TPM state. Its massive over engineering IMHO and adding way
more complexity and thus scope for failure

The TPM 1.2 implementation adds 10s of thousands of lines of code. The TPM 2 implementation is in the same range. The concern was having this code right in the QEMU address space. It's big, it can have bugs, so we don't want it to harm QEMU. So we now put this into an external process implemented by the swtpm project that builds on libtpms which provides TPM 1.2 functionality (to be extended with TPM 2). We cannot call APIs of libtpms directly anymore, so we need a control channel, which is implemented through ioctls on the CUSE device.

   Stefan


Regards,
Daniel




reply via email to

[Prev in Thread] Current Thread [Next in Thread]