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

[Stefan Berger <stefanb@linux.vnet.ibm.com>]

On 04/05/2017 01:49 PM, Marc-André Lureau wrote:
> Hi
>
> On Wed, Apr 5, 2017 at 7:32 PM Stefan Berger 
> <stefanb@linux.vnet.ibm.com <mailto: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 <mailto:stefanb@linux.vnet.ibm.com>>
>     > wrote:
>     >
>     >> On 04/05/2017 03:09 AM, Amarnath Valluri wrote:
>     >>>
>     >>> On 03.04.2017 20 <tel: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.

Libvirt could open two sockets and pass them via command line. I don't 
think there's a problem in this case.
With command line it may be a bit more typing, but passing the data 
socket through the ctrl socket doesn't seem to work so easily, so one 
may have to resort to typing the paths.