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:
> On Wed, Apr 5, 2017 at 5:04 PM Stefan Berger
>> 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
>>>>> backend code.
>>>>> The similar idea was initiated earliar(2) by Stefan Berger(CCed)
>>>>> with slightly
>>>>> different approach, using CUSE. As swtpm has excellent
>>>>> unix domain
>>>>> sockets, hence this implementation uses unix domain sockets to
>>>>> communicate with
>>>>> 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
>>>> 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.
>>>> let us have stricter privilege separation.
>>> Both spawning inside qemu and connecting to already running
>>> its own pros, Hence we can make this spawning as backend
>>> detail, So it looks like this:
>>> 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
>> FD passing would work?
> Could with /dev/fdset in theory, but it would be better to use
> Is there any reason left to have 2 sockets? Couldn't the data be
> another message on the "ctrl-path" ?
Better to keep them separate so whatever comes out of a VM will
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.