qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 0/7] Provide support for the software TPM emulat


From: Marc-André Lureau
Subject: Re: [Qemu-devel] [PATCH 0/7] Provide support for the software TPM emulator
Date: Mon, 03 Apr 2017 17:18:37 +0000

Hi

On Mon, Apr 3, 2017 at 7:08 PM Daniel P. Berrange <address@hidden>
wrote:

> On Fri, Mar 31, 2017 at 04:10:09PM +0300, Amarnath Valluri wrote:
> > Briefly, Theses set of patches introduces:
> >  - new TPM backend driver to support software TPM emulators(swtpm(1)).
> >  - and few supported fixes/enhancements/cleanup to existing tpm backend
> code.
> >
> > The similar idea was initiated earliar(2) by Stefan Berger(CCed) with
> slightly
> > different approach, using CUSE. As swtpm has excellent support for unix
> domain
> > sockets, hence this implementation uses unix domain sockets to
> communicate with
> > swtpm.
> >
> > When Qemu is configured with 'emulator' tpm backend, it spawns 'swtpm'
> and
> > communicates its via Unix domain sockets.
>
> I'm not convinced that having QEMU spawning swtpm itself is a desirable
> approach, as it means QEMU needs to have all the privileges that swtpm
> will need, so that swtpm can inherit them. At the very least I think we
> need to have a way to disable this spawning, so it can connect to a
> pre-existing swtpm process that's been spawned ahead of time. This will
> let us have stricter privilege separation.
>

Could the security contexts be given as arguments to qemu for the
subprocesses? The reason to have qemu spawn its own subprocess is that it
would leave more flexibility on how and when to do it, or even to use
multiple subprcesses if some day that makes sense. If there is no reason to
make this interface public or shared by various other processes, I would
rather see it as internal to qemu rather than managed by other tools. It
also makes command line & testing easier.

Similarly, I think the swtpm protocol must offer enough guarantee about
stability, versionning / capabilities, that we can later extend it. swtpm
could likely be implemented in qemu (by using libswtpm), using a private
protocol. It's hard to estimate how much code that represents, but I think
by reusing glib & qemu common it should be fairly small & simple. I haven't
looked in details.

thanks
-- 
Marc-André Lureau


reply via email to

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