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

[Marc-André Lureau]

Hi

On Wed, Apr 5, 2017 at 5:04 PM Stefan Berger <address@hidden>
wrote:

> 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?
>

Could with /dev/fdset in theory, but it would be better to use chardevs
instead.

Is there any reason left to have 2 sockets? Couldn't the data be sent as
another message on the "ctrl-path" ?


> >      *logfile       - File path to use for swtpm logs
> >      *loglevel    - log level number, defaults to 5 (ignored if no
> > logfile provided)
> >
> > -  If spawn is off, data-path and ctrl-path must be provided to qemu,
> > where to connect already running swtpm
> > -  If spawn if on, both data-path and ctrl-path are optional. If not
> > provided, qemu uses socket pairs to communicates with swptm, as it is
> > doing now.
> >
> > Hope this satisfies all usecases, if everyone here happy with this i
> > can submit the new patch with these changes.
> >
> > - Amarnath
> >
>
>
> --
Marc-André Lureau