[Top][All Lists]

[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

From: Stefan Berger
Subject: Re: [Qemu-devel] [PATCH 0/7] Provide support for the software TPM emulator
Date: Wed, 5 Apr 2017 14:00:44 -0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0

On 04/05/2017 01:49 PM, Marc-André Lureau wrote:

On Wed, Apr 5, 2017 at 7:32 PM Stefan Berger <address@hidden <mailto:address@hidden>> wrote:

    On 04/05/2017 11:08 AM, Marc-André Lureau wrote:
    > Hi
    > On Wed, Apr 5, 2017 at 5:04 PM Stefan Berger
    <address@hidden <mailto:address@hidden>>
    > 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
    >>>>>    - 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
    >>>> 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
    >>> 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
    > 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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]