Hi On Wed, Apr 5, 2017 at 7:32 PM Stefan Berger <stef...@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 <stef...@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
