Hi, I‘m trying to install vTPM based on Xen-4.2.2, linux-kernel 3.9.1 (Dom0) and TPM emulator. However, I cannot find the TPM backed driver in this version of Dom0 linux kernel. There is no CONFIG_XEN_TPMDEV_BACKEND in the kernel config file. The config file for Dom0 is attached. Maybe it provides some useful information. So, how to install a Xen TPM backend driver in the Dom0 linux-kernel. Thank you very much. -- Best Regards, Bei Guan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
On 05/22/2013 09:56 AM, Bei Guan wrote:> Hi, > > I‘m trying to install vTPM based on Xen-4.2.2, linux-kernel 3.9.1 (Dom0) > and TPM emulator. However, I cannot find the TPM backed driver in this > version of Dom0 linux kernel. There is no CONFIG_XEN_TPMDEV_BACKEND in the > kernel config file. The config file for Dom0 is attached. Maybe it provides > some useful information. > > So, how to install a Xen TPM backend driver in the Dom0 linux-kernel. > Thank you very much.Unless you need to use Xen 4.2 for some reason, I would suggest using the vTPM in Xen 4.3, as it works more reliably. The Linux TPM backend driver is only available in the old 2.6.18 branch; the current preferred setup for vTPMs is to grant the vTPM Manager stub domain direct hardware access to the TPM and to avoid using the hardware TPM in dom0. The Linux frontend TPM driver for Xen has been posted recently on the mailing list; this version works with the vTPM from Xen 4.3. The vTPM from Xen 4.2 will only work with the frontend driver from 2.6.18. -- Daniel De Graaf National Security Agency
On Tue, May 28, 2013 at 9:00 PM, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:> On 05/22/2013 09:56 AM, Bei Guan wrote: >> >> Hi, >> >> I‘m trying to install vTPM based on Xen-4.2.2, linux-kernel 3.9.1 (Dom0) >> and TPM emulator. However, I cannot find the TPM backed driver in this >> version of Dom0 linux kernel. There is no CONFIG_XEN_TPMDEV_BACKEND in the >> kernel config file. The config file for Dom0 is attached. Maybe it >> provides >> some useful information. >> >> So, how to install a Xen TPM backend driver in the Dom0 linux-kernel. >> Thank you very much. > > > Unless you need to use Xen 4.2 for some reason, I would suggest using the > vTPM in Xen 4.3, as it works more reliably.You do realize 4.3 hasn''t actually been released yet, right? :-) Bei Guan: We expect 4.3 to be released in the next month or so, so you may wish to wait. -George
Thank you for all your reply. I''ll try vTPM on Xen-4.3-unstable. However, I don''t have a physical TPM on my PC. Can I use the TPM emulator in Xen-4.3-unstable now? Thank you very much, Bei Guan 2013/5/29 George Dunlap <George.Dunlap@eu.citrix.com>> On Tue, May 28, 2013 at 9:00 PM, Daniel De Graaf <dgdegra@tycho.nsa.gov> > wrote: > > On 05/22/2013 09:56 AM, Bei Guan wrote: > >> > >> Hi, > >> > >> I‘m trying to install vTPM based on Xen-4.2.2, linux-kernel 3.9.1 (Dom0) > >> and TPM emulator. However, I cannot find the TPM backed driver in this > >> version of Dom0 linux kernel. There is no CONFIG_XEN_TPMDEV_BACKEND in > the > >> kernel config file. The config file for Dom0 is attached. Maybe it > >> provides > >> some useful information. > >> > >> So, how to install a Xen TPM backend driver in the Dom0 linux-kernel. > >> Thank you very much. > > > > > > Unless you need to use Xen 4.2 for some reason, I would suggest using the > > vTPM in Xen 4.3, as it works more reliably. > > You do realize 4.3 hasn''t actually been released yet, right? :-) > > Bei Guan: We expect 4.3 to be released in the next month or so, so you > may wish to wait. > > -George >-- Best Regards, Bei Guan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
On 05/29/2013 05:56 AM, George Dunlap wrote:> On Tue, May 28, 2013 at 9:00 PM, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote: >> On 05/22/2013 09:56 AM, Bei Guan wrote: >>> >>> Hi, >>> >>> I‘m trying to install vTPM based on Xen-4.2.2, linux-kernel 3.9.1 (Dom0) >>> and TPM emulator. However, I cannot find the TPM backed driver in this >>> version of Dom0 linux kernel. There is no CONFIG_XEN_TPMDEV_BACKEND in the >>> kernel config file. The config file for Dom0 is attached. Maybe it >>> provides >>> some useful information. >>> >>> So, how to install a Xen TPM backend driver in the Dom0 linux-kernel. >>> Thank you very much. >> >> >> Unless you need to use Xen 4.2 for some reason, I would suggest using the >> vTPM in Xen 4.3, as it works more reliably. > > You do realize 4.3 hasn''t actually been released yet, right? :-)I assume anyone posting on xen-devel is willing to use pre-release software - especially as 4.3 is in a later RC now.> Bei Guan: We expect 4.3 to be released in the next month or so, so you > may wish to wait. > > -George >-- Daniel De Graaf National Security Agency
On 05/29/2013 07:23 AM, Bei Guan wrote:> Thank you for all your reply. I''ll try vTPM on Xen-4.3-unstable. > > However, I don''t have a physical TPM on my PC. Can I use the TPM emulator > in Xen-4.3-unstable now? > > Thank you very much, > Bei Guan >The current TPM Manager requires a physical TPM to be present. While you could make things work without one, it would require patching either the vTPM or vTPM Manager domains with an alternate sealing mechanism for the long-term keys and source of random numbers.> > 2013/5/29 George Dunlap <George.Dunlap@eu.citrix.com> > >> On Tue, May 28, 2013 at 9:00 PM, Daniel De Graaf <dgdegra@tycho.nsa.gov> >> wrote: >>> On 05/22/2013 09:56 AM, Bei Guan wrote: >>>> >>>> Hi, >>>> >>>> I‘m trying to install vTPM based on Xen-4.2.2, linux-kernel 3.9.1 (Dom0) >>>> and TPM emulator. However, I cannot find the TPM backed driver in this >>>> version of Dom0 linux kernel. There is no CONFIG_XEN_TPMDEV_BACKEND in >> the >>>> kernel config file. The config file for Dom0 is attached. Maybe it >>>> provides >>>> some useful information. >>>> >>>> So, how to install a Xen TPM backend driver in the Dom0 linux-kernel. >>>> Thank you very much. >>> >>> >>> Unless you need to use Xen 4.2 for some reason, I would suggest using the >>> vTPM in Xen 4.3, as it works more reliably. >> >> You do realize 4.3 hasn''t actually been released yet, right? :-) >> >> Bei Guan: We expect 4.3 to be released in the next month or so, so you >> may wish to wait. >> >> -George >> > > >-- Daniel De Graaf National Security Agency
On 29/05/13 12:56, Daniel De Graaf wrote:> On 05/29/2013 05:56 AM, George Dunlap wrote: >> On Tue, May 28, 2013 at 9:00 PM, Daniel De Graaf >> <dgdegra@tycho.nsa.gov> wrote: >>> On 05/22/2013 09:56 AM, Bei Guan wrote: >>>> >>>> Hi, >>>> >>>> I‘m trying to install vTPM based on Xen-4.2.2, linux-kernel 3.9.1 >>>> (Dom0) >>>> and TPM emulator. However, I cannot find the TPM backed driver in this >>>> version of Dom0 linux kernel. There is no CONFIG_XEN_TPMDEV_BACKEND >>>> in the >>>> kernel config file. The config file for Dom0 is attached. Maybe it >>>> provides >>>> some useful information. >>>> >>>> So, how to install a Xen TPM backend driver in the Dom0 linux-kernel. >>>> Thank you very much. >>> >>> >>> Unless you need to use Xen 4.2 for some reason, I would suggest >>> using the >>> vTPM in Xen 4.3, as it works more reliably. >> >> You do realize 4.3 hasn''t actually been released yet, right? :-) > > I assume anyone posting on xen-devel is willing to use pre-release > software - especially as 4.3 is in a later RC now.On the contrary, this is where users are meant to report bugs and ask technical questions that can''t be answered by the people on xen-users. Where else was Bei Guan supposed to ask for help getting vTPM working in 4.2? -George
Hi, I compile the stubdom when I install xen-4.3-unstable, but there is an error about the newlibc linked library. Do you have any ideas to solved this problem? The output of "make install" is attached below. According to the functions "__ctype_ptr" and "__getreent" in the output that are very very basic ones, maybe the problem is something related to the environment. However, with several days'' work, I still have no idea. If this problem cannot be solved, can I just make "newlib" not to compile the doc? Maybe makedoc is not so important. But, how to do it? Any suggestions is appreciated. Thank you very much. # make install-stubdom ... gcc -g -O2 -o makedoc makedoc.o makedoc.o: In function `at'': /root/Xen/xen-4.3-unstable/stubdom/newlib-x86_64/x86_64-xen-elf/newlib /doc/../../../../newlib-1.16.0/newlib/doc/makedoc.c:125: undefined reference to `__ctype_ptr'' makedoc.o: In function `nextword'': /root/Xen/xen-4.3-unstable/stubdom/newlib-x86_64/x86_64-xen-elf/newlib /doc/../../../../newlib-1.16.0/newlib/doc/makedoc.c:1067: undefined reference to `__ctype_ptr'' makedoc.o: In function `quickref'': /root/Xen/xen-4.3-unstable/stubdom/newlib-x86_64/x86_64-xen-elf/newlib /doc/../../../../newlib-1.16.0/newlib/doc/makedoc.c:470: undefined reference to `__getreent'' /root/Xen/xen-4.3-unstable/stubdom/newlib-x86_64/x86_64-xen-elf/newlib /doc/../../../../newlib-1.16.0/newlib/doc/makedoc.c:477: undefined reference to `__getreent'' makedoc.o: In function `kill_bogus_lines'': /root/Xen/xen-4.3-unstable/stubdom/newlib-x86_64/x86_64-xen-elf/newlib /doc/../../../../newlib-1.16.0/newlib/doc/makedoc.c:867: undefined reference to `__ctype_ptr'' makedoc.o: In function `bulletize'': /root/Xen/xen-4.3-unstable/stubdom/newlib-x86_64/x86_64-xen-elf/newlib /doc/../../../../newlib-1.16.0/newlib/doc/makedoc.c:679: undefined reference to `__ctype_ptr'' /root/Xen/xen-4.3-unstable/stubdom/newlib-x86_64/x86_64-xen-elf/newlib /doc/../../../../newlib-1.16.0/newlib/doc/makedoc.c:679: undefined reference to `__ctype_ptr'' makedoc.o: In function `do_fancy_stuff'': /root/Xen/xen-4.3-unstable/stubdom/newlib-x86_64/x86_64-xen-elf/newlib /doc/../../../../newlib-1.16.0/newlib/doc/makedoc.c:735: undefined reference to `__ctype_ptr'' /root/Xen/xen-4.3-unstable/stubdom/newlib-x86_64/x86_64-xen-elf/newlib /doc/../../../../newlib-1.16.0/newlib/doc/makedoc.c:744: undefined reference to `__ctype_ptr'' makedoc.o:/root/Xen/xen-4.3-unstable/stubdom/newlib-x86_64/x86_64-xen-elf/ newlib/doc/../../../../newlib-1.16.0/newlib/doc/makedoc.c:378: more undefined references to `__ctype_ptr'' follow makedoc.o: In function `lookup_word'': /root/Xen/xen-4.3-unstable/stubdom/newlib-x86_64/x86_64-xen-elf/newlib /doc/../../../../newlib-1.16.0/newlib/doc/makedoc.c:1151: undefined reference to `__getreent'' makedoc.o: In function `compile'': /root/Xen/xen-4.3-unstable/stubdom/newlib-x86_64/x86_64-xen-elf/newlib /doc/../../../../newlib-1.16.0/newlib/doc/makedoc.c:1332: undefined reference to `__getreent'' makedoc.o: In function `main'': /root/Xen/xen-4.3-unstable/stubdom/newlib-x86_64/x86_64-xen-elf/newlib /doc/../../../../newlib-1.16.0/newlib/doc/makedoc.c:1431: undefined reference to `__getreent'' makedoc.o: In function `write_buffer'': /root/Xen/xen-4.3-unstable/stubdom/newlib-x86_64/x86_64-xen-elf/newlib /doc/../../../../newlib-1.16.0/newlib/doc/makedoc.c:103: undefined reference to `__getreent'' makedoc.o: In function `remove_noncomments'': /root/Xen/xen-4.3-unstable/stubdom/newlib-x86_64/x86_64-xen-elf/newlib /doc/../../../../newlib-1.16.0/newlib/doc/makedoc.c:311: undefined reference to `__ctype_ptr'' /root/Xen/xen-4.3-unstable/stubdom/newlib-x86_64/x86_64-xen-elf/newlib /doc/../../../../newlib-1.16.0/newlib/doc/makedoc.c:328: undefined reference to `__ctype_ptr'' makedoc.o: In function `perform'': /root/Xen/xen-4.3-unstable/stubdom/newlib-x86_64/x86_64-xen-elf/newlib /doc/../../../../newlib-1.16.0/newlib/doc/makedoc.c:1185: undefined reference to `__getreent'' makedoc.o: In function `main'': /root/Xen/xen-4.3-unstable/stubdom/newlib-x86_64/x86_64-xen-elf/newlib /doc/../../../../newlib-1.16.0/newlib/doc/makedoc.c:1446: undefined reference to `__getreent'' collect2: ld returned 1 exit status make[5]: *** [makedoc] Error 1 make[5]: Leaving directory `/root/Xen/xen-4.3-unstable/stubdom/newlib -x86_64/x86_64-xen-elf/newlib/doc'' make[4]: *** [all-recursive] Error 1 make[4]: Leaving directory `/root/Xen/xen-4.3-unstable/stubdom/newlib -x86_64/x86_64-xen-elf/newlib'' make[3]: *** [all] Error 2 make[3]: Leaving directory `/root/Xen/xen-4.3-unstable/stubdom/newlib -x86_64/x86_64-xen-elf/newlib'' make[2]: *** [all-target-newlib] Error 2 make[2]: Leaving directory `/root/Xen/xen-4.3-unstable/stubdom/newlib -x86_64'' make[1]: *** [all] Error 2 make[1]: Leaving directory `/root/Xen/xen-4.3-unstable/stubdom/newlib -x86_64'' make: *** [cross-root-x86_64/x86_64-xen-elf/lib/libc.a] Error 2 2013/5/29 George Dunlap <george.dunlap@eu.citrix.com>> On 29/05/13 12:56, Daniel De Graaf wrote: > >> On 05/29/2013 05:56 AM, George Dunlap wrote: >> >>> On Tue, May 28, 2013 at 9:00 PM, Daniel De Graaf <dgdegra@tycho.nsa.gov> >>> wrote: >>> >>>> On 05/22/2013 09:56 AM, Bei Guan wrote: >>>> >>>>> >>>>> Hi, >>>>> >>>>> I‘m trying to install vTPM based on Xen-4.2.2, linux-kernel 3.9.1 >>>>> (Dom0) >>>>> and TPM emulator. However, I cannot find the TPM backed driver in this >>>>> version of Dom0 linux kernel. There is no CONFIG_XEN_TPMDEV_BACKEND in >>>>> the >>>>> kernel config file. The config file for Dom0 is attached. Maybe it >>>>> provides >>>>> some useful information. >>>>> >>>>> So, how to install a Xen TPM backend driver in the Dom0 linux-kernel. >>>>> Thank you very much. >>>>> >>>> >>>> >>>> Unless you need to use Xen 4.2 for some reason, I would suggest using >>>> the >>>> vTPM in Xen 4.3, as it works more reliably. >>>> >>> >>> You do realize 4.3 hasn''t actually been released yet, right? :-) >>> >> >> I assume anyone posting on xen-devel is willing to use pre-release >> software - especially as 4.3 is in a later RC now. >> > > On the contrary, this is where users are meant to report bugs and ask > technical questions that can''t be answered by the people on xen-users. > Where else was Bei Guan supposed to ask for help getting vTPM working in > 4.2? > > -George >-- Best Regards, Bei Guan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Additional information: My environment is Centos6.3 64bit and the my gcc version is like this: [root@localhost newlib-x86_64]# gcc -v Using built-in specs. Target: x86_64-redhat-linux Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla--enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk --disable-dssi --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre --enable-libgcj-multifile --enable-java-maintainer-mode --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib --with-ppl --with-cloog --with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux Thread model: posix gcc version 4.4.7 20120313 (Red Hat 4.4.7-3) (GCC) Thank you. 2013/6/3 Bei Guan <gbtju85@gmail.com>> Hi, > > I compile the stubdom when I install xen-4.3-unstable, but there is an > error about the newlibc linked library. Do you have any ideas to solved > this problem? The output of "make install" is attached below. > > According to the functions "__ctype_ptr" and "__getreent" in the output > that are very very basic ones, maybe the problem is something related to > the environment. However, with several days'' work, I still have no idea. > If this problem cannot be solved, can I just make "newlib" not to compile > the doc? Maybe makedoc is not so important. But, how to do it? > Any suggestions is appreciated. Thank you very much. > > > # make install-stubdom > ... > gcc -g -O2 -o makedoc makedoc.o > makedoc.o: In function `at'': > /root/Xen/xen-4.3-unstable/stubdom/newlib-x86_64/x86_64-xen-elf/newlib > /doc/../../../../newlib-1.16.0/newlib/doc/makedoc.c:125: undefined > reference to `__ctype_ptr'' > makedoc.o: In function `nextword'': > /root/Xen/xen-4.3-unstable/stubdom/newlib-x86_64/x86_64-xen-elf/newlib > /doc/../../../../newlib-1.16.0/newlib/doc/makedoc.c:1067: undefined > reference to `__ctype_ptr'' > makedoc.o: In function `quickref'': > /root/Xen/xen-4.3-unstable/stubdom/newlib-x86_64/x86_64-xen-elf/newlib > /doc/../../../../newlib-1.16.0/newlib/doc/makedoc.c:470: undefined > reference to `__getreent'' > /root/Xen/xen-4.3-unstable/stubdom/newlib-x86_64/x86_64-xen-elf/newlib > /doc/../../../../newlib-1.16.0/newlib/doc/makedoc.c:477: undefined > reference to `__getreent'' > makedoc.o: In function `kill_bogus_lines'': > /root/Xen/xen-4.3-unstable/stubdom/newlib-x86_64/x86_64-xen-elf/newlib > /doc/../../../../newlib-1.16.0/newlib/doc/makedoc.c:867: undefined > reference to `__ctype_ptr'' > makedoc.o: In function `bulletize'': > /root/Xen/xen-4.3-unstable/stubdom/newlib-x86_64/x86_64-xen-elf/newlib > /doc/../../../../newlib-1.16.0/newlib/doc/makedoc.c:679: undefined > reference to `__ctype_ptr'' > /root/Xen/xen-4.3-unstable/stubdom/newlib-x86_64/x86_64-xen-elf/newlib > /doc/../../../../newlib-1.16.0/newlib/doc/makedoc.c:679: undefined > reference to `__ctype_ptr'' > makedoc.o: In function `do_fancy_stuff'': > /root/Xen/xen-4.3-unstable/stubdom/newlib-x86_64/x86_64-xen-elf/newlib > /doc/../../../../newlib-1.16.0/newlib/doc/makedoc.c:735: undefined > reference to `__ctype_ptr'' > /root/Xen/xen-4.3-unstable/stubdom/newlib-x86_64/x86_64-xen-elf/newlib > /doc/../../../../newlib-1.16.0/newlib/doc/makedoc.c:744: undefined > reference to `__ctype_ptr'' > makedoc.o:/root/Xen/xen-4.3-unstable/stubdom/newlib-x86_64/x86_64-xen-elf/ > newlib/doc/../../../../newlib-1.16.0/newlib/doc/makedoc.c:378: more > undefined references to `__ctype_ptr'' follow > makedoc.o: In function `lookup_word'': > /root/Xen/xen-4.3-unstable/stubdom/newlib-x86_64/x86_64-xen-elf/newlib > /doc/../../../../newlib-1.16.0/newlib/doc/makedoc.c:1151: undefined > reference to `__getreent'' > makedoc.o: In function `compile'': > /root/Xen/xen-4.3-unstable/stubdom/newlib-x86_64/x86_64-xen-elf/newlib > /doc/../../../../newlib-1.16.0/newlib/doc/makedoc.c:1332: undefined > reference to `__getreent'' > makedoc.o: In function `main'': > /root/Xen/xen-4.3-unstable/stubdom/newlib-x86_64/x86_64-xen-elf/newlib > /doc/../../../../newlib-1.16.0/newlib/doc/makedoc.c:1431: undefined > reference to `__getreent'' > makedoc.o: In function `write_buffer'': > /root/Xen/xen-4.3-unstable/stubdom/newlib-x86_64/x86_64-xen-elf/newlib > /doc/../../../../newlib-1.16.0/newlib/doc/makedoc.c:103: undefined > reference to `__getreent'' > makedoc.o: In function `remove_noncomments'': > /root/Xen/xen-4.3-unstable/stubdom/newlib-x86_64/x86_64-xen-elf/newlib > /doc/../../../../newlib-1.16.0/newlib/doc/makedoc.c:311: undefined > reference to `__ctype_ptr'' > /root/Xen/xen-4.3-unstable/stubdom/newlib-x86_64/x86_64-xen-elf/newlib > /doc/../../../../newlib-1.16.0/newlib/doc/makedoc.c:328: undefined > reference to `__ctype_ptr'' > makedoc.o: In function `perform'': > /root/Xen/xen-4.3-unstable/stubdom/newlib-x86_64/x86_64-xen-elf/newlib > /doc/../../../../newlib-1.16.0/newlib/doc/makedoc.c:1185: undefined > reference to `__getreent'' > makedoc.o: In function `main'': > /root/Xen/xen-4.3-unstable/stubdom/newlib-x86_64/x86_64-xen-elf/newlib > /doc/../../../../newlib-1.16.0/newlib/doc/makedoc.c:1446: undefined > reference to `__getreent'' > collect2: ld returned 1 exit status > make[5]: *** [makedoc] Error 1 > make[5]: Leaving directory `/root/Xen/xen-4.3-unstable/stubdom/newlib > -x86_64/x86_64-xen-elf/newlib/doc'' > make[4]: *** [all-recursive] Error 1 > make[4]: Leaving directory `/root/Xen/xen-4.3-unstable/stubdom/newlib > -x86_64/x86_64-xen-elf/newlib'' > make[3]: *** [all] Error 2 > make[3]: Leaving directory `/root/Xen/xen-4.3-unstable/stubdom/newlib > -x86_64/x86_64-xen-elf/newlib'' > make[2]: *** [all-target-newlib] Error 2 > make[2]: Leaving directory `/root/Xen/xen-4.3-unstable/stubdom/newlib > -x86_64'' > make[1]: *** [all] Error 2 > make[1]: Leaving directory `/root/Xen/xen-4.3-unstable/stubdom/newlib > -x86_64'' > make: *** [cross-root-x86_64/x86_64-xen-elf/lib/libc.a] Error 2 > > > > > 2013/5/29 George Dunlap <george.dunlap@eu.citrix.com> > >> On 29/05/13 12:56, Daniel De Graaf wrote: >> >>> On 05/29/2013 05:56 AM, George Dunlap wrote: >>> >>>> On Tue, May 28, 2013 at 9:00 PM, Daniel De Graaf <dgdegra@tycho.nsa.gov> >>>> wrote: >>>> >>>>> On 05/22/2013 09:56 AM, Bei Guan wrote: >>>>> >>>>>> >>>>>> Hi, >>>>>> >>>>>> I‘m trying to install vTPM based on Xen-4.2.2, linux-kernel 3.9.1 >>>>>> (Dom0) >>>>>> and TPM emulator. However, I cannot find the TPM backed driver in this >>>>>> version of Dom0 linux kernel. There is no CONFIG_XEN_TPMDEV_BACKEND >>>>>> in the >>>>>> kernel config file. The config file for Dom0 is attached. Maybe it >>>>>> provides >>>>>> some useful information. >>>>>> >>>>>> So, how to install a Xen TPM backend driver in the Dom0 linux-kernel. >>>>>> Thank you very much. >>>>>> >>>>> >>>>> >>>>> Unless you need to use Xen 4.2 for some reason, I would suggest using >>>>> the >>>>> vTPM in Xen 4.3, as it works more reliably. >>>>> >>>> >>>> You do realize 4.3 hasn''t actually been released yet, right? :-) >>>> >>> >>> I assume anyone posting on xen-devel is willing to use pre-release >>> software - especially as 4.3 is in a later RC now. >>> >> >> On the contrary, this is where users are meant to report bugs and ask >> technical questions that can''t be answered by the people on xen-users. >> Where else was Bei Guan supposed to ask for help getting vTPM working in >> 4.2? >> >> -George >> > > > > -- > Best Regards, > Bei Guan >-- Best Regards, Bei Guan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
On 06/03/2013 03:45 AM, Bei Guan wrote:> Additional information: > > My environment is Centos6.3 64bit and the my gcc version is like this: > [root@localhost newlib-x86_64]# gcc -v > Using built-in specs. > Target: x86_64-redhat-linux > Configured with: ../configure --prefix=/usr --mandir=/usr/share/man > --infodir=/usr/share/info > --with-bugurl=http://bugzilla.redhat.com/bugzilla--enable-bootstrap > --enable-shared --enable-threads=posix > --enable-checking=release --with-system-zlib --enable-__cxa_atexit > --disable-libunwind-exceptions --enable-gnu-unique-object > --enable-languages=c,c++,objc,obj-c++,java,fortran,ada > --enable-java-awt=gtk --disable-dssi > --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre > --enable-libgcj-multifile --enable-java-maintainer-mode > --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib > --with-ppl --with-cloog --with-tune=generic --with-arch_32=i686 > --build=x86_64-redhat-linux > Thread model: posix > gcc version 4.4.7 20120313 (Red Hat 4.4.7-3) (GCC) > > Thank you. > > > > 2013/6/3 Bei Guan <gbtju85@gmail.com> > >> Hi, >> >> I compile the stubdom when I install xen-4.3-unstable, but there is an >> error about the newlibc linked library. Do you have any ideas to solved >> this problem? The output of "make install" is attached below. >> >> According to the functions "__ctype_ptr" and "__getreent" in the output >> that are very very basic ones, maybe the problem is something related to >> the environment. However, with several days'' work, I still have no idea. >> If this problem cannot be solved, can I just make "newlib" not to compile >> the doc? Maybe makedoc is not so important. But, how to do it? >> Any suggestions is appreciated. Thank you very much. >> >> >> # make install-stubdom >> ... >> gcc -g -O2 -o makedoc makedoc.o >> makedoc.o: In function `at'': >> /root/Xen/xen-4.3-unstable/stubdom/newlib-x86_64/x86_64-xen-elf/newlib >> /doc/../../../../newlib-1.16.0/newlib/doc/makedoc.c:125: undefined >> reference to `__ctype_ptr'' >> makedoc.o: In function `nextword'': >> /root/Xen/xen-4.3-unstable/stubdom/newlib-x86_64/x86_64-xen-elf/newlib >> /doc/../../../../newlib-1.16.0/newlib/doc/makedoc.c:1067: undefined >> reference to `__ctype_ptr'' >> makedoc.o: In function `quickref'': >> /root/Xen/xen-4.3-unstable/stubdom/newlib-x86_64/x86_64-xen-elf/newlib >> /doc/../../../../newlib-1.16.0/newlib/doc/makedoc.c:470: undefined >> reference to `__getreent'' >> /root/Xen/xen-4.3-unstable/stubdom/newlib-x86_64/x86_64-xen-elf/newlib >> /doc/../../../../newlib-1.16.0/newlib/doc/makedoc.c:477: undefined >> reference to `__getreent'' >> makedoc.o: In function `kill_bogus_lines'': >> /root/Xen/xen-4.3-unstable/stubdom/newlib-x86_64/x86_64-xen-elf/newlib >> /doc/../../../../newlib-1.16.0/newlib/doc/makedoc.c:867: undefined >> reference to `__ctype_ptr'' >> makedoc.o: In function `bulletize'': >> /root/Xen/xen-4.3-unstable/stubdom/newlib-x86_64/x86_64-xen-elf/newlib >> /doc/../../../../newlib-1.16.0/newlib/doc/makedoc.c:679: undefined >> reference to `__ctype_ptr'' >> /root/Xen/xen-4.3-unstable/stubdom/newlib-x86_64/x86_64-xen-elf/newlib >> /doc/../../../../newlib-1.16.0/newlib/doc/makedoc.c:679: undefined >> reference to `__ctype_ptr'' >> makedoc.o: In function `do_fancy_stuff'': >> /root/Xen/xen-4.3-unstable/stubdom/newlib-x86_64/x86_64-xen-elf/newlib >> /doc/../../../../newlib-1.16.0/newlib/doc/makedoc.c:735: undefined >> reference to `__ctype_ptr'' >> /root/Xen/xen-4.3-unstable/stubdom/newlib-x86_64/x86_64-xen-elf/newlib >> /doc/../../../../newlib-1.16.0/newlib/doc/makedoc.c:744: undefined >> reference to `__ctype_ptr'' >> makedoc.o:/root/Xen/xen-4.3-unstable/stubdom/newlib-x86_64/x86_64-xen-elf/ >> newlib/doc/../../../../newlib-1.16.0/newlib/doc/makedoc.c:378: more >> undefined references to `__ctype_ptr'' follow >> makedoc.o: In function `lookup_word'': >> /root/Xen/xen-4.3-unstable/stubdom/newlib-x86_64/x86_64-xen-elf/newlib >> /doc/../../../../newlib-1.16.0/newlib/doc/makedoc.c:1151: undefined >> reference to `__getreent'' >> makedoc.o: In function `compile'': >> /root/Xen/xen-4.3-unstable/stubdom/newlib-x86_64/x86_64-xen-elf/newlib >> /doc/../../../../newlib-1.16.0/newlib/doc/makedoc.c:1332: undefined >> reference to `__getreent'' >> makedoc.o: In function `main'': >> /root/Xen/xen-4.3-unstable/stubdom/newlib-x86_64/x86_64-xen-elf/newlib >> /doc/../../../../newlib-1.16.0/newlib/doc/makedoc.c:1431: undefined >> reference to `__getreent'' >> makedoc.o: In function `write_buffer'': >> /root/Xen/xen-4.3-unstable/stubdom/newlib-x86_64/x86_64-xen-elf/newlib >> /doc/../../../../newlib-1.16.0/newlib/doc/makedoc.c:103: undefined >> reference to `__getreent'' >> makedoc.o: In function `remove_noncomments'': >> /root/Xen/xen-4.3-unstable/stubdom/newlib-x86_64/x86_64-xen-elf/newlib >> /doc/../../../../newlib-1.16.0/newlib/doc/makedoc.c:311: undefined >> reference to `__ctype_ptr'' >> /root/Xen/xen-4.3-unstable/stubdom/newlib-x86_64/x86_64-xen-elf/newlib >> /doc/../../../../newlib-1.16.0/newlib/doc/makedoc.c:328: undefined >> reference to `__ctype_ptr'' >> makedoc.o: In function `perform'': >> /root/Xen/xen-4.3-unstable/stubdom/newlib-x86_64/x86_64-xen-elf/newlib >> /doc/../../../../newlib-1.16.0/newlib/doc/makedoc.c:1185: undefined >> reference to `__getreent'' >> makedoc.o: In function `main'': >> /root/Xen/xen-4.3-unstable/stubdom/newlib-x86_64/x86_64-xen-elf/newlib >> /doc/../../../../newlib-1.16.0/newlib/doc/makedoc.c:1446: undefined >> reference to `__getreent'' >> collect2: ld returned 1 exit status >> make[5]: *** [makedoc] Error 1 >> make[5]: Leaving directory `/root/Xen/xen-4.3-unstable/stubdom/newlib >> -x86_64/x86_64-xen-elf/newlib/doc'' >> make[4]: *** [all-recursive] Error 1 >> make[4]: Leaving directory `/root/Xen/xen-4.3-unstable/stubdom/newlib >> -x86_64/x86_64-xen-elf/newlib'' >> make[3]: *** [all] Error 2 >> make[3]: Leaving directory `/root/Xen/xen-4.3-unstable/stubdom/newlib >> -x86_64/x86_64-xen-elf/newlib'' >> make[2]: *** [all-target-newlib] Error 2 >> make[2]: Leaving directory `/root/Xen/xen-4.3-unstable/stubdom/newlib >> -x86_64'' >> make[1]: *** [all] Error 2 >> make[1]: Leaving directory `/root/Xen/xen-4.3-unstable/stubdom/newlib >> -x86_64'' >> make: *** [cross-root-x86_64/x86_64-xen-elf/lib/libc.a] Error 2 >> >>Your issue seems to be unrelated to the TPM code; newlib is also used in other stub domains. My Centos6.4 test system does not have this problem, although I don''t think the release matters - it''s likely a package you have installed that I do not. You may want to try cleaning out the entire stubdom directory (with rm) and force everything to re-unpack. -- Daniel De Graaf National Security Agency
2013/5/29 Daniel De Graaf <dgdegra@tycho.nsa.gov>> On 05/29/2013 07:23 AM, Bei Guan wrote: > >> Thank you for all your reply. I''ll try vTPM on Xen-4.3-unstable. >> >> However, I don''t have a physical TPM on my PC. Can I use the TPM emulator >> in Xen-4.3-unstable now? >> >> Thank you very much, >> Bei Guan >> >> > The current TPM Manager requires a physical TPM to be present. While > you could make things work without one, it would require patching > either the vTPM or vTPM Manager domains with an alternate sealing > mechanism for the long-term keys and source of random numbers. >Hi Daniel, I''m trying vTPM on Xen-4.3-unstable with a TPM emulator. However, I run into problems. Everything in stubdom seems to be compiled successfully except for the TPM emulator. I''m not sure how to make the TPM emulator work in Xen-4.3. Can you give me more detailed instructions? Such as which part of the code need to be modified, if necessary. And, how much the coding work need to do to make the TPM emulator work? I found there is a code file tpm_tis.c in mini-os/ and stubdom/ioemu/hw/ respectively. What''s the difference between them? Is the code stubdom/ioemu/hw/tpm_tis.c only for QEMU emulated TPM device? And, what''s the difference between mini-os/tpm_tis.c and drivers/char/tpm/tpm_tis.c in linux kernel? Thank you very much. -- Best Regards, Bei Guan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
On 06/04/2013 05:03 AM, Bei Guan wrote:> 2013/5/29 Daniel De Graaf <dgdegra@tycho.nsa.gov> > >> On 05/29/2013 07:23 AM, Bei Guan wrote: >> >>> Thank you for all your reply. I''ll try vTPM on Xen-4.3-unstable. >>> >>> However, I don''t have a physical TPM on my PC. Can I use the TPM emulator >>> in Xen-4.3-unstable now? >>> >>> Thank you very much, >>> Bei Guan >>> >>> >> The current TPM Manager requires a physical TPM to be present. While >> you could make things work without one, it would require patching >> either the vTPM or vTPM Manager domains with an alternate sealing >> mechanism for the long-term keys and source of random numbers. >> > > Hi Daniel, > > I''m trying vTPM on Xen-4.3-unstable with a TPM emulator. However, I run > into problems. > Everything in stubdom seems to be compiled successfully except for the TPM > emulator.I can''t help if I don''t know what the problems are. Some of the dependencies in stubdom may be broken if you got things half-compiled before they broke, so a clean tree could help. You also need cmake, but it sounds like you''ve gotten past that point.> I''m not sure how to make the TPM emulator work in Xen-4.3. Can you give me > more detailed instructions? Such as which part of the code need to be > modified, if necessary. And, how much the coding work need to do to make > the TPM emulator work?The TPM emulator (vtpm-stubdom) depends on the TPM Manager (vtpmmgr-stubdom) to store its encryption keys securely. The TPM Manager uses a physical TPM to secure its own storage. Without a physical TPM, this is not possible, so possible workarounds include removing the requirement to have a TPM manager from the vTPM domain (remove tpmfront references), or to modify the TPM manager to not use the physical TPM. In either case, you will need to find another source for random numbers, which is one thing the physical TPM is used for. Changing the vTPM would be simpler than changing the TPM manager; the code you need to change is ~1000 lines, but most of your changes will be removal of code.> I found there is a code file tpm_tis.c in mini-os/ and stubdom/ioemu/hw/ > respectively. What''s the difference between them? Is the code > stubdom/ioemu/hw/tpm_tis.c only for QEMU emulated TPM device? > And, what''s the difference between mini-os/tpm_tis.c and > drivers/char/tpm/tpm_tis.c in linux kernel? > > Thank you very much.The mini-os driver is derived from the one in the Linux kernel; they both interface with a hardware TPM. The QEMU code (ioemu/hw) emulates a hardware TPM based on qemu''s access to a Linux /dev/tpm0 device driver. With Linux stub domains, this device can be backed by the tpmfront driver connected to the vtpm stubdom. -- Daniel De Graaf National Security Agency
Thank you for your reply. I find out you previous TPM front patch that you posted several days ago at: http://xen.markmail.org/message/j6xyvmjlqocjxbbn?q=drivers/tpm:+add+xen+tpmfront+interface Is your patch only for a PV DomU? Can I use a linux hvm to apply your patch? If not, can you recommend a DomU (PV or HVM is ok) to use your patch? Thank you very much. 2013/6/4 Daniel De Graaf <dgdegra@tycho.nsa.gov>> On 06/04/2013 05:03 AM, Bei Guan wrote: > >> 2013/5/29 Daniel De Graaf <dgdegra@tycho.nsa.gov> >> >> On 05/29/2013 07:23 AM, Bei Guan wrote: >>> >>> Thank you for all your reply. I''ll try vTPM on Xen-4.3-unstable. >>>> >>>> However, I don''t have a physical TPM on my PC. Can I use the TPM >>>> emulator >>>> in Xen-4.3-unstable now? >>>> >>>> Thank you very much, >>>> Bei Guan >>>> >>>> >>>> The current TPM Manager requires a physical TPM to be present. While >>> you could make things work without one, it would require patching >>> either the vTPM or vTPM Manager domains with an alternate sealing >>> mechanism for the long-term keys and source of random numbers. >>> >>> >> Hi Daniel, >> >> I''m trying vTPM on Xen-4.3-unstable with a TPM emulator. However, I run >> into problems. >> Everything in stubdom seems to be compiled successfully except for the TPM >> emulator. >> > > I can''t help if I don''t know what the problems are. Some of the > dependencies > in stubdom may be broken if you got things half-compiled before they broke, > so a clean tree could help. You also need cmake, but it sounds like you''ve > gotten past that point. > > > I''m not sure how to make the TPM emulator work in Xen-4.3. Can you give me >> more detailed instructions? Such as which part of the code need to be >> modified, if necessary. And, how much the coding work need to do to make >> the TPM emulator work? >> > > The TPM emulator (vtpm-stubdom) depends on the TPM Manager > (vtpmmgr-stubdom) > to store its encryption keys securely. The TPM Manager uses a physical TPM > to secure its own storage. Without a physical TPM, this is not possible, so > possible workarounds include removing the requirement to have a TPM manager > from the vTPM domain (remove tpmfront references), or to modify the TPM > manager to not use the physical TPM. > > In either case, you will need to find another source for random numbers, > which is one thing the physical TPM is used for. Changing the vTPM would be > simpler than changing the TPM manager; the code you need to change is ~1000 > lines, but most of your changes will be removal of code. > > > I found there is a code file tpm_tis.c in mini-os/ and stubdom/ioemu/hw/ >> respectively. What''s the difference between them? Is the code >> stubdom/ioemu/hw/tpm_tis.c only for QEMU emulated TPM device? >> And, what''s the difference between mini-os/tpm_tis.c and >> drivers/char/tpm/tpm_tis.c in linux kernel? >> >> Thank you very much. >> > > The mini-os driver is derived from the one in the Linux kernel; they both > interface with a hardware TPM. The QEMU code (ioemu/hw) emulates a hardware > TPM based on qemu''s access to a Linux /dev/tpm0 device driver. With Linux > stub domains, this device can be backed by the tpmfront driver connected to > the vtpm stubdom. > > > -- > Daniel De Graaf > National Security Agency >-- Best Regards, Bei Guan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Can I apply your patch to the kernel linux-2.6.18-xen as a PV DomU? Thanks. 2013/6/5 Bei Guan <gbtju85@gmail.com>> Thank you for your reply. > I find out you previous TPM front patch that you posted several days ago > at: > > http://xen.markmail.org/message/j6xyvmjlqocjxbbn?q=drivers/tpm:+add+xen+tpmfront+interface > > Is your patch only for a PV DomU? Can I use a linux hvm to apply your > patch? > If not, can you recommend a DomU (PV or HVM is ok) to use your patch? > Thank you very much. > > > > > 2013/6/4 Daniel De Graaf <dgdegra@tycho.nsa.gov> > >> On 06/04/2013 05:03 AM, Bei Guan wrote: >> >>> 2013/5/29 Daniel De Graaf <dgdegra@tycho.nsa.gov> >>> >>> On 05/29/2013 07:23 AM, Bei Guan wrote: >>>> >>>> Thank you for all your reply. I''ll try vTPM on Xen-4.3-unstable. >>>>> >>>>> However, I don''t have a physical TPM on my PC. Can I use the TPM >>>>> emulator >>>>> in Xen-4.3-unstable now? >>>>> >>>>> Thank you very much, >>>>> Bei Guan >>>>> >>>>> >>>>> The current TPM Manager requires a physical TPM to be present. While >>>> you could make things work without one, it would require patching >>>> either the vTPM or vTPM Manager domains with an alternate sealing >>>> mechanism for the long-term keys and source of random numbers. >>>> >>>> >>> Hi Daniel, >>> >>> I''m trying vTPM on Xen-4.3-unstable with a TPM emulator. However, I run >>> into problems. >>> Everything in stubdom seems to be compiled successfully except for the >>> TPM >>> emulator. >>> >> >> I can''t help if I don''t know what the problems are. Some of the >> dependencies >> in stubdom may be broken if you got things half-compiled before they >> broke, >> so a clean tree could help. You also need cmake, but it sounds like you''ve >> gotten past that point. >> >> >> I''m not sure how to make the TPM emulator work in Xen-4.3. Can you give >>> me >>> more detailed instructions? Such as which part of the code need to be >>> modified, if necessary. And, how much the coding work need to do to make >>> the TPM emulator work? >>> >> >> The TPM emulator (vtpm-stubdom) depends on the TPM Manager >> (vtpmmgr-stubdom) >> to store its encryption keys securely. The TPM Manager uses a physical TPM >> to secure its own storage. Without a physical TPM, this is not possible, >> so >> possible workarounds include removing the requirement to have a TPM >> manager >> from the vTPM domain (remove tpmfront references), or to modify the TPM >> manager to not use the physical TPM. >> >> In either case, you will need to find another source for random numbers, >> which is one thing the physical TPM is used for. Changing the vTPM would >> be >> simpler than changing the TPM manager; the code you need to change is >> ~1000 >> lines, but most of your changes will be removal of code. >> >> >> I found there is a code file tpm_tis.c in mini-os/ and stubdom/ioemu/hw/ >>> respectively. What''s the difference between them? Is the code >>> stubdom/ioemu/hw/tpm_tis.c only for QEMU emulated TPM device? >>> And, what''s the difference between mini-os/tpm_tis.c and >>> drivers/char/tpm/tpm_tis.c in linux kernel? >>> >>> Thank you very much. >>> >> >> The mini-os driver is derived from the one in the Linux kernel; they both >> interface with a hardware TPM. The QEMU code (ioemu/hw) emulates a >> hardware >> TPM based on qemu''s access to a Linux /dev/tpm0 device driver. With Linux >> stub domains, this device can be backed by the tpmfront driver connected >> to >> the vtpm stubdom. >> >> >> -- >> Daniel De Graaf >> National Security Agency >> > > > > -- > Best Regards, > Bei Guan >-- Best Regards, Bei Guan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
On 06/05/2013 04:36 AM, Bei Guan wrote:> Thank you for your reply. > I find out you previous TPM front patch that you posted several days ago at: > http://xen.markmail.org/message/j6xyvmjlqocjxbbn?q=drivers/tpm:+add+xen+tpmfront+interface > > Is your patch only for a PV DomU? Can I use a linux hvm to apply your patch? > If not, can you recommend a DomU (PV or HVM is ok) to use your patch? Thank > you very much.This patch has been tested successfully as both PV and HVM. Full support for HVM will need a bit more integration with the BIOS (i.e. hvmloader) and with QEMU to support the usual TIS interface to the TPM so bootloaders like trusted grub can work - however, if you don''t care about having a full chain of measurement in your guest, all the usual TPM functionality will work in HVM mode with that module. The tpmfront driver also works in dom0, which can be useful if you want TPM functionality there since the real TPM is exclusively used by the TPM manager. This is what the "hwinitpcrs" vTPM command line option is intended for; normal vTPMs should initialize their PCRs to 0. Re: 2.6.18 - I think the in-kernel TPM interface is a bit different there. The existing tpmfront module for 2.6.18 won''t work with the v2 interface used in Xen 4.3''s tpmback, but there have been previous patches that just updated that interface (first to patch a 3.x kernel, then to tweak the interface) so a backport shouldn''t be too hard.> 2013/6/4 Daniel De Graaf <dgdegra@tycho.nsa.gov> > >> On 06/04/2013 05:03 AM, Bei Guan wrote: >> >>> 2013/5/29 Daniel De Graaf <dgdegra@tycho.nsa.gov> >>> >>> On 05/29/2013 07:23 AM, Bei Guan wrote: >>>> >>>> Thank you for all your reply. I''ll try vTPM on Xen-4.3-unstable. >>>>> >>>>> However, I don''t have a physical TPM on my PC. Can I use the TPM >>>>> emulator >>>>> in Xen-4.3-unstable now? >>>>> >>>>> Thank you very much, >>>>> Bei Guan >>>>> >>>>> >>>>> The current TPM Manager requires a physical TPM to be present. While >>>> you could make things work without one, it would require patching >>>> either the vTPM or vTPM Manager domains with an alternate sealing >>>> mechanism for the long-term keys and source of random numbers. >>>> >>>> >>> Hi Daniel, >>> >>> I''m trying vTPM on Xen-4.3-unstable with a TPM emulator. However, I run >>> into problems. >>> Everything in stubdom seems to be compiled successfully except for the TPM >>> emulator. >>> >> >> I can''t help if I don''t know what the problems are. Some of the >> dependencies >> in stubdom may be broken if you got things half-compiled before they broke, >> so a clean tree could help. You also need cmake, but it sounds like you''ve >> gotten past that point. >> >> >> I''m not sure how to make the TPM emulator work in Xen-4.3. Can you give me >>> more detailed instructions? Such as which part of the code need to be >>> modified, if necessary. And, how much the coding work need to do to make >>> the TPM emulator work? >>> >> >> The TPM emulator (vtpm-stubdom) depends on the TPM Manager >> (vtpmmgr-stubdom) >> to store its encryption keys securely. The TPM Manager uses a physical TPM >> to secure its own storage. Without a physical TPM, this is not possible, so >> possible workarounds include removing the requirement to have a TPM manager >> from the vTPM domain (remove tpmfront references), or to modify the TPM >> manager to not use the physical TPM. >> >> In either case, you will need to find another source for random numbers, >> which is one thing the physical TPM is used for. Changing the vTPM would be >> simpler than changing the TPM manager; the code you need to change is ~1000 >> lines, but most of your changes will be removal of code. >> >> >> I found there is a code file tpm_tis.c in mini-os/ and stubdom/ioemu/hw/ >>> respectively. What''s the difference between them? Is the code >>> stubdom/ioemu/hw/tpm_tis.c only for QEMU emulated TPM device? >>> And, what''s the difference between mini-os/tpm_tis.c and >>> drivers/char/tpm/tpm_tis.c in linux kernel? >>> >>> Thank you very much. >>> >> >> The mini-os driver is derived from the one in the Linux kernel; they both >> interface with a hardware TPM. The QEMU code (ioemu/hw) emulates a hardware >> TPM based on qemu''s access to a Linux /dev/tpm0 device driver. With Linux >> stub domains, this device can be backed by the tpmfront driver connected to >> the vtpm stubdom. >> >> >> -- >> Daniel De Graaf >> National Security Agency >> > > >-- Daniel De Graaf National Security Agency
2013/6/5 Daniel De Graaf <dgdegra@tycho.nsa.gov>> On 06/05/2013 04:36 AM, Bei Guan wrote: > >> Thank you for your reply. >> I find out you previous TPM front patch that you posted several days ago >> at: >> http://xen.markmail.org/**message/j6xyvmjlqocjxbbn?q=** >> drivers/tpm:+add+xen+tpmfront+**interface<http://xen.markmail.org/message/j6xyvmjlqocjxbbn?q=drivers/tpm:+add+xen+tpmfront+interface> >> >> Is your patch only for a PV DomU? Can I use a linux hvm to apply your >> patch? >> If not, can you recommend a DomU (PV or HVM is ok) to use your patch? >> Thank >> you very much. >> > > This patch has been tested successfully as both PV and HVM. Full support > for > HVM will need a bit more integration with the BIOS (i.e. hvmloader) and > with > QEMU to support the usual TIS interface to the TPM so bootloaders like > trusted grub can work - however, if you don''t care about having a full > chain > of measurement in your guest, all the usual TPM functionality will work in > HVM mode with that module. > > The tpmfront driver also works in dom0, which can be useful if you want TPM > functionality there since the real TPM is exclusively used by the TPM > manager. > This is what the "hwinitpcrs" vTPM command line option is intended for; > normal > vTPMs should initialize their PCRs to 0. > > Re: 2.6.18 - I think the in-kernel TPM interface is a bit different there. > The existing tpmfront module for 2.6.18 won''t work with the v2 interface > used > in Xen 4.3''s tpmback, but there have been previous patches that just > updated > that interface (first to patch a 3.x kernel, then to tweak the interface) > so > a backport shouldn''t be too hard.I have applied your patch tpmfront (v3) to the linux-kernel 3.9.1. When I create the vtpm_manager, there is an error as the following. (on Xen-4.3-unstable with TPM emulator) Does this error has something to do with the TPM emulator? (PS: I have not yet changed the vtpm manager and vtpm to fit for the emulator.) [root@localhost vtpm-conf]# xl create -c vtpmmgr-stubdom.cfg Parsing config from vtpmmgr-stubdom.cfg Daemon running with PID 6631 Xen Minimal OS! start_info: 0xa3000(VA) nr_pages: 0x1000 shared_inf: 0xbbcaf000(MA) pt_base: 0xa6000(VA) nr_pt_frames: 0x5 mfn_list: 0x9b000(VA) mod_start: 0x0(VA) mod_len: 0 flags: 0x0 cmd_line: stack: 0x5a7a0-0x7a7a0 MM: Init _text: 0x0(VA) _etext: 0x39854(VA) _erodata: 0x46000(VA) _edata: 0x48c00(VA) stack start: 0x5a7a0(VA) _end: 0x9adc0(VA) start_pfn: ae max_pfn: 1000 Mapping memory range 0x400000 - 0x1000000 setting 0x0-0x46000 readonly skipped 0x1000 MM: Initialise page allocator for b4000(b4000)-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 0x1003e8 Thread "shutdown": pointer: 0x2001002fb0, stack: 0xf0000 Dummy main: start_info=0x7a8a0 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/19/768 Failed to read /local/domain/0/backend/qdisk/19/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 0x1f0ea base is 0x10fcd8 caller is 0x284e3 base is 0x10fd88 caller is 0x285b8 base is 0x10fde8 caller is 0x270cc base is 0x10fe28 caller is 0x270e4 base is 0x10fe38 caller is 0x1bcc9 base is 0x10fe78 caller is 0x6ffc base is 0x10ff38 caller is 0x3545 base is 0x10ff68 caller is 0x1fc1c base is 0x10ffe8 caller is 0x343b> > > 2013/6/4 Daniel De Graaf <dgdegra@tycho.nsa.gov> >> >> On 06/04/2013 05:03 AM, Bei Guan wrote: >>> >>> 2013/5/29 Daniel De Graaf <dgdegra@tycho.nsa.gov> >>>> >>>> On 05/29/2013 07:23 AM, Bei Guan wrote: >>>> >>>>> >>>>> Thank you for all your reply. I''ll try vTPM on Xen-4.3-unstable. >>>>> >>>>>> >>>>>> However, I don''t have a physical TPM on my PC. Can I use the TPM >>>>>> emulator >>>>>> in Xen-4.3-unstable now? >>>>>> >>>>>> Thank you very much, >>>>>> Bei Guan >>>>>> >>>>>> >>>>>> The current TPM Manager requires a physical TPM to be present. While >>>>>> >>>>> you could make things work without one, it would require patching >>>>> either the vTPM or vTPM Manager domains with an alternate sealing >>>>> mechanism for the long-term keys and source of random numbers. >>>>> >>>>> >>>>> Hi Daniel, >>>> >>>> I''m trying vTPM on Xen-4.3-unstable with a TPM emulator. However, I run >>>> into problems. >>>> Everything in stubdom seems to be compiled successfully except for the >>>> TPM >>>> emulator. >>>> >>>> >>> I can''t help if I don''t know what the problems are. Some of the >>> dependencies >>> in stubdom may be broken if you got things half-compiled before they >>> broke, >>> so a clean tree could help. You also need cmake, but it sounds like >>> you''ve >>> gotten past that point. >>> >>> >>> I''m not sure how to make the TPM emulator work in Xen-4.3. Can you >>> give me >>> >>>> more detailed instructions? Such as which part of the code need to be >>>> modified, if necessary. And, how much the coding work need to do to make >>>> the TPM emulator work? >>>> >>>> >>> The TPM emulator (vtpm-stubdom) depends on the TPM Manager >>> (vtpmmgr-stubdom) >>> to store its encryption keys securely. The TPM Manager uses a physical >>> TPM >>> to secure its own storage. Without a physical TPM, this is not possible, >>> so >>> possible workarounds include removing the requirement to have a TPM >>> manager >>> from the vTPM domain (remove tpmfront references), or to modify the TPM >>> manager to not use the physical TPM. >>> >>> In either case, you will need to find another source for random numbers, >>> which is one thing the physical TPM is used for. Changing the vTPM would >>> be >>> simpler than changing the TPM manager; the code you need to change is >>> ~1000 >>> lines, but most of your changes will be removal of code. >>> >>> >>> I found there is a code file tpm_tis.c in mini-os/ and >>> stubdom/ioemu/hw/ >>> >>>> respectively. What''s the difference between them? Is the code >>>> stubdom/ioemu/hw/tpm_tis.c only for QEMU emulated TPM device? >>>> And, what''s the difference between mini-os/tpm_tis.c and >>>> drivers/char/tpm/tpm_tis.c in linux kernel? >>>> >>>> Thank you very much. >>>> >>>> >>> The mini-os driver is derived from the one in the Linux kernel; they both >>> interface with a hardware TPM. The QEMU code (ioemu/hw) emulates a >>> hardware >>> TPM based on qemu''s access to a Linux /dev/tpm0 device driver. With Linux >>> stub domains, this device can be backed by the tpmfront driver connected >>> to >>> the vtpm stubdom. >>> >>> >>> -- >>> Daniel De Graaf >>> National Security Agency >>> >>> >> >> >> > > -- > Daniel De Graaf > National Security Agency >-- Best Regards, Bei Guan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
The config file for vTPM manager is kernel="/root/Xen/xen-4.3-unstable/stubdom/mini-os-x86_64-vtpmmgr/mini-os.gz" memory=16 disk=["file:/var/vtpmmgr-stubdom.img,hda,w"] name="vtpmmgr" iomem=["fed40,5"] 2013/6/6 Bei Guan <gbtju85@gmail.com>> > > > 2013/6/5 Daniel De Graaf <dgdegra@tycho.nsa.gov> > >> On 06/05/2013 04:36 AM, Bei Guan wrote: >> >>> Thank you for your reply. >>> I find out you previous TPM front patch that you posted several days ago >>> at: >>> http://xen.markmail.org/**message/j6xyvmjlqocjxbbn?q=** >>> drivers/tpm:+add+xen+tpmfront+**interface<http://xen.markmail.org/message/j6xyvmjlqocjxbbn?q=drivers/tpm:+add+xen+tpmfront+interface> >>> >>> Is your patch only for a PV DomU? Can I use a linux hvm to apply your >>> patch? >>> If not, can you recommend a DomU (PV or HVM is ok) to use your patch? >>> Thank >>> you very much. >>> >> >> This patch has been tested successfully as both PV and HVM. Full support >> for >> HVM will need a bit more integration with the BIOS (i.e. hvmloader) and >> with >> QEMU to support the usual TIS interface to the TPM so bootloaders like >> trusted grub can work - however, if you don''t care about having a full >> chain >> of measurement in your guest, all the usual TPM functionality will work in >> HVM mode with that module. >> >> The tpmfront driver also works in dom0, which can be useful if you want >> TPM >> functionality there since the real TPM is exclusively used by the TPM >> manager. >> This is what the "hwinitpcrs" vTPM command line option is intended for; >> normal >> vTPMs should initialize their PCRs to 0. >> >> Re: 2.6.18 - I think the in-kernel TPM interface is a bit different there. >> The existing tpmfront module for 2.6.18 won''t work with the v2 interface >> used >> in Xen 4.3''s tpmback, but there have been previous patches that just >> updated >> that interface (first to patch a 3.x kernel, then to tweak the interface) >> so >> a backport shouldn''t be too hard. > > I have applied your patch tpmfront (v3) to the linux-kernel 3.9.1. > When I create the vtpm_manager, there is an error as the following. (on > Xen-4.3-unstable with TPM emulator) > Does this error has something to do with the TPM emulator? > (PS: I have not yet changed the vtpm manager and vtpm to fit for the > emulator.) > > [root@localhost vtpm-conf]# xl create -c vtpmmgr-stubdom.cfg > Parsing config from vtpmmgr-stubdom.cfg > Daemon running with PID 6631 > Xen Minimal OS! > start_info: 0xa3000(VA) > nr_pages: 0x1000 > shared_inf: 0xbbcaf000(MA) > pt_base: 0xa6000(VA) > nr_pt_frames: 0x5 > mfn_list: 0x9b000(VA) > mod_start: 0x0(VA) > mod_len: 0 > flags: 0x0 > cmd_line: > stack: 0x5a7a0-0x7a7a0 > MM: Init > _text: 0x0(VA) > _etext: 0x39854(VA) > _erodata: 0x46000(VA) > _edata: 0x48c00(VA) > stack start: 0x5a7a0(VA) > _end: 0x9adc0(VA) > start_pfn: ae > max_pfn: 1000 > Mapping memory range 0x400000 - 0x1000000 > setting 0x0-0x46000 readonly > skipped 0x1000 > MM: Initialise page allocator for b4000(b4000)-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 0x1003e8 > Thread "shutdown": pointer: 0x2001002fb0, stack: 0xf0000 > Dummy main: start_info=0x7a8a0 > 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/19/768 > Failed to read /local/domain/0/backend/qdisk/19/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 0x1f0ea > base is 0x10fcd8 caller is 0x284e3 > base is 0x10fd88 caller is 0x285b8 > base is 0x10fde8 caller is 0x270cc > base is 0x10fe28 caller is 0x270e4 > base is 0x10fe38 caller is 0x1bcc9 > base is 0x10fe78 caller is 0x6ffc > base is 0x10ff38 caller is 0x3545 > base is 0x10ff68 caller is 0x1fc1c > base is 0x10ffe8 caller is 0x343b > > > > > > >> >> >> 2013/6/4 Daniel De Graaf <dgdegra@tycho.nsa.gov> >>> >>> On 06/04/2013 05:03 AM, Bei Guan wrote: >>>> >>>> 2013/5/29 Daniel De Graaf <dgdegra@tycho.nsa.gov> >>>>> >>>>> On 05/29/2013 07:23 AM, Bei Guan wrote: >>>>> >>>>>> >>>>>> Thank you for all your reply. I''ll try vTPM on Xen-4.3-unstable. >>>>>> >>>>>>> >>>>>>> However, I don''t have a physical TPM on my PC. Can I use the TPM >>>>>>> emulator >>>>>>> in Xen-4.3-unstable now? >>>>>>> >>>>>>> Thank you very much, >>>>>>> Bei Guan >>>>>>> >>>>>>> >>>>>>> The current TPM Manager requires a physical TPM to be present. >>>>>>> While >>>>>>> >>>>>> you could make things work without one, it would require patching >>>>>> either the vTPM or vTPM Manager domains with an alternate sealing >>>>>> mechanism for the long-term keys and source of random numbers. >>>>>> >>>>>> >>>>>> Hi Daniel, >>>>> >>>>> I''m trying vTPM on Xen-4.3-unstable with a TPM emulator. However, I run >>>>> into problems. >>>>> Everything in stubdom seems to be compiled successfully except for the >>>>> TPM >>>>> emulator. >>>>> >>>>> >>>> I can''t help if I don''t know what the problems are. Some of the >>>> dependencies >>>> in stubdom may be broken if you got things half-compiled before they >>>> broke, >>>> so a clean tree could help. You also need cmake, but it sounds like >>>> you''ve >>>> gotten past that point. >>>> >>>> >>>> I''m not sure how to make the TPM emulator work in Xen-4.3. Can you >>>> give me >>>> >>>>> more detailed instructions? Such as which part of the code need to be >>>>> modified, if necessary. And, how much the coding work need to do to >>>>> make >>>>> the TPM emulator work? >>>>> >>>>> >>>> The TPM emulator (vtpm-stubdom) depends on the TPM Manager >>>> (vtpmmgr-stubdom) >>>> to store its encryption keys securely. The TPM Manager uses a physical >>>> TPM >>>> to secure its own storage. Without a physical TPM, this is not >>>> possible, so >>>> possible workarounds include removing the requirement to have a TPM >>>> manager >>>> from the vTPM domain (remove tpmfront references), or to modify the TPM >>>> manager to not use the physical TPM. >>>> >>>> In either case, you will need to find another source for random numbers, >>>> which is one thing the physical TPM is used for. Changing the vTPM >>>> would be >>>> simpler than changing the TPM manager; the code you need to change is >>>> ~1000 >>>> lines, but most of your changes will be removal of code. >>>> >>>> >>>> I found there is a code file tpm_tis.c in mini-os/ and >>>> stubdom/ioemu/hw/ >>>> >>>>> respectively. What''s the difference between them? Is the code >>>>> stubdom/ioemu/hw/tpm_tis.c only for QEMU emulated TPM device? >>>>> And, what''s the difference between mini-os/tpm_tis.c and >>>>> drivers/char/tpm/tpm_tis.c in linux kernel? >>>>> >>>>> Thank you very much. >>>>> >>>>> >>>> The mini-os driver is derived from the one in the Linux kernel; they >>>> both >>>> interface with a hardware TPM. The QEMU code (ioemu/hw) emulates a >>>> hardware >>>> TPM based on qemu''s access to a Linux /dev/tpm0 device driver. With >>>> Linux >>>> stub domains, this device can be backed by the tpmfront driver >>>> connected to >>>> the vtpm stubdom. >>>> >>>> >>>> -- >>>> Daniel De Graaf >>>> National Security Agency >>>> >>>> >>> >>> >>> >> >> -- >> Daniel De Graaf >> National Security Agency >> > > > > -- > Best Regards, > Bei Guan >-- Best Regards, Bei Guan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
On 06/05/2013 10:57 PM, Bei Guan wrote: [... cropping and moving the config below ...]>> >> I have applied your patch tpmfront (v3) to the linux-kernel 3.9.1. >> When I create the vtpm_manager, there is an error as the following. (on >> Xen-4.3-unstable with TPM emulator) >> Does this error has something to do with the TPM emulator? >> (PS: I have not yet changed the vtpm manager and vtpm to fit for the >> emulator.) >> >> [root@localhost vtpm-conf]# xl create -c vtpmmgr-stubdom.cfg >> Parsing config from vtpmmgr-stubdom.cfg >> Daemon running with PID 6631 >> Xen Minimal OS! >> start_info: 0xa3000(VA) >> nr_pages: 0x1000 >> shared_inf: 0xbbcaf000(MA) >> pt_base: 0xa6000(VA) >> nr_pt_frames: 0x5 >> mfn_list: 0x9b000(VA) >> mod_start: 0x0(VA) >> mod_len: 0 >> flags: 0x0 >> cmd_line: >> stack: 0x5a7a0-0x7a7a0 >> MM: Init >> _text: 0x0(VA) >> _etext: 0x39854(VA) >> _erodata: 0x46000(VA) >> _edata: 0x48c00(VA) >> stack start: 0x5a7a0(VA) >> _end: 0x9adc0(VA) >> start_pfn: ae >> max_pfn: 1000 >> Mapping memory range 0x400000 - 0x1000000 >> setting 0x0-0x46000 readonly >> skipped 0x1000 >> MM: Initialise page allocator for b4000(b4000)-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 0x1003e8 >> Thread "shutdown": pointer: 0x2001002fb0, stack: 0xf0000 >> Dummy main: start_info=0x7a8a0 >> 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/19/768 >> Failed to read /local/domain/0/backend/qdisk/19/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.This seems to be a failure to map the I/O memory for the physical TPM.>> Do_exit called! >> base is 0x10fcb8 caller is 0x1f0ea >> base is 0x10fcd8 caller is 0x284e3 >> base is 0x10fd88 caller is 0x285b8 >> base is 0x10fde8 caller is 0x270cc >> base is 0x10fe28 caller is 0x270e4 >> base is 0x10fe38 caller is 0x1bcc9 >> base is 0x10fe78 caller is 0x6ffc >> base is 0x10ff38 caller is 0x3545 >> base is 0x10ff68 caller is 0x1fc1c >> base is 0x10ffe8 caller is 0x343b >> >> >> >>> The config file for vTPM manager is > > kernel="/root/Xen/xen-4.3-unstable/stubdom/mini-os-x86_64-vtpmmgr/mini-os.gz" > memory=16 > disk=["file:/var/vtpmmgr-stubdom.img,hda,w"] > name="vtpmmgr" > iomem=["fed40,5"]The iomem line here should allow the TPM to be mapped without this error. Is this on a system with a hardware TPM? If not, then that would explain the error.>> >> >>> >>> >>> 2013/6/4 Daniel De Graaf <dgdegra@tycho.nsa.gov> >>>> >>>> On 06/04/2013 05:03 AM, Bei Guan wrote: >>>>> >>>>> 2013/5/29 Daniel De Graaf <dgdegra@tycho.nsa.gov> >>>>>> >>>>>> On 05/29/2013 07:23 AM, Bei Guan wrote: >>>>>> >>>>>>> >>>>>>> Thank you for all your reply. I''ll try vTPM on Xen-4.3-unstable. >>>>>>> >>>>>>>> >>>>>>>> However, I don''t have a physical TPM on my PC. Can I use the TPM >>>>>>>> emulator >>>>>>>> in Xen-4.3-unstable now? >>>>>>>> >>>>>>>> Thank you very much, >>>>>>>> Bei Guan >>>>>>>> >>>>>>>> >>>>>>>> The current TPM Manager requires a physical TPM to be present. >>>>>>>> While >>>>>>>> >>>>>>> you could make things work without one, it would require patching >>>>>>> either the vTPM or vTPM Manager domains with an alternate sealing >>>>>>> mechanism for the long-term keys and source of random numbers. >>>>>>> >>>>>>> >>>>>>> Hi Daniel, >>>>>> >>>>>> I''m trying vTPM on Xen-4.3-unstable with a TPM emulator. However, I run >>>>>> into problems. >>>>>> Everything in stubdom seems to be compiled successfully except for the >>>>>> TPM >>>>>> emulator. >>>>>> >>>>>> >>>>> I can''t help if I don''t know what the problems are. Some of the >>>>> dependencies >>>>> in stubdom may be broken if you got things half-compiled before they >>>>> broke, >>>>> so a clean tree could help. You also need cmake, but it sounds like >>>>> you''ve >>>>> gotten past that point. >>>>> >>>>> >>>>> I''m not sure how to make the TPM emulator work in Xen-4.3. Can you >>>>> give me >>>>> >>>>>> more detailed instructions? Such as which part of the code need to be >>>>>> modified, if necessary. And, how much the coding work need to do to >>>>>> make >>>>>> the TPM emulator work? >>>>>> >>>>>> >>>>> The TPM emulator (vtpm-stubdom) depends on the TPM Manager >>>>> (vtpmmgr-stubdom) >>>>> to store its encryption keys securely. The TPM Manager uses a physical >>>>> TPM >>>>> to secure its own storage. Without a physical TPM, this is not >>>>> possible, so >>>>> possible workarounds include removing the requirement to have a TPM >>>>> manager >>>>> from the vTPM domain (remove tpmfront references), or to modify the TPM >>>>> manager to not use the physical TPM. >>>>> >>>>> In either case, you will need to find another source for random numbers, >>>>> which is one thing the physical TPM is used for. Changing the vTPM >>>>> would be >>>>> simpler than changing the TPM manager; the code you need to change is >>>>> ~1000 >>>>> lines, but most of your changes will be removal of code. >>>>> >>>>> >>>>> I found there is a code file tpm_tis.c in mini-os/ and >>>>> stubdom/ioemu/hw/ >>>>> >>>>>> respectively. What''s the difference between them? Is the code >>>>>> stubdom/ioemu/hw/tpm_tis.c only for QEMU emulated TPM device? >>>>>> And, what''s the difference between mini-os/tpm_tis.c and >>>>>> drivers/char/tpm/tpm_tis.c in linux kernel? >>>>>> >>>>>> Thank you very much. >>>>>> >>>>>> >>>>> The mini-os driver is derived from the one in the Linux kernel; they >>>>> both >>>>> interface with a hardware TPM. The QEMU code (ioemu/hw) emulates a >>>>> hardware >>>>> TPM based on qemu''s access to a Linux /dev/tpm0 device driver. With >>>>> Linux >>>>> stub domains, this device can be backed by the tpmfront driver >>>>> connected to >>>>> the vtpm stubdom.-- Daniel De Graaf National Security Agency
No, there''s no TPM hardware on my PC. If a TPM emulator is used. Does it still need to map the TPM emulator using the line "iomem=["fed40,5"]" ? Another question is: Does the vTPM in Xen-4.3-unstable support the VM migration? What''s functionality of the TPM emulator in current version vtpm-stubdom? I find there only two libraries crypto/libtpm_crypto.a and tpm/libtpm.a are compiled in the TPM emulator directory. Thank you very much. 2013/6/6 Daniel De Graaf <dgdegra@tycho.nsa.gov>> On 06/05/2013 10:57 PM, Bei Guan wrote: > [... cropping and moving the config below ...] > > >>> I have applied your patch tpmfront (v3) to the linux-kernel 3.9.1. >>> When I create the vtpm_manager, there is an error as the following. (on >>> Xen-4.3-unstable with TPM emulator) >>> Does this error has something to do with the TPM emulator? >>> (PS: I have not yet changed the vtpm manager and vtpm to fit for the >>> emulator.) >>> >>> [root@localhost vtpm-conf]# xl create -c vtpmmgr-stubdom.cfg >>> Parsing config from vtpmmgr-stubdom.cfg >>> Daemon running with PID 6631 >>> Xen Minimal OS! >>> start_info: 0xa3000(VA) >>> nr_pages: 0x1000 >>> shared_inf: 0xbbcaf000(MA) >>> pt_base: 0xa6000(VA) >>> nr_pt_frames: 0x5 >>> mfn_list: 0x9b000(VA) >>> mod_start: 0x0(VA) >>> mod_len: 0 >>> flags: 0x0 >>> cmd_line: >>> stack: 0x5a7a0-0x7a7a0 >>> MM: Init >>> _text: 0x0(VA) >>> _etext: 0x39854(VA) >>> _erodata: 0x46000(VA) >>> _edata: 0x48c00(VA) >>> stack start: 0x5a7a0(VA) >>> _end: 0x9adc0(VA) >>> start_pfn: ae >>> max_pfn: 1000 >>> Mapping memory range 0x400000 - 0x1000000 >>> setting 0x0-0x46000 readonly >>> skipped 0x1000 >>> MM: Initialise page allocator for b4000(b4000)-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 0x1003e8 >>> Thread "shutdown": pointer: 0x2001002fb0, stack: 0xf0000 >>> Dummy main: start_info=0x7a8a0 >>> 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/**19/768 >>> Failed to read /local/domain/0/backend/qdisk/**19/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. >>> >> > This seems to be a failure to map the I/O memory for the physical TPM. > > > Do_exit called! >>> base is 0x10fcb8 caller is 0x1f0ea >>> base is 0x10fcd8 caller is 0x284e3 >>> base is 0x10fd88 caller is 0x285b8 >>> base is 0x10fde8 caller is 0x270cc >>> base is 0x10fe28 caller is 0x270e4 >>> base is 0x10fe38 caller is 0x1bcc9 >>> base is 0x10fe78 caller is 0x6ffc >>> base is 0x10ff38 caller is 0x3545 >>> base is 0x10ff68 caller is 0x1fc1c >>> base is 0x10ffe8 caller is 0x343b >>> >>> >>> >>> >>> > The config file for vTPM manager is >> >> kernel="/root/Xen/xen-4.3-**unstable/stubdom/mini-os-x86_** >> 64-vtpmmgr/mini-os.gz" >> memory=16 >> disk=["file:/var/vtpmmgr-**stubdom.img,hda,w"] >> name="vtpmmgr" >> iomem=["fed40,5"] >> > > The iomem line here should allow the TPM to be mapped without this error. > Is > this on a system with a hardware TPM? If not, then that would explain the > error. > > > >>> >>> >>>> >>>> 2013/6/4 Daniel De Graaf <dgdegra@tycho.nsa.gov> >>>> >>>>> >>>>> On 06/04/2013 05:03 AM, Bei Guan wrote: >>>>> >>>>>> >>>>>> 2013/5/29 Daniel De Graaf <dgdegra@tycho.nsa.gov> >>>>>> >>>>>>> >>>>>>> On 05/29/2013 07:23 AM, Bei Guan wrote: >>>>>>> >>>>>>> >>>>>>>> Thank you for all your reply. I''ll try vTPM on Xen-4.3-unstable. >>>>>>>> >>>>>>>> >>>>>>>>> However, I don''t have a physical TPM on my PC. Can I use the TPM >>>>>>>>> emulator >>>>>>>>> in Xen-4.3-unstable now? >>>>>>>>> >>>>>>>>> Thank you very much, >>>>>>>>> Bei Guan >>>>>>>>> >>>>>>>>> >>>>>>>>> The current TPM Manager requires a physical TPM to be present. >>>>>>>>> While >>>>>>>>> >>>>>>>>> you could make things work without one, it would require patching >>>>>>>> either the vTPM or vTPM Manager domains with an alternate sealing >>>>>>>> mechanism for the long-term keys and source of random numbers. >>>>>>>> >>>>>>>> >>>>>>>> Hi Daniel, >>>>>>>> >>>>>>> >>>>>>> I''m trying vTPM on Xen-4.3-unstable with a TPM emulator. However, I >>>>>>> run >>>>>>> into problems. >>>>>>> Everything in stubdom seems to be compiled successfully except for >>>>>>> the >>>>>>> TPM >>>>>>> emulator. >>>>>>> >>>>>>> >>>>>>> I can''t help if I don''t know what the problems are. Some of the >>>>>> dependencies >>>>>> in stubdom may be broken if you got things half-compiled before they >>>>>> broke, >>>>>> so a clean tree could help. You also need cmake, but it sounds like >>>>>> you''ve >>>>>> gotten past that point. >>>>>> >>>>>> >>>>>> I''m not sure how to make the TPM emulator work in Xen-4.3. Can you >>>>>> give me >>>>>> >>>>>> more detailed instructions? Such as which part of the code need to be >>>>>>> modified, if necessary. And, how much the coding work need to do to >>>>>>> make >>>>>>> the TPM emulator work? >>>>>>> >>>>>>> >>>>>>> The TPM emulator (vtpm-stubdom) depends on the TPM Manager >>>>>> (vtpmmgr-stubdom) >>>>>> to store its encryption keys securely. The TPM Manager uses a physical >>>>>> TPM >>>>>> to secure its own storage. Without a physical TPM, this is not >>>>>> possible, so >>>>>> possible workarounds include removing the requirement to have a TPM >>>>>> manager >>>>>> from the vTPM domain (remove tpmfront references), or to modify the >>>>>> TPM >>>>>> manager to not use the physical TPM. >>>>>> >>>>>> In either case, you will need to find another source for random >>>>>> numbers, >>>>>> which is one thing the physical TPM is used for. Changing the vTPM >>>>>> would be >>>>>> simpler than changing the TPM manager; the code you need to change is >>>>>> ~1000 >>>>>> lines, but most of your changes will be removal of code. >>>>>> >>>>>> >>>>>> I found there is a code file tpm_tis.c in mini-os/ and >>>>>> stubdom/ioemu/hw/ >>>>>> >>>>>> respectively. What''s the difference between them? Is the code >>>>>>> stubdom/ioemu/hw/tpm_tis.c only for QEMU emulated TPM device? >>>>>>> And, what''s the difference between mini-os/tpm_tis.c and >>>>>>> drivers/char/tpm/tpm_tis.c in linux kernel? >>>>>>> >>>>>>> Thank you very much. >>>>>>> >>>>>>> >>>>>>> The mini-os driver is derived from the one in the Linux kernel; they >>>>>> both >>>>>> interface with a hardware TPM. The QEMU code (ioemu/hw) emulates a >>>>>> hardware >>>>>> TPM based on qemu''s access to a Linux /dev/tpm0 device driver. With >>>>>> Linux >>>>>> stub domains, this device can be backed by the tpmfront driver >>>>>> connected to >>>>>> the vtpm stubdom. >>>>>> >>>>> > > > -- > Daniel De Graaf > National Security Agency >-- Best Regards, Bei Guan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
On 06/06/2013 12:25 PM, Bei Guan wrote:> No, there''s no TPM hardware on my PC. If a TPM emulator is used. Does it > still need to map the TPM emulator using the line "iomem=["fed40,5"]" ?No, you currently cannot use the vTPMs in Xen without a physical TPM. While the TPM manager does have an option to use the Xen TPM protocol as its backend instead of the TIS interface, that will still require a TPM to back it - and the only available one in Xen (vtpm-stubdom) requires a TPM manager so you''ll eventually have to ground this out in a real TPM or write your own emulator.> Another question is: Does the vTPM in Xen-4.3-unstable support the > VM migration?Currently it does not. The domain may be able to migrate, but it will lose access to the TPM. Migrating the TPM''s data is a more complex issue, and will only be supported in a later release - as will support for upgrades to the BIOS or hypervisor without losing a secured TPM manager''s state.> What''s functionality of the TPM emulator in current version vtpm-stubdom? I > find there only two libraries crypto/libtpm_crypto.a and tpm/libtpm.a are > compiled in the TPM emulator directory. > > Thank you very much.The TPM emulator handles the full TPM 1.2 specification, and is correct as far as I am aware. The TPM emulation is in stubdom/tpm_emulator-x86_64/tpm and is used to make those .a files.> > 2013/6/6 Daniel De Graaf <dgdegra@tycho.nsa.gov> > >> On 06/05/2013 10:57 PM, Bei Guan wrote: >> [... cropping and moving the config below ...] >> >> >>>> I have applied your patch tpmfront (v3) to the linux-kernel 3.9.1. >>>> When I create the vtpm_manager, there is an error as the following. (on >>>> Xen-4.3-unstable with TPM emulator) >>>> Does this error has something to do with the TPM emulator? >>>> (PS: I have not yet changed the vtpm manager and vtpm to fit for the >>>> emulator.) >>>> >>>> [root@localhost vtpm-conf]# xl create -c vtpmmgr-stubdom.cfg >>>> Parsing config from vtpmmgr-stubdom.cfg >>>> Daemon running with PID 6631 >>>> Xen Minimal OS! >>>> start_info: 0xa3000(VA) >>>> nr_pages: 0x1000 >>>> shared_inf: 0xbbcaf000(MA) >>>> pt_base: 0xa6000(VA) >>>> nr_pt_frames: 0x5 >>>> mfn_list: 0x9b000(VA) >>>> mod_start: 0x0(VA) >>>> mod_len: 0 >>>> flags: 0x0 >>>> cmd_line: >>>> stack: 0x5a7a0-0x7a7a0 >>>> MM: Init >>>> _text: 0x0(VA) >>>> _etext: 0x39854(VA) >>>> _erodata: 0x46000(VA) >>>> _edata: 0x48c00(VA) >>>> stack start: 0x5a7a0(VA) >>>> _end: 0x9adc0(VA) >>>> start_pfn: ae >>>> max_pfn: 1000 >>>> Mapping memory range 0x400000 - 0x1000000 >>>> setting 0x0-0x46000 readonly >>>> skipped 0x1000 >>>> MM: Initialise page allocator for b4000(b4000)-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 0x1003e8 >>>> Thread "shutdown": pointer: 0x2001002fb0, stack: 0xf0000 >>>> Dummy main: start_info=0x7a8a0 >>>> 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/**19/768 >>>> Failed to read /local/domain/0/backend/qdisk/**19/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. >>>> >>> >> This seems to be a failure to map the I/O memory for the physical TPM. >> >> >> Do_exit called! >>>> base is 0x10fcb8 caller is 0x1f0ea >>>> base is 0x10fcd8 caller is 0x284e3 >>>> base is 0x10fd88 caller is 0x285b8 >>>> base is 0x10fde8 caller is 0x270cc >>>> base is 0x10fe28 caller is 0x270e4 >>>> base is 0x10fe38 caller is 0x1bcc9 >>>> base is 0x10fe78 caller is 0x6ffc >>>> base is 0x10ff38 caller is 0x3545 >>>> base is 0x10ff68 caller is 0x1fc1c >>>> base is 0x10ffe8 caller is 0x343b >>>> >>>> >>>> >>>> >>>> >> The config file for vTPM manager is >>> >>> kernel="/root/Xen/xen-4.3-**unstable/stubdom/mini-os-x86_** >>> 64-vtpmmgr/mini-os.gz" >>> memory=16 >>> disk=["file:/var/vtpmmgr-**stubdom.img,hda,w"] >>> name="vtpmmgr" >>> iomem=["fed40,5"] >>> >> >> The iomem line here should allow the TPM to be mapped without this error. >> Is >> this on a system with a hardware TPM? If not, then that would explain the >> error. >> >> >> >>>> >>>> >>>>> >>>>> 2013/6/4 Daniel De Graaf <dgdegra@tycho.nsa.gov> >>>>> >>>>>> >>>>>> On 06/04/2013 05:03 AM, Bei Guan wrote: >>>>>> >>>>>>> >>>>>>> 2013/5/29 Daniel De Graaf <dgdegra@tycho.nsa.gov> >>>>>>> >>>>>>>> >>>>>>>> On 05/29/2013 07:23 AM, Bei Guan wrote: >>>>>>>> >>>>>>>> >>>>>>>>> Thank you for all your reply. I''ll try vTPM on Xen-4.3-unstable. >>>>>>>>> >>>>>>>>> >>>>>>>>>> However, I don''t have a physical TPM on my PC. Can I use the TPM >>>>>>>>>> emulator >>>>>>>>>> in Xen-4.3-unstable now? >>>>>>>>>> >>>>>>>>>> Thank you very much, >>>>>>>>>> Bei Guan >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> The current TPM Manager requires a physical TPM to be present. >>>>>>>>>> While >>>>>>>>>> >>>>>>>>>> you could make things work without one, it would require patching >>>>>>>>> either the vTPM or vTPM Manager domains with an alternate sealing >>>>>>>>> mechanism for the long-term keys and source of random numbers. >>>>>>>>> >>>>>>>>> >>>>>>>>> Hi Daniel, >>>>>>>>> >>>>>>>> >>>>>>>> I''m trying vTPM on Xen-4.3-unstable with a TPM emulator. However, I >>>>>>>> run >>>>>>>> into problems. >>>>>>>> Everything in stubdom seems to be compiled successfully except for >>>>>>>> the >>>>>>>> TPM >>>>>>>> emulator. >>>>>>>> >>>>>>>> >>>>>>>> I can''t help if I don''t know what the problems are. Some of the >>>>>>> dependencies >>>>>>> in stubdom may be broken if you got things half-compiled before they >>>>>>> broke, >>>>>>> so a clean tree could help. You also need cmake, but it sounds like >>>>>>> you''ve >>>>>>> gotten past that point. >>>>>>> >>>>>>> >>>>>>> I''m not sure how to make the TPM emulator work in Xen-4.3. Can you >>>>>>> give me >>>>>>> >>>>>>> more detailed instructions? Such as which part of the code need to be >>>>>>>> modified, if necessary. And, how much the coding work need to do to >>>>>>>> make >>>>>>>> the TPM emulator work? >>>>>>>> >>>>>>>> >>>>>>>> The TPM emulator (vtpm-stubdom) depends on the TPM Manager >>>>>>> (vtpmmgr-stubdom) >>>>>>> to store its encryption keys securely. The TPM Manager uses a physical >>>>>>> TPM >>>>>>> to secure its own storage. Without a physical TPM, this is not >>>>>>> possible, so >>>>>>> possible workarounds include removing the requirement to have a TPM >>>>>>> manager >>>>>>> from the vTPM domain (remove tpmfront references), or to modify the >>>>>>> TPM >>>>>>> manager to not use the physical TPM. >>>>>>> >>>>>>> In either case, you will need to find another source for random >>>>>>> numbers, >>>>>>> which is one thing the physical TPM is used for. Changing the vTPM >>>>>>> would be >>>>>>> simpler than changing the TPM manager; the code you need to change is >>>>>>> ~1000 >>>>>>> lines, but most of your changes will be removal of code. >>>>>>> >>>>>>> >>>>>>> I found there is a code file tpm_tis.c in mini-os/ and >>>>>>> stubdom/ioemu/hw/ >>>>>>> >>>>>>> respectively. What''s the difference between them? Is the code >>>>>>>> stubdom/ioemu/hw/tpm_tis.c only for QEMU emulated TPM device? >>>>>>>> And, what''s the difference between mini-os/tpm_tis.c and >>>>>>>> drivers/char/tpm/tpm_tis.c in linux kernel? >>>>>>>> >>>>>>>> Thank you very much. >>>>>>>> >>>>>>>> >>>>>>>> The mini-os driver is derived from the one in the Linux kernel; they >>>>>>> both >>>>>>> interface with a hardware TPM. The QEMU code (ioemu/hw) emulates a >>>>>>> hardware >>>>>>> TPM based on qemu''s access to a Linux /dev/tpm0 device driver. With >>>>>>> Linux >>>>>>> stub domains, this device can be backed by the tpmfront driver >>>>>>> connected to >>>>>>> the vtpm stubdom. >>>>>>> >>>>>> >> >> >> -- >> Daniel De Graaf >> National Security Agency >> > > >-- Daniel De Graaf National Security Agency