[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH 0/7] Provide support for the software TPM emulat
Re: [Qemu-devel] [PATCH 0/7] Provide support for the software TPM emulator
Wed, 05 Apr 2017 15:08:20 +0000
On Wed, Apr 5, 2017 at 5:04 PM Stefan Berger <address@hidden>
> 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
> > 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
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
Re: [Qemu-devel] [PATCH 0/7] Provide support for the software TPM emulator, Patrick Ohly, 2017/04/03
Re: [Qemu-devel] [PATCH 0/7] Provide support for the software TPM emulator, Dr. David Alan Gilbert, 2017/04/03
Re: [Qemu-devel] [PATCH 0/7] Provide support for the software TPM emulator, Stefan Berger, 2017/04/04
Re: [Qemu-devel] [PATCH 0/7] Provide support for the software TPM emulator, Amarnath Valluri, 2017/04/05
- Re: [Qemu-devel] [PATCH 0/7] Provide support for the software TPM emulator, (continued)