Hi
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
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.