[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-users] Problem in building vTPM manager



On 10/16/2013 11:25 AM, Emma Allison wrote:
Good point Daniel, it is working now! Thanks.

A question: is it possible that vTPM manager directly uses AIKs in hardware
TPM instead of generating and signing them? I can understand that it would
be a performance issue, as TPM chip at the moment is not so powerful to
handle many requests.

It is not possible to use a hardware TPM's AIK to sign a vTPM's PCRs: the
AIKs cannot be used to make such a signature, as this would give the ability
to forge PCR values in a real signature. The closest that could be done is
to create TPM_Sign keys in the physical TPM for the virtual TPM keys, but
this adds little additional security since these keys cannot be bound to
or report on any virtual PCRs - the only thing you gain is that the keys
can't be copied.

An updated TPM Manager is being created that allows a physical TPM's AIK to
quote-sign physical and virtual PCRs for a complete picture of a guest's
trusted computing base. It's more of alpha quality at the moment and has not
yet been posted to the mailing lists, but this will eventually let you do
something similar to what you asked.


On Tue, Oct 15, 2013 at 6:10 PM, Daniel De Graaf <dgdegra@xxxxxxxxxxxxx>wrote:

On 10/15/2013 05:33 PM, Emma Allison wrote:

Thanks,

By applying the patch, that error is fixed now. I am still unable to
create
vTPM manager, as I get the following error. Have I missed something, or a
have done a mistake?

MM: Initialise page allocator for 4a3000(4a3000)-40000000(**40000000)
MM: done
Demand map pfns at 40001000-2040001000.
Heap resides at 2040002000-4040002000.
Initialising timer interface
Initialising console ... done.
gnttab_table mapped at 0x40001000.
Initialising scheduler
Thread "Idle": pointer: 0x2040002050, stack: 0x6c0000
Thread "xenstore": pointer: 0x2040002800, stack: 0x6d0000
xenbus initialised on irq 1 mfn 0x2f5305
Thread "shutdown": pointer: 0x2040002fb0, stack: 0x6e0000
Dummy main: start_info=0x798e0
Thread "main": pointer: 0x2040003760, stack: 0x6f0000
"main"
Shutting down ()
Shutdown requested: 3
Thread "shutdown" exited.
INFO[VTPM]: Starting vTPM manager domain
INFO[VTPM]: Option: Using tpm_tis driver
******************* BLKFRONT for device/vbd/768 **********


Failed to read device/vbd/768/backend-id.
Abort transaction writing ring-ref
ERROR[VTPM]: Unable to initialize storage subsystem!


There seems to be something wrong with the disk you assigned to the
manager; check for errors in the qemu log or see what is actually in
xenstore at that path (possibly using xl create -p). If qdisk won't
work for you, you could try using a block device backend to use the
in-kernel blkback (this works best with LVM, though losetup works
for testing). Be sure you specify "hda" not "sda" or "xvda" for vdev.

  Tpmback:Info Shutting down tpm backend
close(-1)
close(-1): Bad descriptor
close(-1)
close(-1): Bad descriptor
INFO[VTPM]: VTPM Manager stopped.
ERROR[VTPM]: Unable to initialize vtpmmgr domain!
close(0)
close(1)
close(2)
main returned -1
Do_exit called!
base is 0x6ffef8 caller is 0x1f24d
base is 0x6fff18 caller is 0x1fb07
base is 0x6fff48 caller is 0x28f6b
base is 0x6fff68 caller is 0x1fa87
base is 0x6fffe8 caller is 0x343b



On Tue, Oct 15, 2013 at 1:09 PM, Daniel De Graaf <dgdegra@xxxxxxxxxxxxx
wrote:

  On 10/11/2013 07:09 PM, Emma Allison wrote:

  Thanks Daniel,

When I run

sudo xl create -c vtpmmgr-stubdom.cfg

I receive the following error:

   [...]


   IOMEM Machine Base Address: FED40000

Enabled Localities: 0
Map 1 (fed40, ...) at 0x1006000 failed: -1.
Do_exit called!
base is 0x10fcb8 caller is 0x1f24d
base is 0x10fcd8 caller is 0x27658
base is 0x10fd88 caller is 0x2772b
base is 0x10fde8 caller is 0x26bf6
base is 0x10fe28 caller is 0x26c1e
base is 0x10fe38 caller is 0x1ba94
base is 0x10fe78 caller is 0x6f84
base is 0x10ff38 caller is 0x353c
base is 0x10ff68 caller is 0x1fa80
base is 0x10ffe8 caller is 0x343b

How I can solve this problem?


This is fixed by a hypervisor patch in xen-unstable:

http://xenbits.xen.org/gitweb/****?p=xen.git;a=commit;h=**<http://xenbits.xen.org/gitweb/**?p=xen.git;a=commit;h=**>
07344c0f33be13bf9232a113681ef9****087557f706<http://xenbits.**
xen.org/gitweb/?p=xen.git;a=**commit;h=**07344c0f33be13bf9232a113681ef9*
*087557f706<http://xenbits.xen.org/gitweb/?p=xen.git;a=commit;h=07344c0f33be13bf9232a113681ef9087557f706>



That patch has not yet been applied to the 4.3 tree, however you can
apply
it yourself. I'm adding Jan to CC as a ping to backport this patch; a
report on if the patch fixes the issue may also be helpful here.


   Note: I had tcsd running on dom0, which I killed before I run the
command.



On Fri, Sep 27, 2013 at 2:39 PM, Daniel De Graaf <dgdegra@xxxxxxxxxxxxx

wrote:


   On 09/27/2013 02:17 PM, Emma Allison wrote:


   Hi,


I use Xen 4.3.0. When I build the source using "make world", the file
vtpmmgr-stubdom.gz is not created. Based on the documentation, manager
config file requires the path to this file to be specified.

Is there any flag that I have to set, or any trick for building vTPM
manager?

Thanks.


  You likely need to install cmake and then rerun ./configure. You can
also
run "./configure --enable-vtpmmgr-stubdom" to make missing dependencies
fatal.


--
Daniel De Graaf
National Security Agency

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.