On Tue, May 21, 2013 at 2:31 PM, Wei, Gang <gang....@intel.com> wrote:

> >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.
> Yes, I agree with you on this point. And I've checked the initialization
> part of xen and found that: once xen detects the existence of tboot during
> the process of command line parsing, it will skip one part of
> read-mode(mem.S: the main task is to get system memory map) and enter into
> the protected and paging on mode. I think the reason why xen skips is that
> it has already been aware of the tboot and it does not have to initiate a
> BIOS interrupt (int 0x15). After that, xen will take some measure to
> protect TXT-related memory regions from DMA attack. Also, xen has done some
> protection measures to do with the sleep and shutdown events.
>
    However, what puzzles me is that how tboot determines whether
kernel/VMM supports tboot? It's just as what you said: " it is supposed
that even Xen is not tboot aware, it should still be able to boot up and
able to bring up guest". I think tboot has a verifcation mechanism to
distinguish xen with tboot from xen without tboot. Can you give me some
references?
   Thanks!
   henry



> >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?
>
------------------------------------------------------------------------------
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

Reply via email to