Re: [Xen-devel] [PATCH 11/11] add vtpm support to libxl

[Matthew Fioravante <matthew.fioravante@xxxxxxxxxx>]

On 10/02/2012 10:43 AM, Ian Campbell wrote:
> On Tue, 2012-10-02 at 15:31 +0100, Matthew Fioravante wrote:
>> On 10/02/2012 09:44 AM, Ian Campbell wrote:
>>> On Mon, 2012-10-01 at 19:40 +0100, Matthew Fioravante wrote:
>>>
>>>> Actually thinking about it more, uuids have to be attached to the
>>>> driver. If 2 vtpms connect to the manager, one could send the uuid of
>>>> the other and get access to someone elses secrets.
>>>>
>>>> TL;DR version
>>>>
>>>> uuids must remain part of the driver.
>>> What stops the driver lying about the UUID in a similar way?
>> The tpm backend driver (in the manager) will read the uuid from
>> xenstore. So as long as we trust xenstore ( and the entities who created
>> the entry, named libxl in dom0), we can trust the uuid and thus the
>> identity of the vtpm connecting to us.
> OK, why does that same argument not apply when the toolstack passes the
> UUID to the manager domain instead?
The other implementation I mentioned is where the toolstack would just
create a front/back pair and the vtpm itself would send its uuid. If the
toolstack can be fooled ( as simple as replacing the vtpm kernel image)
then it will connect a bogus vtpm to the manager which can then send the
uuid of any real vtpm and get at its secrets.

In essense, attaching the uuid to the driver is basically a convenient
way of having the toolstack domain tell the vtpm manager the identity of
the vtpm. If it wasn't attached to the driver there would have to be
some other daemon or special case code to do this.

This problem might go away later if/when we have measured boot of vtpms
but that is not currently implemented.


>
> Ian.
>
>

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel