The control flow is right. And it is supposed that even Xen is not tboot aware, it should still be able to boot up and able to bring up guest, but this is not a design goal for tboot. If it doesn't then you need to check what is the really cause.
Jimmy henry del wrote on 2013-05-19: > Hi, > > I think that the control flow of CPU is as follows: grub -> tboot -> xen -> > guest OS. If we only consider the process of loading guest OS, regardless of > handling the sleep states and shutdown event, the guest OS should be > launched successfully. In other words, if xen does not support tboot, the guest > OS should also be launched successfully, but I've failed in such a way. > > Is it because that the assumption of control flow is wrong? if it is, then > what is the right cotrol flow? > > Thanks. > > Best regards, > henry > > > > On Sun, May 19, 2013 at 3:36 PM, henry del <idelhe...@gmail.com> wrote: > > > > > > On Sun, May 19, 2013 at 10:15 AM, Wei, Gang <gang....@intel.com> wrote: > > > henry del wrote on 2013-05-18: > > >> Thank you for your prompt reply. Yet I have another > question. >> According to the TXT spec, if GETSEC[SENTER] leaf > function has not been >> used to launch a measured environment, it's > impossible to make use of >> locality 1-4. Because registers in the > private space can only be >> accessed after a measured environment has > been established, while these >> registers control whether to unlock > the locality 1-4. That means that >> if bitvisor wants to use PCR, > locality of which is above 0, bitvisor >> need to support txt. Is that > correct? > > > >Correct. PCR17~22 can't be extended in locality 0. > > > >> So if I port xen/arch/x86/tboot.c and relevant files into > bitvisor >> and modify the grub.lst, this way will work for bitvisor? > > > >Yes. > > I have compared the tboot implementation in kernel 3.2.2 to that of > xen, they are much different. The important files: tboot.c and tboot.h are > supported differently in xen and kernel. > > > I think that both xen and kernel have full control of hardware sources > when booted separatedly by tboot. Why do xen and linux kernel have a different > implementation of tboot? Or is it enough for me only to refer to tboot support > in xen when I work for bitvisor?
smime.p7s
Description: S/MIME cryptographic signature
------------------------------------------------------------------------------ Try New Relic Now & We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, & servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may
_______________________________________________ tboot-devel mailing list tboot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tboot-devel
