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

["Marc-André Lureau" <marcandre.lureau@gmail.com>]

Hi

On Wed, Apr 5, 2017 at 7:32 PM Stefan Berger <stefanb@linux.vnet.ibm.com>
wrote:

> On 04/05/2017 11:08 AM, Marc-André Lureau wrote:
> > Hi
> >
> > On Wed, Apr 5, 2017 at 5:04 PM Stefan Berger <stefanb@linux.vnet.ibm.com
> >
> > wrote:
> >
> >> On 04/05/2017 03:09 AM, Amarnath Valluri wrote:
> >>>
> >>> On 03.04.2017 20 <03%2004%2020%2017%2020>
> <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" ?
>
> Better to keep them separate so whatever comes out of a VM will never be
> mistaken for a control command.
>

This is a moot argument, there is no reason the code would mix the two,

An alternative to make the setup easier is to pass the data socket through
the ctrl socket, perhaps.


> >
> >
> >>>       *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
> >
>
>
> --
Marc-André Lureau