On 04/05/2017 03:09 AM, Amarnath Valluri wrote:
On 03.04.2017 20 <03%2004%2020%2017%2020>:07, 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. 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.
Both spawning inside qemu and connecting to already running swtpm has
its own pros, Hence we can make this spawning as backend configuration
detail, So it looks like this:
-tpmdev
emulator,id=id,tpmstatedir=dir[,spawn=[on|off],data-path=path,ctrl-path=path,logfile=path,loglevel=number]
Options details:
tpmstatedir - Directory path, which swtpm should use for
storing TPM state
*spawn - should spawn new process, defaults to 'off'
*path - swtpm binary path to spawn, ignored if spawn is off
*data-path - Socket path to use/connect for data messages
*ctrl-path - Socket path to use/connect for out-of-band control
messages
FD passing would work?