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

[Dr. David Alan Gilbert]

* Patrick Ohly (address@hidden) wrote:
> On Mon, 2017-04-03 at 18:07 +0100, Daniel P. Berrange 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.
> 
> The intended usage is for emulating a TPM in software, for example to do
> automated testing of an OS which requires a TPM or to do software
> development in an environment were it is easy to reset the TPM. That
> doesn't require any privileges, because swtpm just reads and writes
> files owned by the user who calls qemu.

Being able to do fancier permissions would let you use it in a real VM
situation so that the virtual guest sees it's own TPM; you would then
want to protect the TPM data files pretty carefully - for example stop
one compromised guest sniffing around the TPM data for another.

> >  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.
> 
> Which privileges and use cases did you have in mind?
> 
> swtpm already can be started so that it listens on a Unix domain socket,
> instead of inheriting something from the parent. It shouldn't be hard to
> add that as an alternative to the existing spawning code.
> 
> I can think of one use case: spawning swtpm in advance under debugging
> tools like gdb or valgrind. Is that enough justification for adding more
> code?

Or you could just remove the spawning code and use existing sockets; less code!

Dave

> -- 
> Best Regards, Patrick Ohly
> 
> The content of this message is my personal opinion only and although
> I am an employee of Intel, the statements I make here in no way
> represent Intel's position on the issue, nor am I authorized to speak
> on behalf of Intel on this matter.
> 
> 
> 
> 
--
Dr. David Alan Gilbert / address@hidden / Manchester, UK