* Patrick Ohly (patrick.o...@intel.com) 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 / dgilb...@redhat.com / Manchester, UK
