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. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users
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
Thanks Daniel,
When I run
sudo xl create -c vtpmmgr-stubdom.cfg
I receive the following error:
Parsing config from vtpmmgr-stubdom.cfg
Daemon running with PID 29361
Xen Minimal OS!
start_info: 0xa2000(VA)
nr_pages: 0x1000
shared_inf: 0x83ad7000(MA)
pt_base: 0xa5000(VA)
nr_pt_frames: 0x5
mfn_list: 0x9a000(VA)
mod_start: 0x0(VA)
mod_len: 0
flags: 0x0
cmd_line:
stack: 0x597e0-0x797e0
MM: Init
_text: 0x0(VA)
_etext: 0x39357(VA)
_erodata: 0x45000(VA)
_edata: 0x47c40(VA)
stack start: 0x597e0(VA)
_end: 0x99e00(VA)
start_pfn: ad
max_pfn: 1000
Mapping memory range 0x400000 - 0x1000000
setting 0x0-0x45000 readonly
skipped 0x1000
MM: Initialise page allocator for b3000(b3000)-1000000(1000000)
MM: done
Demand map pfns at 1001000-2001001000.
Heap resides at 2001002000-4001002000.
Initialising timer interface
Initialising console ... done.
gnttab_table mapped at 0x1001000.
Initialising scheduler
Thread "Idle": pointer: 0x2001002050, stack: 0xd0000
Thread "xenstore": pointer: 0x2001002800, stack: 0xe0000
xenbus initialised on irq 1 mfn 0x2302d8
Thread "shutdown": pointer: 0x2001002fb0, stack: 0xf0000
Dummy main: start_info=0x798e0
Thread "main": pointer: 0x2001003760, stack: 0x100000
"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 **********
backend at /local/domain/0/backend/qdisk/22/768
Failed to read /local/domain/0/backend/qdisk/22/768/feature-barrier.
32768 sectors of 512 bytes
**************************
blk_open(device/vbd/768) -> 3
============= Init TPM BACK ===============Thread "tpmback-listener":
pointer: 0x20010043f0, stack: 0xf0000
============= Init TPM TIS Driver =============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?
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@tycho.nsa.gov>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@lists.xen.org
http://lists.xen.org/xen-users
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=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@tycho.nsa.gov>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 >> >-- Daniel De Graaf National Security Agency
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! 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@tycho.nsa.gov>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=** > 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@tycho.nsa.gov >> >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 >>> >>> >> > > -- > Daniel De Graaf > National Security Agency >_______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users
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@tycho.nsa.gov>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=** >> 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@tycho.nsa.gov >>>> 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 >>>> >>>> >>> >> >> -- >> Daniel De Graaf >> National Security Agency >> >-- Daniel De Graaf National Security Agency
>>> On 15.10.13 at 19:09, Daniel De Graaf <dgdegra@tycho.nsa.gov> 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=07344c0f33be13bf9232a113 > 681ef9087557f706 > > 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.A ping means that you previously asked for this to be backported, but I don''t think you ever did. Considering that your first try at fixing this was broken, I would also not have considered this as a candidate on my own (in fear of further issues)... Jan Jan
>>> On 15.10.13 at 23:33, Emma Allison <em.allison.88@gmail.com> wrote: > 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?Please drop me from further communication on the vTPM aspects of this problem. Jan
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. On Tue, Oct 15, 2013 at 6:10 PM, Daniel De Graaf <dgdegra@tycho.nsa.gov>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@tycho.nsa.gov >> >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@tycho.nsa.gov >>>> >>>>> 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 >>>>> >>>>> >>>>> >>>> >>> -- >>> Daniel De Graaf >>> National Security Agency >>> >>> >> > > -- > Daniel De Graaf > National Security Agency >_______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users
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@tycho.nsa.gov>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@tycho.nsa.gov >>>> 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@tycho.nsa.gov >>>>> >>>>>> 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
On 10/16/2013 05:10 AM, Jan Beulich wrote:>>>> On 15.10.13 at 19:09, Daniel De Graaf <dgdegra@tycho.nsa.gov> 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=07344c0f33be13bf9232a113 >> 681ef9087557f706 >> >> 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. > > A ping means that you previously asked for this to be backported, > but I don''t think you ever did. Considering that your first try at > fixing this was broken, I would also not have considered this as a > candidate on my own (in fear of further issues)... >Yes, looking back I should have explicitly requested the backport after it was committed to unstable and tested. Thanks for applying the patch now that it has been confirmed to work. -- Daniel De Graaf National Security Agency
Daniel, does Xen implementation of vTPM is similar to what is proposed by vTPM paper (IBM Research)? Please correct me if I am wrong, as you are professional in this area: Assume that we use hardware AIKs for virtual machines. For hardware PCRs, we use TPM_Quote with arguments to be PCR indexes, and possibly external data such as nonce. For vPCRs, it can be similar to signing virtual EKs by hardware AIKs (as in the paper.) That is, supplying vPCRs to be signed as external data. I guess the output of the two signatures should look different. In that case, it is not possible to forge real PCR signature. On Wed, Oct 16, 2013 at 1:36 PM, Daniel De Graaf <dgdegra@tycho.nsa.gov>wrote:> 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@tycho.nsa.gov >> >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@tycho.nsa.gov >>>> >>>>> 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=**> >>>>> <h**ttp://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***<http://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@tycho.nsa.gov >>>>>> >>>>>> 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@lists.xen.org http://lists.xen.org/xen-users
On 10/16/2013 04:30 PM, Emma Allison wrote:> Daniel, does Xen implementation of vTPM is similar to what is proposed by > vTPM paper (IBM Research)? > > > Please correct me if I am wrong, as you are professional in this area: > > Assume that we use hardware AIKs for virtual machines. > > For hardware PCRs, we use TPM_Quote with arguments to be PCR indexes, and > possibly external data such as nonce. For vPCRs, it can be similar to > signing virtual EKs by hardware AIKs (as in the paper.) That is, supplying > vPCRs to be signed as external data. I guess the output of the two > signatures should look different. In that case, it is not possible to forge > real PCR signature. >While I don''t have the paper in front of me, this sounds like the same method (which is sometimes termed quote-signing). It is also usable to sign virtual EKs in order to assist in the creation of the EK credentials for the vTPM.> On Wed, Oct 16, 2013 at 1:36 PM, Daniel De Graaf <dgdegra@tycho.nsa.gov>wrote: > >> 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@tycho.nsa.gov >>>> 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@tycho.nsa.gov >>>>> >>>>>> 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=**> >>>>>> <h**ttp://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***<http://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@tycho.nsa.gov >>>>>>> >>>>>>> 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 >> >-- Daniel De Graaf National Security Agency