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