[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: |
Dr. David Alan Gilbert |
Subject: |
Re: [Qemu-devel] [PATCH 0/7] Provide support for the software TPM emulator |
Date: |
Mon, 3 Apr 2017 18:38:23 +0100 |
User-agent: |
Mutt/1.8.0 (2017-02-23) |
* 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
Re: [Qemu-devel] [PATCH 0/7] Provide support for the software TPM emulator, Dr. David Alan Gilbert, 2017/04/03
Re: [Qemu-devel] [PATCH 0/7] Provide support for the software TPM emulator, Stefan Berger, 2017/04/04
Re: [Qemu-devel] [PATCH 0/7] Provide support for the software TPM emulator, Amarnath Valluri, 2017/04/05
- Re: [Qemu-devel] [PATCH 0/7] Provide support for the software TPM emulator, Stefan Berger, 2017/04/05
- Re: [Qemu-devel] [PATCH 0/7] Provide support for the software TPM emulator, Marc-André Lureau, 2017/04/05
- Re: [Qemu-devel] [PATCH 0/7] Provide support for the software TPM emulator, Stefan Berger, 2017/04/05
- Re: [Qemu-devel] [PATCH 0/7] Provide support for the software TPM emulator, Marc-André Lureau, 2017/04/05
- Re: [Qemu-devel] [PATCH 0/7] Provide support for the software TPM emulator, Stefan Berger, 2017/04/05