tboot-devel — Developer support

Re: [tboot-devel] Intel's P-MAPS research project

[Hal F. <hal...@gm...>]

On Tue, Jul 21, 2009 at 6:20 AM, Lil Evil<Lil...@gm...> wrote:
> There are many different projects with similar goals out there:
> BitVisor(sourcecode available somewhere) or Daonity and of course flickr, probably more that I am not aware of.
> They all seem to target a particular use case and scenario.
>
> Cutting out Operating System is certainly an elegant and interesting solution. However, I think in its current form and function it is limited.
> You cannot use shared libraries and there is still the issue with the trusted graphics to be solved.
>
> Just some thoughts ....
> lIl

Hi Lil, thank you for the pointers to those other projects, I will
look at them more. I was a little confused about the mention of
flickr, the photo sharing site, not where you'd expect to find the
cutting edge of hypervisor research. But then I realized you meant Jon
McCune's Flicker, which I agree is a very advanced implementation
along these lines.

I have the impression that P-MAPS can handle shared libraries. Reading
some of the older papers by the same author(s), which used a variety
of technologies to provide "ring -1" protection to application data,
there is discussion of a signed "manifest" which describes what should
be in an executable, and which includes relocation information
necessary because the dynamic loader will move things around in
memory. I think this would be specific to shared libraries, but I'm
not sure.

Unfortunately it appears that the Intel research blog site I linked to
is kind of inactive, with no posts or updates for a month. Comments
have to be approved; mine hasn't appeared after more than a week, and
in fact no comments have been approved for the past month. Maybe the
site administrator is on vacation, or maybe all of Intel shuts down
during July? :)

Hal

Re: [tboot-devel] SINIT module license

[Jonathan M. M. <jon...@cm...>]

Is it not also the case that the long-term plan is for the module 
specific to a particular system to be included with that system as part 
of its firmware?  I.e., code that wants to use TXT can just read the 
appropriate module out of a well-known memory location?

If this is the case, then it solves the distribution problem, at least 
in the long run.

Thanks,
-Jon



Shane Wang wrote:
> Yes, you are right.
> 
> Shane
> 
> Martin Pirker wrote:
>> Reading the "Intel Software License Agreement" packaged along
>> with the SINIT binaries, I would interpret it that it is not
>> allowed to distribute the SINIT modules.
>> Rather, every user who wants to do a TXT boot needs to
>> download and install the SINIT binaries by himself.
>>
>> Is my reading correct?
>>
>> Martin
>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> tboot-devel mailing list
>> tbo...@li...
>> https://lists.sourceforge.net/lists/listinfo/tboot-devel
> 
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> tboot-devel mailing list
> tbo...@li...
> https://lists.sourceforge.net/lists/listinfo/tboot-devel
> 

Re: [tboot-devel] SINIT module license

[Shane W. <sha...@in...>]

Yes, you are right.

Shane

Martin Pirker wrote:
> Reading the "Intel Software License Agreement" packaged along
> with the SINIT binaries, I would interpret it that it is not
> allowed to distribute the SINIT modules.
> Rather, every user who wants to do a TXT boot needs to
> download and install the SINIT binaries by himself.
> 
> Is my reading correct?
> 
> Martin
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> tboot-devel mailing list
> tbo...@li...
> https://lists.sourceforge.net/lists/listinfo/tboot-devel

[tboot-devel] SINIT module license

[Martin P. <Mar...@ia...>]

Reading the "Intel Software License Agreement" packaged along
with the SINIT binaries, I would interpret it that it is not
allowed to distribute the SINIT modules.
Rather, every user who wants to do a TXT boot needs to
download and install the SINIT binaries by himself.

Is my reading correct?

Martin

Re: [tboot-devel] Calculation of PCR 18 - Error in doc

[Shane W. <sha...@in...>]

Right.
The tboot policy was extended to PCR 17 in the code, if 
TB_POLCTL_EXTEND_PCR17 is set.

Thanks.
Shane

Michael Gissing wrote:
> Hi!
> 
> I tried to calculate the final value of PCR 18 by paper and pen, it 
> seems that tboot README is wrong about that. In section "PCR Usage" it 
> says that tboot policy will also be extended to PCR 18, that's wrong.
> 
> PCR 18 is calculated only by:
> 1) extend hash of tboot (as measured by lcp_mlehash)
> 2) extend (SHA-1(commandline of first module) | SHA-1(first module))
> 
> greetz
> Michael
> 
> ------------------------------------------------------------------------------
> Enter the BlackBerry Developer Challenge  
> This is your chance to win up to $100,000 in prizes! For a limited time, 
> vendors submitting new applications to BlackBerry App World(TM) will have
> the opportunity to enter the BlackBerry Developer Challenge. See full prize  
> details at: http://p.sf.net/sfu/Challenge
> _______________________________________________
> tboot-devel mailing list
> tbo...@li...
> https://lists.sourceforge.net/lists/listinfo/tboot-devel

Re: [tboot-devel] LCP index definitions

[Shane W. <sha...@in...>]

Hi Martin,

Sorry for that. We are looking at different versions. I can't find it in 
  version 2008-June, either.

For what you mentioned, it is not clear in the current spec. We will 
mention the definitions according to what you pointed out in the next 
release of the spec, which will be published soon.

Thanks.
Shane

Martin Pirker wrote:
> Shane Wang wrote:
>> The index values are the protocol with the SINIT module, consulting with
>> the SINIT. The tools in tboot write launch control policy to those
>> addresses in TPM NV, and during machine bootup, the SINIT reads policies
>> from those addresses by default. You can get some info about platform
>> owner index in 3.5.
> 
> I understand what they are good for, but I can't find a spec definition
> for them.  There is no chapter 3.5 in
> http://download.intel.com/technology/security/downloads/315168.pdf
> ?!?
> 
> Thanks,
> Martin
> 
>> But you provide a good suggestion to revise the document. This should be
>> clear in the document.
>>
>> Thanks.
>> Shane
>>
>> Martin Pirker wrote:
>>> Hello list....
>>>
>>> In include/lcp.h there are definitions:
>>>
>>> /*--------- LCP reserved Indices------------*/
>>> #define INDEX_LCP_DEF   0x50000001
>>> #define INDEX_LCP_OWN   0x40000001
>>> #define INDEX_AUX       0x50000002
>>>
>>>
>>> Where do they come from?
>>>
>>> Appendix D in the Intel TXT guide (June 2008) describes
>>> some of the structures, but to me it appears I'm missing
>>> some pieces of the puzzle....
>>>
>>> Thanks,
>>> Martin
> 

Re: [tboot-devel] Bug in find_mle_hdr(), mlehash.c

[Shane W. <sha...@in...>]

Hi Michael,

Thank you for pointing out the potential issue.
Here is the fix for it.

Fix the potential segmentation fault in find_mle_hdr,
when size%sizeof(uuid_t)!=0 where size is unsigned long.

Signed-off-by: Shane Wang <sha...@in...>
diff -r ad96c7e8bf5a lcptools/mlehash.c
--- a/lcptools/mlehash.c	Tue Jul 21 17:22:14 2009 -0700
+++ b/lcptools/mlehash.c	Tue Jul 21 17:57:57 2009 -0700
@@ -308,11 +308,13 @@ error:

  static mle_hdr_t *find_mle_hdr(void *start, size_t size)
  {
-    while ( size > 0 ) {
+    void *end;
+
+    end = start + size - sizeof(uuid_t);
+    while ( start <= end ) {
          if ( are_uuids_equal((const uuid_t *)start, 
&((uuid_t)MLE_HDR_UUID)) )
              return (mle_hdr_t *)start;
          start += sizeof(uuid_t);
-        size -= sizeof(uuid_t);
      }
      return NULL;
  }


Thanks.
Shane

Michael Gissing wrote:
> Hi!
> 
> This is just a minor issue, but I want to share it with you ;-)
> 
> file mlehash.c, line 311:
> size is a size_t (typedefed unsigned long), so if "size%sizeof(uuid_t) 
> != 0", size will _always_ be >0, the loop won't exit and you'll get a 
> segfault.
> 
> I've got a question too: How do you ensure that the uuid we are
> searching for is always alligned to sizeof(uuid_t) stepping?
> 
> greetz
> Michael
> 
> 
> ------------------------------------------------------------------------------
> Enter the BlackBerry Developer Challenge  
> This is your chance to win up to $100,000 in prizes! For a limited time, 
> vendors submitting new applications to BlackBerry App World(TM) will have
> the opportunity to enter the BlackBerry Developer Challenge. See full prize  
> details at: http://p.sf.net/sfu/Challenge
> _______________________________________________
> tboot-devel mailing list
> tbo...@li...
> https://lists.sourceforge.net/lists/listinfo/tboot-devel

Re: [tboot-devel] Intel's P-MAPS research project

[Lil E. <Lil...@gm...>]

There are many different projects with similar goals out there:
BitVisor(sourcecode available somewhere) or Daonity and of course flickr, probably more that I am not aware of.
They all seem to target a particular use case and scenario.

Cutting out Operating System is certainly an elegant and interesting solution. However, I think in its current form and function it is limited.
You cannot use shared libraries and there is still the issue with the trusted graphics to be solved.

Just some thoughts ....
lIl

-------- Original-Nachricht --------
> Datum: Sun, 12 Jul 2009 16:04:43 -0700
> Von: Hal Finney <hal...@gm...>
> An: tbo...@li...
> Betreff: [tboot-devel] Intel\'s P-MAPS research project

> I recently learned about Intel's P-MAPS research project which
> provides an alternative way of using TPM+TXT to provide attestations
> and sealing in the context of a standard OS. Here is a link to the
> Intel Research blog post:
> 
> http://blogs.intel.com/research/2009/04/p-maps_an_on-demand_hardware-r.php
> 
> and here is an article in Dr Dobbs Journal which goes into more detail:
> 
> http://www.ddj.com/mobile/218401423
> 
> The goal is to allow applications running in a standard OS like Linux
> or Windows to be able to gain hardware protection from corruption of
> other processes or of the OS. This is a hard problem to solve due to
> the complexity of modern OS's. P-MAPS bypasses the OS by loading a
> Measured Virtual Machine Monitor (MVMM) which runs the OS as a VM.
> Then a P-MAPS aware application can make special VM calls directly
> into P-MAPS, going around the OS, to request protection. P-MAPS
> monitors and virtualizes the OS's page tables and is able to protect
> all of the application's pages from rogue access, either from the OS
> or other processes.
> 
> Because P-MAPS mostly confines its attention to memory management, it
> can be relatively small for a VMM. It doesn't have to worry about
> virtualizing devices or networks or I/O or having to load lots of
> different drivers. It mostly just manages page tables. This means that
> the OS is removed from the Trusted Computing Base (TCB) which greatly
> reduces the amount of code which has to be correct in order to achieve
> security.
> 
> P-MAPS is also able to perform attestation ("Quote") and sealing on
> behalf of protected applications, allowing apps to protect secrets
> from other applications and from the OS, and to attest to outside
> parties that their data is safe.
> 
> Among other nice features, P-MAPS uses smart loading, such that when
> no applications are currently requesting P-MAPS services, it unloads
> itself completely and switches the OS from being in a VM back to being
> in a normal, non-virtualized mode. Then when a process requests P-MAPS
> protection, it re-virtualizes the OS, including doing a TXT launch of
> the P-MAPS MVMM.
> 
> All in all this sounds like an amazing range of functionality, a real
> tour de force to get all of these technologies (TPM, TXT, VM) working
> together successfully. But the net result is a tremendously useful
> package that neatly bypasses the dilemma of security vs complexity.
> Most solutions today either provide potentially high security with
> relatively limited functionality, like Jon McCune's Flicker, or
> provide a much wider set of functions, like TBOOT+XEN, at the expense
> of a large TCB which inherently undercuts security goals. P-MAPS
> appears to be the first solution I've seen that could provide high
> security via a small TCB, while retaining the functionality provided
> by a standard OS.
> 
> Unfortunately, as a research project it does not sound like something
> which is likely to be made available to experimenters any time soon. I
> hope Intel will find a way to make the code available as it has done
> with TBOOT. P-MAPS is IMO even better suited as a framework for
> providing meaningful TXT based protections to today's application
> developers.
> 
> Hal Finey
> 
> ------------------------------------------------------------------------------
> Enter the BlackBerry Developer Challenge  
> This is your chance to win up to $100,000 in prizes! For a limited time, 
> vendors submitting new applications to BlackBerry App World(TM) will have
> the opportunity to enter the BlackBerry Developer Challenge. See full
> prize  
> details at: http://p.sf.net/sfu/Challenge
> _______________________________________________
> tboot-devel mailing list
> tbo...@li...
> https://lists.sourceforge.net/lists/listinfo/tboot-devel

-- 
Neu: GMX Doppel-FLAT mit Internet-Flatrate + Telefon-Flatrate
für nur 19,99 Euro/mtl.!* http://portal.gmx.net/de/go/dsl02

Re: [tboot-devel] LCP index definitions

[Martin P. <Mar...@ia...>]

Shane Wang wrote:
> The index values are the protocol with the SINIT module, consulting with
> the SINIT. The tools in tboot write launch control policy to those
> addresses in TPM NV, and during machine bootup, the SINIT reads policies
> from those addresses by default. You can get some info about platform
> owner index in 3.5.

I understand what they are good for, but I can't find a spec definition
for them.  There is no chapter 3.5 in
http://download.intel.com/technology/security/downloads/315168.pdf
?!?

Thanks,
Martin

> But you provide a good suggestion to revise the document. This should be
> clear in the document.
> 
> Thanks.
> Shane
> 
> Martin Pirker wrote:
>> Hello list....
>>
>> In include/lcp.h there are definitions:
>>
>> /*--------- LCP reserved Indices------------*/
>> #define INDEX_LCP_DEF   0x50000001
>> #define INDEX_LCP_OWN   0x40000001
>> #define INDEX_AUX       0x50000002
>>
>>
>> Where do they come from?
>>
>> Appendix D in the Intel TXT guide (June 2008) describes
>> some of the structures, but to me it appears I'm missing
>> some pieces of the puzzle....
>>
>> Thanks,
>> Martin

[tboot-devel] Calculation of PCR 18 - Error in doc

[Michael G. <m.g...@tu...>]

Hi!

I tried to calculate the final value of PCR 18 by paper and pen, it 
seems that tboot README is wrong about that. In section "PCR Usage" it 
says that tboot policy will also be extended to PCR 18, that's wrong.

PCR 18 is calculated only by:
1) extend hash of tboot (as measured by lcp_mlehash)
2) extend (SHA-1(commandline of first module) | SHA-1(first module))

greetz
Michael

[tboot-devel] Bug in find_mle_hdr(), mlehash.c

[Michael G. <m.g...@tu...>]

Hi!

This is just a minor issue, but I want to share it with you ;-)

file mlehash.c, line 311:
size is a size_t (typedefed unsigned long), so if "size%sizeof(uuid_t) 
!= 0", size will _always_ be >0, the loop won't exit and you'll get a 
segfault.

I've got a question too: How do you ensure that the uuid we are
searching for is always alligned to sizeof(uuid_t) stepping?

greetz
Michael

Re: [tboot-devel] LCP index definitions

[Shane W. <sha...@in...>]

Hi Martin,

The index values are the protocol with the SINIT module, consulting with 
the SINIT. The tools in tboot write launch control policy to those 
addresses in TPM NV, and during machine bootup, the SINIT reads policies 
from those addresses by default. You can get some info about platform 
owner index in 3.5.

But you provide a good suggestion to revise the document. This should be 
clear in the document.

Thanks.
Shane

Martin Pirker wrote:
> Hello list....
> 
> In include/lcp.h there are definitions:
> 
> /*--------- LCP reserved Indices------------*/
> #define INDEX_LCP_DEF   0x50000001
> #define INDEX_LCP_OWN   0x40000001
> #define INDEX_AUX       0x50000002
> 
> 
> Where do they come from?
> 
> Appendix D in the Intel TXT guide (June 2008) describes
> some of the structures, but to me it appears I'm missing
> some pieces of the puzzle....
> 
> Thanks,
> Martin
> 
> 
> ------------------------------------------------------------------------------
> Enter the BlackBerry Developer Challenge  
> This is your chance to win up to $100,000 in prizes! For a limited time, 
> vendors submitting new applications to BlackBerry App World(TM) will have
> the opportunity to enter the BlackBerry Developer Challenge. See full prize  
> details at: http://p.sf.net/sfu/Challenge
> _______________________________________________
> tboot-devel mailing list
> tbo...@li...
> https://lists.sourceforge.net/lists/listinfo/tboot-devel

[tboot-devel] LCP index definitions

[Martin P. <Mar...@ia...>]

Hello list....

In include/lcp.h there are definitions:

/*--------- LCP reserved Indices------------*/
#define INDEX_LCP_DEF   0x50000001
#define INDEX_LCP_OWN   0x40000001
#define INDEX_AUX       0x50000002


Where do they come from?

Appendix D in the Intel TXT guide (June 2008) describes
some of the structures, but to me it appears I'm missing
some pieces of the puzzle....

Thanks,
Martin

[tboot-devel] Intel's P-MAPS research project

[Hal F. <hal...@gm...>]

I recently learned about Intel's P-MAPS research project which
provides an alternative way of using TPM+TXT to provide attestations
and sealing in the context of a standard OS. Here is a link to the
Intel Research blog post:

http://blogs.intel.com/research/2009/04/p-maps_an_on-demand_hardware-r.php

and here is an article in Dr Dobbs Journal which goes into more detail:

http://www.ddj.com/mobile/218401423

The goal is to allow applications running in a standard OS like Linux
or Windows to be able to gain hardware protection from corruption of
other processes or of the OS. This is a hard problem to solve due to
the complexity of modern OS's. P-MAPS bypasses the OS by loading a
Measured Virtual Machine Monitor (MVMM) which runs the OS as a VM.
Then a P-MAPS aware application can make special VM calls directly
into P-MAPS, going around the OS, to request protection. P-MAPS
monitors and virtualizes the OS's page tables and is able to protect
all of the application's pages from rogue access, either from the OS
or other processes.

Because P-MAPS mostly confines its attention to memory management, it
can be relatively small for a VMM. It doesn't have to worry about
virtualizing devices or networks or I/O or having to load lots of
different drivers. It mostly just manages page tables. This means that
the OS is removed from the Trusted Computing Base (TCB) which greatly
reduces the amount of code which has to be correct in order to achieve
security.

P-MAPS is also able to perform attestation ("Quote") and sealing on
behalf of protected applications, allowing apps to protect secrets
from other applications and from the OS, and to attest to outside
parties that their data is safe.

Among other nice features, P-MAPS uses smart loading, such that when
no applications are currently requesting P-MAPS services, it unloads
itself completely and switches the OS from being in a VM back to being
in a normal, non-virtualized mode. Then when a process requests P-MAPS
protection, it re-virtualizes the OS, including doing a TXT launch of
the P-MAPS MVMM.

All in all this sounds like an amazing range of functionality, a real
tour de force to get all of these technologies (TPM, TXT, VM) working
together successfully. But the net result is a tremendously useful
package that neatly bypasses the dilemma of security vs complexity.
Most solutions today either provide potentially high security with
relatively limited functionality, like Jon McCune's Flicker, or
provide a much wider set of functions, like TBOOT+XEN, at the expense
of a large TCB which inherently undercuts security goals. P-MAPS
appears to be the first solution I've seen that could provide high
security via a small TCB, while retaining the functionality provided
by a standard OS.

Unfortunately, as a research project it does not sound like something
which is likely to be made available to experimenters any time soon. I
hope Intel will find a way to make the code available as it has done
with TBOOT. P-MAPS is IMO even better suited as a framework for
providing meaningful TXT based protections to today's application
developers.

Hal Finey

Re: [tboot-devel] TXT questions

[Shane W. <sha...@in...>]

See below.

Thanks.
Shane

Anthony Dessiatnikoff wrote:
> Thank you for your answer,
> 
> for my second question, maybe I was not clear enough:
> I don't understand how the expected hashes values are coming from (it must be the TPM but it is necessary to save them into it before booting and executing tboot so I would like to know when these hashes are calculated and what is the tool used ?) before to be compared with the current value.
Yes, the expected hashes are in TPM. They are computed based on MLE 
image in advance and stored in TPM NV. For when, it is at the time when 
users think their systems are safe, such as, at the beginning of 
shipping. Or in most cases, even computed and provisioned by OEM vendors 
in the factory. For the tool, see lcp_mlehash in folder lcptools. For 
SINIT, it is signed by Intel.

> 
> about the localities, is it like the ring (0-3) protection system of processors, how is it implemented ? is any software able to declare itself as working in locality 4 ?
I think it is a bit like ring0~3, which is enforced by hardware. For how 
to implement or any software in locality 4, I have no idea to my 
knowledge. But you can refer to TCG spec to find the answers.

> 
> 
> 
> 
> 
> 2009/7/1 Shane Wang <sha...@in...<mailto:sha...@in...>>
> See my comments below.
> 
> Thanks.
> Shane
> 
> Anthony Dessiatnikoff wrote:
> Hi everyone,
> 
> I removed -Werror parameter into config.mk<http://config.mk><http://config.mk> to compile tboot and execute it.
> 
> 
> I have some questions:
> 
> - How can I retrieve the tboot logs (because during the boot, the display time is too short to see anything) ? it is apparently not in the dmesg command or others log files.
> If you have serial port, you can connect your test machine running tboot to another machine with serial line, and see the log in the window of some COM tool (say I am using Tera Term Pro)
> If not, you can set logging=memory in tboot command line in grub.conf and after booting up, you can see the log by a tool txt-stat, which is in tboot/txt-test.
> 
> 
> 
> - So we hash into PCR 17 and 18 the content of SINIT and MLE but we need to compare them to the expected values to be sure they are corrects, right ? so when is this verification ? Because DRTM PCRs are set to zeros after SENTER instruction, it is necessary to obtain the expected hashes values from somewhere before performing current hashes of SINIT and MLE and then comparing them.
> Right, we extend them into PCR 17 and PCR 18 respectively. For SINIT, it should include digital signature, and for MLE, its hash will be compared  in SINIT.
> 
> 
> 
> - What is exactly the e820 table ? Why do we need to secure it ?
> e820 is a table, which is provided by bios to explain memory layout for OS/VMM which range can be used, which can't.
> Because it is very important and we use it to protect tboot/TXT related memory itself. We don't want OS/VMM to touch them.
> 
> 
> 
> - How the localities are they managed, I mean is it a security concern (so not possible to pass through a locality to another) or just a way to separate PCRs use from different softwares (so possible to pass through a locality to another) ?
> It should not be the latter, not only PCRs. Locality is to enable the TPM to differentiation between commands from different local sources, a bit like access permission. In TPM v1.2, locality 0 is for normal application; 1 for trusted application; 2 for trusted OS; 4 for trusted chipset. For more, you can refer to TCG spec.
> 
> 
> 
> Thanks,
> 
> 
> --
> Anthony D.
> 
> 
> 
> 
> 
> 
> --
> Anthony Dessiatnikoff
> Master 2 in Computing Security and Cryptology
> University of Limoges (FR)
> 

Re: [tboot-devel] TXT questions

[Anthony D. <ade...@go...>]

Thank you for your answer,

for my second question, maybe I was not clear enough:
I don't understand how the expected hashes values are coming from (it must
be the TPM but it is necessary to save them into it before booting and
executing tboot so I would like to know when these hashes are calculated and
what is the tool used ?) before to be compared with the current value.

about the localities, is it like the ring (0-3) protection system of
processors, how is it implemented ? is any software able to declare itself
as working in locality 4 ?





2009/7/1 Shane Wang <sha...@in...>

> See my comments below.
>
> Thanks.
> Shane
>
> Anthony Dessiatnikoff wrote:
>
>> Hi everyone,
>>
>> I removed -Werror parameter into config.mk<http://config.mk> to compile
>> tboot and execute it.
>>
>> I have some questions:
>>
>> - How can I retrieve the tboot logs (because during the boot, the display
>> time is too short to see anything) ? it is apparently not in the dmesg
>> command or others log files.
>>
> If you have serial port, you can connect your test machine running tboot to
> another machine with serial line, and see the log in the window of some COM
> tool (say I am using Tera Term Pro)
> If not, you can set logging=memory in tboot command line in grub.conf and
> after booting up, you can see the log by a tool txt-stat, which is in
> tboot/txt-test.
>
>
>> - So we hash into PCR 17 and 18 the content of SINIT and MLE but we need
>> to compare them to the expected values to be sure they are corrects, right ?
>> so when is this verification ? Because DRTM PCRs are set to zeros after
>> SENTER instruction, it is necessary to obtain the expected hashes values
>> from somewhere before performing current hashes of SINIT and MLE and then
>> comparing them.
>>
> Right, we extend them into PCR 17 and PCR 18 respectively. For SINIT, it
> should include digital signature, and for MLE, its hash will be compared  in
> SINIT.
>
>
>> - What is exactly the e820 table ? Why do we need to secure it ?
>>
> e820 is a table, which is provided by bios to explain memory layout for
> OS/VMM which range can be used, which can't.
> Because it is very important and we use it to protect tboot/TXT related
> memory itself. We don't want OS/VMM to touch them.
>
>
>> - How the localities are they managed, I mean is it a security concern (so
>> not possible to pass through a locality to another) or just a way to
>> separate PCRs use from different softwares (so possible to pass through a
>> locality to another) ?
>>
> It should not be the latter, not only PCRs. Locality is to enable the TPM
> to differentiation between commands from different local sources, a bit like
> access permission. In TPM v1.2, locality 0 is for normal application; 1 for
> trusted application; 2 for trusted OS; 4 for trusted chipset. For more, you
> can refer to TCG spec.
>
>
>>
>> Thanks,
>>
>>
>> --
>> Anthony D.
>>
>>
>>
>


-- 
Anthony Dessiatnikoff
Master 2 in Computing Security and Cryptology
University of Limoges (FR)

Re: [tboot-devel] TXT questions

[Shane W. <sha...@in...>]

See my comments below.

Thanks.
Shane

Anthony Dessiatnikoff wrote:
> Hi everyone,
> 
> I removed -Werror parameter into config.mk<http://config.mk> to compile tboot and execute it.
> 
> I have some questions:
> 
> - How can I retrieve the tboot logs (because during the boot, the display time is too short to see anything) ? it is apparently not in the dmesg command or others log files.
If you have serial port, you can connect your test machine running tboot 
to another machine with serial line, and see the log in the window of 
some COM tool (say I am using Tera Term Pro)
If not, you can set logging=memory in tboot command line in grub.conf 
and after booting up, you can see the log by a tool txt-stat, which is 
in tboot/txt-test.

> 
> - So we hash into PCR 17 and 18 the content of SINIT and MLE but we need to compare them to the expected values to be sure they are corrects, right ? so when is this verification ? Because DRTM PCRs are set to zeros after SENTER instruction, it is necessary to obtain the expected hashes values from somewhere before performing current hashes of SINIT and MLE and then comparing them.
Right, we extend them into PCR 17 and PCR 18 respectively. For SINIT, it 
should include digital signature, and for MLE, its hash will be compared 
  in SINIT.

> 
> - What is exactly the e820 table ? Why do we need to secure it ?
e820 is a table, which is provided by bios to explain memory layout for 
OS/VMM which range can be used, which can't.
Because it is very important and we use it to protect tboot/TXT related 
memory itself. We don't want OS/VMM to touch them.

> 
> - How the localities are they managed, I mean is it a security concern (so not possible to pass through a locality to another) or just a way to separate PCRs use from different softwares (so possible to pass through a locality to another) ?
It should not be the latter, not only PCRs. Locality is to enable the 
TPM to differentiation between commands from different local sources, a 
bit like access permission. In TPM v1.2, locality 0 is for normal 
application; 1 for trusted application; 2 for trusted OS; 4 for trusted 
chipset. For more, you can refer to TCG spec.

> 
> 
> Thanks,
> 
> 
> --
> Anthony D.
> 
> 

[tboot-devel] TXT questions

[Anthony D. <ade...@go...>]

Hi everyone,

I removed -Werror parameter into config.mk to compile tboot and execute it.

I have some questions:

- How can I retrieve the tboot logs (because during the boot, the display
time is too short to see anything) ? it is apparently not in the dmesg
command or others log files.

- So we hash into PCR 17 and 18 the content of SINIT and MLE but we need to
compare them to the expected values to be sure they are corrects, right ? so
when is this verification ? Because DRTM PCRs are set to zeros after SENTER
instruction, it is necessary to obtain the expected hashes values from
somewhere before performing current hashes of SINIT and MLE and then
comparing them.

- What is exactly the e820 table ? Why do we need to secure it ?

- How the localities are they managed, I mean is it a security concern (so
not possible to pass through a locality to another) or just a way to
separate PCRs use from different softwares (so possible to pass through a
locality to another) ?


Thanks,


-- 
Anthony D.

Re: [tboot-devel] tboot

[Hal F. <hal...@gm...>]

>
> [JC]  When SENTER is executed, it will send the measurement of the SINIT
> ACM to the TPM and that will cause the TPM to reset the DRTM PCRs (17-23) to
> 0 and then extend PCR 17 with the hash of SINIT.  SINIT will then execute
> and extend more values into PCR 17, as described in sec. 1.9.1 of the TXT
> MLE Developers Guide.
>
> PCR 18 is extended with the SHA-1 hash of the MLE.
>
Warning, bit of a rant here.

Let's suppose I want to prove to someone that I'm running a certain
open-source piece of code, with a known hash. I want to prove that there is
a particular key that can only be used for decryption by this particular
piece of code. If that someone encrypts data to that key and sends it to me,
he can have confidence that only this particular piece of code will be able
to decrypt the data and process it. Since he knows what the code does (he
has the complete source and binary) he can have confidence in how his data
will be handled.

To me, this is the fundamental problem statement that trusted computing aims
to solve. It is where the name comes from. That person has reason to TRUST
the COMPUTING which will be done on his data.

TXT comes close to enabling this. It is a step forward because it reduces
the amount of code that has to be trusted to behave properly. With regular
TPMs you have the whole BIOS, all the other firmware that runs at boot time.
Who knows what's in there. With TXT you have less.

But not that much less. The problem is mentioned in the quote above: the
SINIT module. What is this? What is in it? Who writes it? Is he competent?
Is he trustworthy?

The need to trust an opaque software entity, the SINIT module, is a huge
barrier to achieving the goal I laid out above. It forces everyone who wants
to use TXT to trust Intel or whomever else supplies the SINIT module.

The fact that the SINIT module gets hashed into the PCRs is only a slight
aid. Yes, the challenger can determine that a particular SINIT module was
used. But what does that tell him about how trustworthy it is? Nothing much.

Supposedly there is a signature on the SINIT module which gets verified by
some Intel microcode, so the mere fact that the PCRs correspond to a
particular SINIT module hash is evidence that the SINIT module was created
by Intel, or someone they trust. But these modules are being updated
periodically, and no one is told why. Were the old ones bad? Did they have
security flaws? Should verifiers blacklist certain SINIT modules? There is
nothing but silence on these issues.

Challengers are not even allowed, by licensing restrictions, to disassemble
SINIT.

But it is absurd that we should even be considering such a step! Surely the
obvious way forward is to publish the source code of the SINIT module, along
with the build scripts and tool versions to allow any third party to confirm
that a given SINIT source code produces a certain binary object file and a
certain hash. This will provide transparency into the one major piece of
code which everyone must trust, in order to use TXT.

Without this transparency, the goal of Trusted Computing cannot be met.
Users will never have solid ground to trust the attestations and signatures
from a TXT protected module as long as there is a black box in the middle
labelled "TRUST ME". Trust has to be earned, and the way to earn it when you
are dealing with source code is to publish the code. That is the only
mechanism which can allow trust to be based on reason rather than blind
faith.

I hope Intel is aware of how different these issues look from the outside
versus from the inside. Of course Intel trusts SINIT; they can see what is
in it! Imagine if some employee was responsible for this module and insisted
on hiding the source code and providing the company only a binary image,
promising that it did what it was supposed to. Obviously this would be
intolerable in business. Well, that is exactly how the present practices
look from outside.

TXT has been around quite some time
now. SINIT has gone through several iterations. Isn't it time to take
the next logical step and remove this major obstacle to a fully
transparent and truly trustworthy Trusted Computing technology?

Rant off!

Hal Finney

Re: [tboot-devel] tboot

[Cihula, J. <jos...@in...>]

Below (prefixed w/ '[JC]')

From: Anthony Dessiatnikoff [mailto:ade...@go...]
Sent: Wednesday, June 17, 2009 4:56 AM
To: Cihula, Joseph
Subject: Re: tboot

Hi,

Thanks for your fast answer.

I finally installed the trousers package with devel (so trousers and tpm-tools are working) but for tboot, the problem is still here.

I am trying to understand how TXT is working.

So, I have some questions about TXT and TPM:

- How the values of PCRs are calculated in the first place to be compared to ? Are they provided directly by manufacturers or is it necessary to run an init code (assuming there is no malicious softwares installed...) ?
[JC]  When SENTER is executed, it will send the measurement of the SINIT ACM to the TPM and that will cause the TPM to reset the DRTM PCRs (17-23) to 0 and then extend PCR 17 with the hash of SINIT.  SINIT will then execute and extend more values into PCR 17, as described in sec. 1.9.1 of the TXT MLE Developers Guide.
PCR 18 is extended with the SHA-1 hash of the MLE.

- Is there a SML (Stored Measurement Log) file used like described by the TCG ?
[JC]  The "log" of what is measured into PCR 17, as described in sec. 1.9.1, is contained (mainly) in the SinitMleData struct.

- Is Xen necessary to use TXT or is it just for tboot ?
[JC]  tboot is a "generic" launcher in the sense that it does not really know or care about what it launches.  That said, it only currently knows how to launch a Linux kernel or an ELF binary (which Xen is).  But it could easily be enhanced to understand other file formats.  tboot contains most of the TXT logic.

- I am able to seal data with tpm-tools (tpm_sealdata) but how can I unseal data ? I saw in the TSS the tpm_UnsealFile function but for beginning I would like to use a command line if possible.
[JC]  tpm-tools doesn't provide a command line utility to unseal data, unfortunately.  However the function tpmUnsealFile() in libtpm_unseal does almost exactly this and would only require a trivial wrapper to make into an executable (caveat: I haven't tried this myself).  You can get more info on its man page, tpmUnsealFile(3).

I hope my questions are clearly enough, tell me if it is not.

Many thanks.

Best regards,


2009/6/15 Cihula, Joseph <jos...@in...<mailto:jos...@in...>>

I'm glad to hear that you're working with tboot and Intel TXT.



For building TrouSerS, you need to make sure that you have all the dependent packages installed, per the README file.  You may also be able to find a trousers package (you would need a -devel package).



TXT only uses PCRs 17 & 18.  The SRTM PCRs (0-15) are used by regular software during a normal boot.  The other DRTM PCRs (19-23) are available for software (e.g. tboot) to use.



Joe



From: Anthony Dessiatnikoff [mailto:ade...@go...<mailto:ade...@go...>]
Sent: Monday, June 15, 2009 7:54 AM
To: Cihula, Joseph
Subject: tboot



Hi,

I am a student and I am studying the Trusted Execution Technology from Intel and the use with TPM.

I would like some information about tboot because I cannot succeed to compile it ...

When I build with the 'make' command, there is a lot of errors (some variables are not declared, ...) in the Trousers directory, I think I missed something.

Is there some actions to perform before compiling (like replacing some folders) ? (I followed the README instructions so I configured it)

For information, I am on Ubuntu 8.10 with Xen 3.4 installed. I downloaded tboot from sourceforge.

Another question: in the MLE developer's guide, only the PCRs 17 and 18 are described but not the others, so what are they for ?

Thanks for your time.

Best regards,

--
Anthony Dessiatnikoff
Student from the University of Limoges (France) in Systems Security and Cryptology



--
Anthony Dessiatnikoff
Master 2 Systems Security and Cryptology
University of Limoges (France)

Re: [tboot-devel] Using LCP type unsigned and policy list files

[Ross P. <Ros...@ci...>]

>  I just gave this a try with the current code and it worked fine.  Don't forget to include the command line when invoking lcp_mlehash and to re-provision (lcp_writepol) to TPM NV after generating a new policy/policy data.

[RJP] Yes it is all working correctly. I am not sure what I was doing wrong earlier - I must have forgotten a step or something. All good now, thanks.

Ross

From: Cihula, Joseph [mailto:jos...@in...]
Sent: Monday, April 13, 2009 5:42 PM
To: Ross Philipson; tbo...@li...
Subject: RE: Using LCP type unsigned and policy list files

From: Ross Philipson [mailto:Ros...@ci...]
Sent: Friday, April 10, 2009 4:33 PM
To: tbo...@li...
Subject: [tboot-devel] Using LCP type unsigned and policy list files

I have run into a couple of issues trying to used the unsigned LCP type and external policy list files. There are basically two things I wanted to ask about and/or bring up.

1. I am trying to use lcp_crtpol to create a type unsigned policy but there doesn't seem to be a way to specify more than one mle hash as input. Looking at the code in crtpol.c for create_policy(), the count of mle hashes seems to always be 1 though the routine lcp_create_unsigned_poldata() would load multiple ones if there were any. It looks like only one entry in listdata[] is ever initialized. Maybe I am missing something - any clarification would be great.

[JC]  The code will create one hash for each hash (20 pairs of hex chars) in the mle file (as specified by the '-m' option).  So to create a file with multiple hashes, just concatenate the output of lcp_mlehash into the file.  listdata[] is not the lit of hashes, but rather the list of policy elements (e.g. MLE hashes and/or platform configurations).  All MLE hashes will be in one list.

I just gave this a try with the current code and it worked fine.  Don't forget to include the command line when invoking lcp_mlehash and to re-provision (lcp_writepol) to TPM NV after generating a new policy/policy data.

2. I came across an odd hang in xen when I put the LCP data module at the end of the list of modules in grub. If I move the LCP data module say in front of the sinit module, the hang goes away. This only happens when tboot does an un-trusted launch (since in the trusted case, it removes sinit and lcp modules from mbi). It has something to do with the module moving code in __start_xen(). I am going to investigate it further to see if it is a bug in xen (I think it might be related to the very small size of the LCP data module). Anyway, in looking at the tboot code I was thinking it might make sense to pop any sinit and lcp modules out of the mbi module list even in the case where tboot doesn't to a trusted launch as is the case in a trusted launch. The next level kernel modules do not need to see these modules whether it is a trusted boot or not. If folks thinks this is a good idea, I can submit a patch.

[JC]  tboot should definitely be removing both the SINIT and policy files before launching the VMM/kernel regardless of success or failure.  A patch would be greatly appreciated.

Thanks
Ross

Ross Philipson
Senior Software Engineer
Citrix Systems, Inc
14 Crosby Drive
Bedford, MA 01730
781-301-7949
ros...@ci...<mailto:ros...@ci...>

Re: [tboot-devel] Using LCP type unsigned and policy list files

[Cihula, J. <jos...@in...>]

From: Ross Philipson [mailto:Ros...@ci...]
Sent: Friday, April 10, 2009 4:33 PM
To: tbo...@li...
Subject: [tboot-devel] Using LCP type unsigned and policy list files

I have run into a couple of issues trying to used the unsigned LCP type and external policy list files. There are basically two things I wanted to ask about and/or bring up.

1. I am trying to use lcp_crtpol to create a type unsigned policy but there doesn't seem to be a way to specify more than one mle hash as input. Looking at the code in crtpol.c for create_policy(), the count of mle hashes seems to always be 1 though the routine lcp_create_unsigned_poldata() would load multiple ones if there were any. It looks like only one entry in listdata[] is ever initialized. Maybe I am missing something - any clarification would be great.

[JC]  The code will create one hash for each hash (20 pairs of hex chars) in the mle file (as specified by the '-m' option).  So to create a file with multiple hashes, just concatenate the output of lcp_mlehash into the file.  listdata[] is not the lit of hashes, but rather the list of policy elements (e.g. MLE hashes and/or platform configurations).  All MLE hashes will be in one list.

I just gave this a try with the current code and it worked fine.  Don't forget to include the command line when invoking lcp_mlehash and to re-provision (lcp_writepol) to TPM NV after generating a new policy/policy data.

2. I came across an odd hang in xen when I put the LCP data module at the end of the list of modules in grub. If I move the LCP data module say in front of the sinit module, the hang goes away. This only happens when tboot does an un-trusted launch (since in the trusted case, it removes sinit and lcp modules from mbi). It has something to do with the module moving code in __start_xen(). I am going to investigate it further to see if it is a bug in xen (I think it might be related to the very small size of the LCP data module). Anyway, in looking at the tboot code I was thinking it might make sense to pop any sinit and lcp modules out of the mbi module list even in the case where tboot doesn't to a trusted launch as is the case in a trusted launch. The next level kernel modules do not need to see these modules whether it is a trusted boot or not. If folks thinks this is a good idea, I can submit a patch.

[JC]  tboot should definitely be removing both the SINIT and policy files before launching the VMM/kernel regardless of success or failure.  A patch would be greatly appreciated.

Thanks
Ross

Ross Philipson
Senior Software Engineer
Citrix Systems, Inc
14 Crosby Drive
Bedford, MA 01730
781-301-7949
ros...@ci...<mailto:ros...@ci...>

[tboot-devel] Using LCP type unsigned and policy list files

[Ross P. <Ros...@ci...>]

I have run into a couple of issues trying to used the unsigned LCP type and external policy list files. There are basically two things I wanted to ask about and/or bring up.

1. I am trying to use lcp_crtpol to create a type unsigned policy but there doesn't seem to be a way to specify more than one mle hash as input. Looking at the code in crtpol.c for create_policy(), the count of mle hashes seems to always be 1 though the routine lcp_create_unsigned_poldata() would load multiple ones if there were any. It looks like only one entry in listdata[] is ever initialized. Maybe I am missing something - any clarification would be great.

2. I came across an odd hang in xen when I put the LCP data module at the end of the list of modules in grub. If I move the LCP data module say in front of the sinit module, the hang goes away. This only happens when tboot does an un-trusted launch (since in the trusted case, it removes sinit and lcp modules from mbi). It has something to do with the module moving code in __start_xen(). I am going to investigate it further to see if it is a bug in xen (I think it might be related to the very small size of the LCP data module). Anyway, in looking at the tboot code I was thinking it might make sense to pop any sinit and lcp modules out of the mbi module list even in the case where tboot doesn't to a trusted launch as is the case in a trusted launch. The next level kernel modules do not need to see these modules whether it is a trusted boot or not. If folks thinks this is a good idea, I can submit a patch.

Thanks
Ross

Ross Philipson
Senior Software Engineer
Citrix Systems, Inc
14 Crosby Drive
Bedford, MA 01730
781-301-7949
ros...@ci...<mailto:ros...@ci...>

Re: [tboot-devel] stuck on GETSEC[SENTER]

[Alana L. <al...@cs...>]

On Fri, 10 Apr 2009, Cihula, Joseph wrote:

> The problem is that your kernel does not have VT-d (Intel's IOMMU) support in it.  So even though you specify 'intel_iommu=on' in the command line, it gets ignored.  You can verify if your .config has CONFIG_DMAR set (which we will add as a dependency in the next patch update).
>
> The issue is that tboot is DMA protecting memory and without VT-d support the kernel never un-protects it.  So all DMA fails.
>
> Joe

That was it! I did not have CONFIG_DMAR set, so I set it, recompiled, and 
now booting proceeds normally. Thank you so much for your help!

-- Alana

Re: [tboot-devel] stuck on GETSEC[SENTER]

[Cihula, J. <jos...@in...>]

> From: Alana Libonati [mailto:al...@cs...]
> Sent: Friday, April 10, 2009 10:21 AM
>
> On Thu, 9 Apr 2009, Cihula, Joseph wrote:
>
> > OK, this is due to the SMM handler not liking that its legacy USB buffer is DMA protected.
> And it is DMA protected because of that single usable page above all the reserved regions.
> The same single page above the reserved regions was found on another system as well, so I'm in
> the process of figuring out the best way to accommodate ACPI regions in the middle of usable
> memory (I'd really like to avoid a hack that just looks for a single page at the top).
>
> Oh, I see.
>
> > The SIPI line indicates that the kernel booted and brought the AP out of tboot.  At this
> point, it would seem to be a kernel issue, though possibly in the tboot patch.  You'll need to
> get the dmesg log (or serial if you've set the kernel to output there).
>
> So I took a look at the full log, and it does seem to be a kernel issue
> since I get the same behavior with both the unpatched, generic kernel and
> the tboot patched one. It does, however, only happen when I am using tboot
> (I can boot straight into Linux without issue). I'll post one of those
> logs below to see if that tells us anything. If not, or if this is
> directly related to the issue you mentioned above, I guess I'll just have
> to sit tight until some patch/workaround is released?
>
> This is the log from the tboot patched kernel. The generic kernel fails in
> a very similar way, but does not end with the Call Traces seen here at
> the end (the last thing I see there are the ohci1394 errors after the
> ata2 errors).

The problem is that your kernel does not have VT-d (Intel's IOMMU) support in it.  So even though you specify 'intel_iommu=on' in the command line, it gets ignored.  You can verify if your .config has CONFIG_DMAR set (which we will add as a dependency in the next patch update).

The issue is that tboot is DMA protecting memory and without VT-d support the kernel never un-protects it.  So all DMA fails.

Joe

>
> Thanks,
> Alana
>
> TBOOT: ******************* TBOOT *******************
> TBOOT:    unavailable
> TBOOT: *********************************************
> TBOOT: command line: logging=serial,vga,memory
> TBOOT: TPM is ready
> TBOOT: TPM nv_locked: TRUE
> TBOOT: TPM: get capability, return value = 00000002
> TBOOT: failed to get actual policy size in TPM NV
> TBOOT: failed to read policy from TPM NV, using default
> TBOOT: policy:
> TBOOT:         version: 2
> TBOOT:         policy_type: TB_POLTYPE_CONT_NON_FATAL
> TBOOT:         hash_alg: TB_HALG_SHA1
> TBOOT:         policy_control: 00000001 (EXTEND_PCR17)
> TBOOT:         num_entries: 2
> TBOOT:         policy entry[0]:
> TBOOT:                 mod_num: 0
> TBOOT:                 pcr: none
> TBOOT:                 hash_type: TB_HTYPE_ANY
> TBOOT:                 num_hashes: 0
> TBOOT:         policy entry[1]:
> TBOOT:                 mod_num: any
> TBOOT:                 pcr: 19
> TBOOT:                 hash_type: TB_HTYPE_ANY
> TBOOT:                 num_hashes: 0
> TBOOT: TPM: write nv 20000002, offset 00000000, 00000004 bytes, return = 00000002
> TBOOT: Error: write TPM error: 0x2.
> TBOOT: no policy in TPM NV.
> TBOOT: IA32_FEATURE_CONTROL_MSR: 0000ff0f
> TBOOT: CPU is SMX-capable
> TBOOT: CPU is VMX-capable
> TBOOT: SMX is enabled
> TBOOT: TXT chipset and all needed capabilities present
> TBOOT: TPM: write nv 20000002, offset 00000000, 00000004 bytes, return = 00000002
> TBOOT: Error: write TPM error: 0x2.
> TBOOT: LT.ERRORCODE=0
> TBOOT: LT.ESTS=0
> TBOOT: bios_data (@bc920008, 2c):
> TBOOT:         version: 3
> TBOOT:         bios_sinit_size: 0x0 (0)
> TBOOT:         lcp_pd_base: 0x0
> TBOOT:         lcp_pd_size: 0x0 (0)
> TBOOT:         num_logical_procs: 2
> TBOOT:         flags: 0x00000001
> TBOOT: TPM: write nv 20000002, offset 00000000, 00000004 bytes, return = 00000002
> TBOOT: Error: write TPM error: 0x2.
> TBOOT: CR0 and EFLAGS OK
> TBOOT: no machine check errors
> TBOOT: CPU is ready for SENTER
> TBOOT: checking previous errors on the last boot.
>       TPM: read nv index 20000002 offset 00000000, return value = 00000002
> TBOOT: Error: read TPM error: 0x2.
> TBOOT: last boot has no error.
> TBOOT: user-provided SINIT found: /boot/GM45_PM45_SINIT_19.BIN
> TBOOT: chipset ids: vendor=8086, device=9000, revision=7f
> TBOOT: 1 ACM chipset id entries:
> TBOOT:        vendor=8086, device=9000, flags=1, revision=3f, extended=0
> TBOOT: copied SINIT (size=67c0) to bc900000
> TBOOT: AC mod base alignment OK
> TBOOT: AC mod size OK
> TBOOT: AC module header dump for SINIT:
> TBOOT:         type: 0x2 (ACM_TYPE_CHIPSET)
> TBOOT:         length: 0xa1 (161)
> TBOOT:         version: 0
> TBOOT:         chipset_id: 0x2a40
> TBOOT:         flags: 0x0
> TBOOT:                 pre_production: 0
> TBOOT:                 debug_signed: 0
> TBOOT:         vendor: 0x8086
> TBOOT:         date: 0x20081017
> TBOOT:         size*4: 0x67c0 (26560)
> TBOOT:         code_control: 0x0
> TBOOT:         entry point: 0x00000008:00004120
> TBOOT:         scratch_size: 0x8f (143)
> TBOOT:         info_table:
> TBOOT:                 uuid: {0x7fc03aaa, 0x46a7, 0x18db, 0xac2e,
>               {0x69, 0x8f, 0x8d, 0x41, 0x7f, 0x5a}}
> TBOOT:                     ACM_UUID_V3
> TBOOT:                 chipset_acm_type: 0x1 (SINIT)
> TBOOT:                 version: 3
> TBOOT:                 length: 0x28 (40)
> TBOOT:                 chipset_id_list: 0x4e8
> TBOOT:                 os_sinit_data_ver: 0x4
> TBOOT:                 min_mle_hdr_ver: 0x00020000
> TBOOT:                 capabilities: 0x00000002
> TBOOT:                     rlp_wake_getsec: 0
> TBOOT:                     rlp_wake_monitor: 1
> TBOOT:                 acm_ver: 19
> TBOOT:         chipset list:
> TBOOT:                 count: 1
> TBOOT:                 entry 0:
> TBOOT:                     flags: 0x1
> TBOOT:                     vendor_id: 0x8086
> TBOOT:                     device_id: 0x9000
> TBOOT:                     revision_id: 0x3f
> TBOOT:                     extended_id: 0x0
> TBOOT: file addresses:
> TBOOT:         &_start=00803000
> TBOOT:         &_end=0084fc4c
> TBOOT:         &_mle_start=00803000
> TBOOT:         &_mle_end=00822000
> TBOOT:         &_post_launch_entry=00803020
> TBOOT:         &_txt_wakeup=008031f0
> TBOOT:         &g_mle_hdr=00819120
> TBOOT: MLE header:
> TBOOT:         uuid={0x9082ac5a, 0x476f, 0x74a7, 0x5c0f,
>               {0x55, 0xa2, 0xcb, 0x51, 0xb6, 0x42}}
> TBOOT:         length=34
> TBOOT:         version=00020001
> TBOOT:         entry_point=00000020
> TBOOT:         first_valid_page=00000000
> TBOOT:         mle_start_off=0
> TBOOT:         mle_end_off=1f000
> TBOOT:         capabilities: 0x00000003
> TBOOT:             rlp_wake_getsec: 1
> TBOOT:             rlp_wake_monitor: 1
> TBOOT: MLE start=803000, end=822000, size=1f000
> TBOOT: ptab_size=3000, ptab_base=00800000
> TBOOT: bios_data (@bc920008, 2c):
> TBOOT:         version: 3
> TBOOT:         bios_sinit_size: 0x0 (0)
> TBOOT:         lcp_pd_base: 0x0
> TBOOT:         lcp_pd_size: 0x0 (0)
> TBOOT:         num_logical_procs: 2
> TBOOT:         flags: 0x00000001
> TBOOT: min_lo_ram: 0x0, max_lo_ram: 0xbc700000
> TBOOT: min_hi_ram: 0x0, max_hi_ram: 0x0
> TBOOT: no LCP manifest found
> TBOOT: os_sinit_data (@bc920154, 5c):
> TBOOT:         version: 4
> TBOOT:         mle_ptab: 0x800000
> TBOOT:         mle_size: 0x1f000 (126976)
> TBOOT:         mle_hdr_base: 0x16120
> TBOOT:         vtd_pmr_lo_base: 0x0
> TBOOT:         vtd_pmr_lo_size: 0xbc600000
> TBOOT:         vtd_pmr_hi_base: 0x0
> TBOOT:         vtd_pmr_hi_size: 0x0
> TBOOT:         lcp_po_base: 0x0
> TBOOT:         lcp_po_size: 0x0 (0)
> TBOOT:         capabilities: 0x00000002
> TBOOT:             rlp_wake_getsec: 0
> TBOOT:             rlp_wake_monitor: 1
> TBOOT: setting MTRRs for acmod: base=bc900000, size=67c0, num_pages=7
> TBOOT: executing GETSEC[SENTER]...
> TBOOT: ******************* TBOOT *******************
> TBOOT:    unavailable
> TBOOT: *********************************************
> TBOOT: command line: logging=serial,vga,memory
> TBOOT: TPM is ready
> TBOOT: TPM nv_locked: TRUE
> TBOOT: TPM: get capability, return value = 00000002
> TBOOT: failed to get actual policy size in TPM NV
> TBOOT: failed to read policy from TPM NV, using default
> TBOOT: policy:
> TBOOT:         version: 2
> TBOOT:         policy_type: TB_POLTYPE_CONT_NON_FATAL
> TBOOT:         hash_alg: TB_HALG_SHA1
> TBOOT:         policy_control: 00000001 (EXTEND_PCR17)
> TBOOT:         num_entries: 2
> TBOOT:         policy entry[0]:
> TBOOT:                 mod_num: 0
> TBOOT:                 pcr: none
> TBOOT:                 hash_type: TB_HTYPE_ANY
> TBOOT:                 num_hashes: 0
> TBOOT:         policy entry[1]:
> TBOOT:                 mod_num: any
> TBOOT:                 pcr: 19
> TBOOT:                 hash_type: TB_HTYPE_ANY
> TBOOT:                 num_hashes: 0
> TBOOT: TPM: write nv 20000002, offset 00000000, 00000004 bytes, return = 00000002
> TBOOT: Error: write TPM error: 0x2.
> TBOOT: no policy in TPM NV.
> TBOOT: IA32_FEATURE_CONTROL_MSR: 0000ff0f
> TBOOT: CPU is SMX-capable
> TBOOT: CPU is VMX-capable
> TBOOT: SMX is enabled
> TBOOT: TXT chipset and all needed capabilities present
> TBOOT: TPM: write nv 20000002, offset 00000000, 00000004 bytes, return = 00000002
> TBOOT: Error: write TPM error: 0x2.
> TBOOT: LT.ERRORCODE=c0000001
> TBOOT: AC module error : acm_type=1, progress=00, error=0
> TBOOT: LT.ESTS=0
> TBOOT: bios_data (@bc920008, 2c):
> TBOOT:         version: 3
> TBOOT:         bios_sinit_size: 0x0 (0)
> TBOOT:         lcp_pd_base: 0x0
> TBOOT:         lcp_pd_size: 0x0 (0)
> TBOOT:         num_logical_procs: 2
> TBOOT:         flags: 0x00000001
> TBOOT: TPM: write nv 20000002, offset 00000000, 00000004 bytes, return = 00000002
> TBOOT: Error: write TPM error: 0x2.
> TBOOT: measured launch succeeded
> TBOOT: bios_data (@bc920008, 2c):
> TBOOT:         version: 3
> TBOOT:         bios_sinit_size: 0x0 (0)
> TBOOT:         lcp_pd_base: 0x0
> TBOOT:         lcp_pd_size: 0x0 (0)
> TBOOT:         num_logical_procs: 2
> TBOOT:         flags: 0x00000001
> TBOOT: os_mle_data (@bc920034, 120):
> TBOOT:         version: 1
> TBOOT:         mbi: 0x00030c30
> TBOOT: os_sinit_data (@bc920154, 5c):
> TBOOT:         version: 4
> TBOOT:         mle_ptab: 0x800000
> TBOOT:         mle_size: 0x1f000 (126976)
> TBOOT:         mle_hdr_base: 0x16120
> TBOOT:         vtd_pmr_lo_base: 0x0
> TBOOT:         vtd_pmr_lo_size: 0xbc600000
> TBOOT:         vtd_pmr_hi_base: 0x0
> TBOOT:         vtd_pmr_hi_size: 0x0
> TBOOT:         lcp_po_base: 0x0
> TBOOT:         lcp_po_size: 0x0 (0)
> TBOOT:         capabilities: 0x00000002
> TBOOT:             rlp_wake_getsec: 0
> TBOOT:             rlp_wake_monitor: 1
> TBOOT: sinit_mle_data (@bc9201b0, 260):
> TBOOT:         version: 6
> TBOOT:         bios_acm_id:
>       80 00 00 00 20 08 05 15 00 00 2a 40 00 00 00 00 ff ff ff ff
> TBOOT:         edx_senter_flags: 0x00000000
> TBOOT:         mseg_valid: 0x0
> TBOOT:         sinit_hash:
>       e4 fd 97 66 c4 11 b3 30 54 be 1b 63 19 70 0a ed c0 bc 23 bb
> TBOOT:         mle_hash:
>       0e f8 c4 7f 34 d6 19 ba ad 39 3f e0 ad 5a 00 3b 0a 9d 18 56
> TBOOT:         stm_hash:
>       00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> TBOOT:         lcp_policy_hash:
>       00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> TBOOT:         lcp_policy_control: 0x00000000
> TBOOT:         rlp_wakeup_addr: 0xbc9019a0
> TBOOT:         num_mdrs: 7
> TBOOT:         mdrs_off: 0x98
> TBOOT:         num_vtd_dmars: 288
> TBOOT:         vtd_dmars_off: 0x140
> TBOOT:         sinit_mdrs:
> TBOOT:                 0000000000000000 - 00000000000a0000 (GOOD)
> TBOOT:                 0000000000100000 - 0000000001000000 (GOOD)
> TBOOT:                 0000000001000000 - 00000000bc900000 (GOOD)
> TBOOT:                 0000000000000000 - 0000000000000000 (GOOD)
> TBOOT:                 0000000000000000 - 0000000000000000 (GOOD)
> TBOOT:                 00000000bca00000 - 00000000bcc00000 (SMRAM NON-OVERLAY)
> TBOOT:                 00000000e0000000 - 00000000f0000000 (PCIE EXTENDED CONFIG)
> TBOOT: RSDP (v002 LENOVO) @ 0x000f64e0
> TBOOT: Seek in XSDT...
> TBOOT: entry[0] sig = FACP @ 0xbc66a400
> TBOOT: entry[1] sig = SSDT @ 0xbc66a5b4
> TBOOT: entry[2] sig = ECDT @ 0xbc679bd6
> TBOOT: entry[3] sig = APIC @ 0xbc679c28
> TBOOT: acpi_table_ioapic @ bc679c74, .address = fec00000
> TBOOT: RSDP (v002 LENOVO) @ 0x000f64e0
> TBOOT: Seek in XSDT...
> TBOOT: entry[0] sig = FACP @ 0xbc66a400
> TBOOT: entry[1] sig = SSDT @ 0xbc66a5b4
> TBOOT: entry[2] sig = ECDT @ 0xbc679bd6
> TBOOT: entry[3] sig = APIC @ 0xbc679c28
> TBOOT: entry[4] sig = MCFG @ 0xbc679ca0
> TBOOT: acpi_table_mcfg @ bc679ca0, .base_address = e0000000
> TBOOT: mtrr_def_type: e = 1, fe = 1, type = 0
> TBOOT: mtrrs:
> TBOOT:                base    mask    type    v
> TBOOT:                0bd000  fff000  00      1
> TBOOT:                0be000  ffe000  00      1
> TBOOT:                000000  f80000  06      1
> TBOOT:                080000  fc0000  06      1
> TBOOT:                0bce00  fffe00  00      1
> TBOOT:                000000  000000  00      0
> TBOOT:                000000  000000  00      0
> TBOOT: min_lo_ram: 0x0, max_lo_ram: 0xbc700000
> TBOOT: min_hi_ram: 0x0, max_hi_ram: 0x0
> TBOOT: mle_join.entry_point = 8031f0
> TBOOT: mle_join.seg_sel = 8
> TBOOT: mle_join.gdt_base = 804000
> TBOOT: mle_join.gdt_limit = 3f
> TBOOT: joining RLPs to MLE with MONITOR wakeup
> TBOOT: rlp_wakeup_addr = 0xbc9019a0
> TBOOT: cpu 1 waking up from TXT sleep
> TBOOT: waiting for all APs (1) to enter wait-for-sipi...
> TBOOT: enabling SMIs on cpu 1
> TBOOT: .VMXON done for cpu 1
> TBOOT:
> TBOOT: launching mini-guest for cpu 1
> TBOOT:
> TBOOT: all APs in wait-for-sipi
> TBOOT: enabling SMIs on BSP
> TBOOT: saved IA32_MISC_ENABLE = 0x64972481
> TBOOT: set LT.CMD.SECRETS flag
> TBOOT: opened TPM locality 1
> TBOOT: TPM: write nv 20000002, offset 00000000, 00000004 bytes, return = 00000002
> TBOOT: Error: write TPM error: 0x2.
> TBOOT: RSDP (v002 LENOVO) @ 0x000f64e0
> TBOOT: Seek in XSDT...
> TBOOT: entry[0] sig = FACP @ 0xbc66a400
> TBOOT: entry[1] sig = SSDT @ 0xbc66a5b4
> TBOOT: entry[2] sig = ECDT @ 0xbc679bd6
> TBOOT: entry[3] sig = APIC @ 0xbc679c28
> TBOOT: entry[4] sig = MCFG @ 0xbc679ca0
> TBOOT: entry[5] sig = HPET @ 0xbc679cdc
> TBOOT: entry[6] sig = SLIC @ 0xbc679dc2
> TBOOT: entry[7] sig = BOOT @ 0xbc679f38
> TBOOT: entry[8] sig = ASF! @ 0xbc679f60
> TBOOT: entry[9] sig = SSDT @ 0xbc68d213
> TBOOT: entry[10] sig = TCPA @ 0xbc407000
> TBOOT: entry[11] sig = DMAR @ 0xbc406000
> TBOOT: DMAR table @ 0xbc406000 saved.
> TBOOT: original e820 map:
> TBOOT:        0000000000000000 - 000000000009ac00  (1)
> TBOOT:        000000000009ac00 - 00000000000a0000  (2)
> TBOOT:        00000000000d6000 - 00000000000d8000  (2)
> TBOOT:        00000000000e0000 - 0000000000100000  (2)
> TBOOT:        0000000000100000 - 00000000bc1a1000  (1)
> TBOOT:        00000000bc1a1000 - 00000000bc1a7000  (2)
> TBOOT:        00000000bc1a7000 - 00000000bc2b7000  (1)
> TBOOT:        00000000bc2b7000 - 00000000bc30f000  (2)
> TBOOT:        00000000bc30f000 - 00000000bc3c6000  (1)
> TBOOT:        00000000bc3c6000 - 00000000bc3d1000  (4)
> TBOOT:        00000000bc3d1000 - 00000000bc3d4000  (3)
> TBOOT:        00000000bc3d4000 - 00000000bc3d8000  (2)
> TBOOT:        00000000bc3d8000 - 00000000bc3dc000  (4)
> TBOOT:        00000000bc3dc000 - 00000000bc3df000  (2)
> TBOOT:        00000000bc3df000 - 00000000bc406000  (4)
> TBOOT:        00000000bc406000 - 00000000bc408000  (3)
> TBOOT:        00000000bc408000 - 00000000bc60f000  (2)
> TBOOT:        00000000bc60f000 - 00000000bc69f000  (4)
> TBOOT:        00000000bc69f000 - 00000000bc6ff000  (3)
> TBOOT:        00000000bc6ff000 - 00000000bc700000  (1)
> TBOOT:        00000000bcc00000 - 00000000bf000000  (2)
> TBOOT:        00000000e0000000 - 00000000f0000000  (2)
> TBOOT:        00000000fec00000 - 00000000fec10000  (2)
> TBOOT:        00000000fed00000 - 00000000fed00400  (2)
> TBOOT:        00000000fed10000 - 00000000fed14000  (2)
> TBOOT:        00000000fed18000 - 00000000fed19000  (2)
> TBOOT:        00000000fed19000 - 00000000fed1a000  (2)
> TBOOT:        00000000fed1c000 - 00000000fed20000  (2)
> TBOOT:        00000000fed20000 - 00000000fed90000  (2)
> TBOOT:        00000000fee00000 - 00000000fee01000  (2)
> TBOOT:        00000000ff800000 - 0000000100000000  (2)
> TBOOT: verifying module 0 of mbi (851000 - aa624f) in e820 table
>        (range from 0000000000851000 to 0000000000aa6250 is in E820_RAM)
> TBOOT: : succeeded.
> TBOOT: verifying module 1 of mbi (aa7000 - 93777ff) in e820 table
>        (range from 0000000000aa7000 to 0000000009377800 is in E820_RAM)
> TBOOT: : succeeded.
> TBOOT: protecting TXT heap (bc920000 - bc9fffff) in e820 table
> TBOOT: protecting SINIT (bc900000 - bc91ffff) in e820 table
> TBOOT: protecting TXT Private Space (fed20000 - fed2ffff) in e820 table
> TBOOT: verifying e820 table against SINIT MDRs: verification succeeded.
> TBOOT: reserving 0xbc600000 - 0xbc700000, which was truncated for VT-d
> TBOOT: TPM: write nv 20000002, offset 00000000, 00000004 bytes, return = 00000002
> TBOOT: Error: write TPM error: 0x2.
> TBOOT: verifying tboot and its page table (800000 - 84fc4b) in e820 table
>        (range from 0000000000800000 to 000000000084fc4c is in E820_RAM)
> TBOOT: : succeeded.
> TBOOT: protecting tboot (800000 - 9fffff) in e820 table
> TBOOT: reserving tboot memory log (60000 - 67fff) in e820 table
> TBOOT: adjusted e820 map:
> TBOOT:        0000000000000000 - 0000000000060000  (1)
> TBOOT:        0000000000060000 - 0000000000068000  (2)
> TBOOT:        0000000000068000 - 000000000009ac00  (1)
> TBOOT:        000000000009ac00 - 00000000000a0000  (2)
> TBOOT:        00000000000d6000 - 00000000000d8000  (2)
> TBOOT:        00000000000e0000 - 0000000000100000  (2)
> TBOOT:        0000000000100000 - 0000000000800000  (1)
> TBOOT:        0000000000800000 - 0000000000a00000  (5)
> TBOOT:        0000000000a00000 - 00000000bc1a1000  (1)
> TBOOT:        00000000bc1a1000 - 00000000bc1a7000  (2)
> TBOOT:        00000000bc1a7000 - 00000000bc2b7000  (1)
> TBOOT:        00000000bc2b7000 - 00000000bc30f000  (2)
> TBOOT:        00000000bc30f000 - 00000000bc3c6000  (1)
> TBOOT:        00000000bc3c6000 - 00000000bc3d1000  (4)
> TBOOT:        00000000bc3d1000 - 00000000bc3d4000  (3)
> TBOOT:        00000000bc3d4000 - 00000000bc3d8000  (2)
> TBOOT:        00000000bc3d8000 - 00000000bc3dc000  (4)
> TBOOT:        00000000bc3dc000 - 00000000bc3df000  (2)
> TBOOT:        00000000bc3df000 - 00000000bc406000  (4)
> TBOOT:        00000000bc406000 - 00000000bc408000  (3)
> TBOOT:        00000000bc408000 - 00000000bc60f000  (2)
> TBOOT:        00000000bc60f000 - 00000000bc69f000  (4)
> TBOOT:        00000000bc69f000 - 00000000bc6ff000  (3)
> TBOOT:        00000000bc6ff000 - 00000000bc700000  (2)
> TBOOT:        00000000bc900000 - 00000000bc920000  (2)
> TBOOT:        00000000bc920000 - 00000000bca00000  (2)
> TBOOT:        00000000bcc00000 - 00000000bf000000  (2)
> TBOOT:        00000000e0000000 - 00000000f0000000  (2)
> TBOOT:        00000000fec00000 - 00000000fec10000  (2)
> TBOOT:        00000000fed00000 - 00000000fed00400  (2)
> TBOOT:        00000000fed10000 - 00000000fed14000  (2)
> TBOOT:        00000000fed18000 - 00000000fed19000  (2)
> TBOOT:        00000000fed19000 - 00000000fed1a000  (2)
> TBOOT:        00000000fed1c000 - 00000000fed20000  (2)
> TBOOT:        00000000fed20000 - 00000000fed30000  (2)
> TBOOT:        00000000fed30000 - 00000000fed90000  (2)
> TBOOT:        00000000fee00000 - 00000000fee01000  (2)
> TBOOT:        00000000ff800000 - 0000000100000000  (2)
> TBOOT: TPM: write nv 20000002, offset 00000000, 00000004 bytes, return = 00000002
> TBOOT: Error: write TPM error: 0x2.
> TBOOT: verifying module "/boot/vmlinuz-2.6.29-tip intel_iommu=on root=UUID=96777f17-50b1-43b1-
> 93ba-d9a6a38dfb0d ro rhgb console=ttyS0,       OK : 84 58 e3 ae 68 19 3b 94 ef 9c 10 70 09 b0 e0
> 88 51 7e 16 38
> TBOOT: TPM: write nv 20000002, offset 00000000, 00000004 bytes, return = 00000002
> TBOOT: Error: write TPM error: 0x2.
> TBOOT: verifying module "/boot/initrd.img-2.6.29-tip"...
> TBOOT:         OK : 06 07 f7 d7 71 0a 40 8d 37 a3 e0 c2 d6 51 96 de d5 06 61 7b
> TBOOT: TPM: write nv 20000002, offset 00000000, 00000004 bytes, return = 00000002
> TBOOT: Error: write TPM error: 0x2.
> TBOOT: all modules are verified
> TBOOT: pre_k_s3_state:
> TBOOT:         vtd_pmr_lo_base: 0x0
> TBOOT:         vtd_pmr_lo_size: 0xbc600000
> TBOOT:         vtd_pmr_hi_base: 0x0
> TBOOT:         vtd_pmr_hi_size: 0x0
> TBOOT:         pol_hash: ab 41 62 4e 7d 71 f0 68 d4 8e 1c 2f 43 e6 16 bf 40 67 1c 39
> TBOOT:         VL measurements:
> TBOOT:           PCR 17: 97 04 35 36 30 67 4b fe 21 b8 6b 64 a7 b0 f9 9c 29 7c f9 02
> TBOOT:           PCR 18: 84 58 e3 ae 68 19 3b 94 ef 9c 10 70 09 b0 e0 88 51 7e 16 38
> TBOOT:           PCR 19: 06 07 f7 d7 71 0a 40 8d 37 a3 e0 c2 d6 51 96 de d5 06 61 7b
> TBOOT: PCRs before extending:
> TBOOT:   PCR 17: 3e 1b 3f cb 26 1e 8d 45 2e ba 1a ad 15 dd fd bd 7c e6 e6 23
> TBOOT:   PCR 18: 21 8c e4 8d af 6e 6e 67 fd 58 e0 95 52 72 3c 6b d0 7b cc f5
> TBOOT: PCRs after extending:
> TBOOT:   PCR 17: 17 f1 d3 92 b6 a9 1a 12 aa cf 75 07 fd 89 2b 49 e1 ff c5 e8
> TBOOT:   PCR 18: b1 d0 02 fa b0 74 08 95 a1 5c 4b ea de f9 78 ee 37 e4 57 d3
> TBOOT: tboot_shared data:
> TBOOT:         version: 5
> TBOOT:         log_addr: 0x00060000
> TBOOT:         shutdown_entry: 0x008031b0
> TBOOT:         shutdown_type: 0
> TBOOT:         tboot_base: 0x00803000
> TBOOT:         tboot_size: 0x4cc4c
> TBOOT:         num_in_wfs: 1
> TBOOT: Error: ELF magic number is not matched.
> TBOOT: assuming kernel is Linux format
> TBOOT: Initrd from 0x7772f000 to 0x7ffff800
> TBOOT: Kernel (protected mode) from 0xa00000 to 0xc52050
> TBOOT: Kernel (real mode) from 0x90000 to 0x93200
> TBOOT: transfering control to kernel @0x00a00000...
> [    0.000000] Initializing cgroup subsys cpuset
> [    0.000000] Initializing cgroup subsys cpu
> [    0.000000] Linux version 2.6.29-tip (root@alana-t400) (gcc version 4.3.2 (Ubuntu 4.3.2-
> 1ubuntu12) ) #1 SMP Mon Apr 6 14:58:51 EDT 2009
> [    0.000000] KERNEL supported cpus:
> [    0.000000]   Intel GenuineIntel
> [    0.000000]   AMD AuthenticAMD
> [    0.000000]   NSC Geode by NSC
> [    0.000000]   Cyrix CyrixInstead
> [    0.000000]   Centaur CentaurHauls
> [    0.000000]   Transmeta GenuineTMx86
> [    0.000000]   Transmeta TransmetaCPU
> [    0.000000]   UMC UMC UMC UMC
> [    0.000000] BIOS-provided physical RAM map:
> [    0.000000]  BIOS-e820: 0000000000000000 - 0000000000060000 (usable)
> [    0.000000]  BIOS-e820: 0000000000060000 - 0000000000068000 (reserved)
> [    0.000000]  BIOS-e820: 0000000000068000 - 000000000009ac00 (usable)
> [    0.000000]  BIOS-e820: 000000000009ac00 - 00000000000a0000 (reserved)
> [    0.000000]  BIOS-e820: 00000000000d6000 - 00000000000d8000 (reserved)
> [    0.000000]  BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved)
> [    0.000000]  BIOS-e820: 0000000000100000 - 0000000000800000 (usable)
> [    0.000000]  BIOS-e820: 0000000000800000 - 0000000000a00000 (unusable)
> [    0.000000]  BIOS-e820: 0000000000a00000 - 00000000bc1a1000 (usable)
> [    0.000000]  BIOS-e820: 00000000bc1a1000 - 00000000bc1a7000 (reserved)
> [    0.000000]  BIOS-e820: 00000000bc1a7000 - 00000000bc2b7000 (usable)
> [    0.000000]  BIOS-e820: 00000000bc2b7000 - 00000000bc30f000 (reserved)
> [    0.000000]  BIOS-e820: 00000000bc30f000 - 00000000bc3c6000 (usable)
> [    0.000000]  BIOS-e820: 00000000bc3c6000 - 00000000bc3d1000 (ACPI NVS)
> [    0.000000]  BIOS-e820: 00000000bc3d1000 - 00000000bc3d4000 (ACPI data)
> [    0.000000]  BIOS-e820: 00000000bc3d4000 - 00000000bc3d8000 (reserved)
> [    0.000000]  BIOS-e820: 00000000bc3d8000 - 00000000bc3dc000 (ACPI NVS)
> [    0.000000]  BIOS-e820: 00000000bc3dc000 - 00000000bc3df000 (reserved)
> [    0.000000]  BIOS-e820: 00000000bc3df000 - 00000000bc406000 (ACPI NVS)
> [    0.000000]  BIOS-e820: 00000000bc406000 - 00000000bc408000 (ACPI data)
> [    0.000000]  BIOS-e820: 00000000bc408000 - 00000000bc60f000 (reserved)
> [    0.000000]  BIOS-e820: 00000000bc60f000 - 00000000bc69f000 (ACPI NVS)
> [    0.000000]  BIOS-e820: 00000000bc69f000 - 00000000bc6ff000 (ACPI data)
> [    0.000000]  BIOS-e820: 00000000bc6ff000 - 00000000bc700000 (reserved)
> [    0.000000]  BIOS-e820: 00000000bc900000 - 00000000bca00000 (reserved)
> [    0.000000]  BIOS-e820: 00000000bcc00000 - 00000000bf000000 (reserved)
> [    0.000000]  BIOS-e820: 00000000e0000000 - 00000000f0000000 (reserved)
> [    0.000000]  BIOS-e820: 00000000fec00000 - 00000000fec10000 (reserved)
> [    0.000000]  BIOS-e820: 00000000fed00000 - 00000000fed00400 (reserved)
> [    0.000000]  BIOS-e820: 00000000fed10000 - 00000000fed14000 (reserved)
> [    0.000000]  BIOS-e820: 00000000fed18000 - 00000000fed1a000 (reserved)
> [    0.000000]  BIOS-e820: 00000000fed1c000 - 00000000fed90000 (reserved)
> [    0.000000]  BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
> [    0.000000]  BIOS-e820: 00000000ff800000 - 0000000100000000 (reserved)
> [    0.000000] DMI present.
> [    0.000000] last_pfn = 0xbc3c6 max_arch_pfn = 0x100000
> [    0.000000] init_memory_mapping: 0000000000000000-00000000373fe000
> [    0.000000] RAMDISK: 7772f000 - 7ffff800
> [    0.000000] Allocated new RAMDISK: 00fe2000 - 098b2800
> [    0.000000] Move RAMDISK from 000000007772f000 - 000000007ffff7ff to 00fe2000 - 098b27ff
> [    0.000000] ACPI: RSDP 000f64e0 00024 (v02 LENOVO)
> [    0.000000] ACPI: XSDT bc66a273 0009C (v01 LENOVO TP-7U    00002120  LTP 00000000)
> [    0.000000] ACPI: FACP bc66a400 000F4 (v03 LENOVO TP-7U    00002120 LNVO 00000001)
> [    0.000000] ACPI: DSDT bc66a7db 0F3FB (v01 LENOVO TP-7U    00002120 MSFT 03000000)
> [    0.000000] ACPI: FACS bc68e000 00040
> [    0.000000] ACPI: SSDT bc66a5b4 00227 (v01 LENOVO TP-7U    00002120 MSFT 03000000)
> [    0.000000] ACPI: ECDT bc679bd6 00052 (v01 LENOVO TP-7U    00002120 LNVO 00000001)
> [    0.000000] ACPI: APIC bc679c28 00078 (v01 LENOVO TP-7U    00002120 LNVO 00000001)
> [    0.000000] ACPI: MCFG bc679ca0 0003C (v01 LENOVO TP-7U    00002120 LNVO 00000001)
> [    0.000000] ACPI: HPET bc679cdc 00038 (v01 LENOVO TP-7U    00002120 LNVO 00000001)
> [    0.000000] ACPI: SLIC bc679dc2 00176 (v01 LENOVO TP-7U    00002120  LTP 00000000)
> [    0.000000] ACPI: BOOT bc679f38 00028 (v01 LENOVO TP-7U    00002120  LTP 00000001)
> [    0.000000] ACPI: ASF! bc679f60 000A0 (v16 LENOVO TP-7U    00002120 PTL  00000001)
> [    0.000000] ACPI: SSDT bc68d213 0054F (v01 LENOVO TP-7U    00002120 INTL 20050513)
> [    0.000000] ACPI: TCPA bc407000 00032 (v00                 00000000      00000000)
> [    0.000000] ACPI: DMAR bc406000 00120 (v01               
 00000001      00000000)
> [    0.000000] ACPI: SSDT bc3d3000 00655 (v01  PmRef    CpuPm 00003000 INTL 20050624)
> [    0.000000] ACPI: SSDT bc3d2000 00274 (v01  PmRef  Cpu0Tst 00003000 INTL 20050624)
> [    0.000000] ACPI: SSDT bc3d1000 00242 (v01  PmRef    ApTst 00003000 INTL 20050624)
> [    0.000000] 2127MB HIGHMEM available.
> [    0.000000] 883MB LOWMEM available.
> [    0.000000]   mapped low ram: 0 - 373fe000
> [    0.000000]   low ram: 0 - 373fe000
> [    0.000000]   node 0 low ram: 00000000 - 373fe000
> [    0.000000]   node 0 bootmap 00008000 - 0000ee80
> [    0.000000] (9 early reservations) ==> bootmem [0000000000 - 00373fe000]
> [    0.000000]   #0 [0000000000 - 0000001000]   BIOS data page ==> [0000000000 - 0000001000]
> [    0.000000]   #1 [0000001000 - 0000002000]    EX TRAMPOLINE ==> [0000001000 - 0000002000]
> [    0.000000]   #2 [0000006000 - 0000007000]       TRAMPOLINE ==> [0000006000 - 0000007000]
> [    0.000000]   #3 [0000a00000 - 0000fdb684]    TEXT DATA BSS ==> [0000a00000 - 0000fdb684]
> [    0.000000]   #4 [000009ac00 - 0000100000]    BIOS reserved ==> [000009ac00 - 0000100000]
> [    0.000000]   #5 [0000fdc000 - 0000fe116c]              BRK ==> [0000fdc000 - 0000fe116c]
> [    0.000000]   #6 [0000007000 - 0000008000]          PGTABLE ==> [0000007000 - 0000008000]
> [    0.000000]   #7 [0000fe2000 - 00098b2800]      NEW RAMDISK ==> [0000fe2000 - 00098b2800]
> [    0.000000]   #8 [0000008000 - 000000f000]          BOOTMAP ==> [0000008000 - 000000f000]
> [    0.000000] found SMP MP-table at [c00f6520] f6520
> [    0.000000] Zone PFN ranges:
> [    0.000000]   DMA      0x00000000 -> 0x00001000
> [    0.000000]   Normal   0x00001000 -> 0x000373fe
> [    0.000000]   HighMem  0x000373fe -> 0x000bc3c6
> [    0.000000] Movable zone start PFN for each node
> [    0.000000] early_node_map[6] active PFN ranges
> [    0.000000]     0: 0x00000000 -> 0x00000060
> [    0.000000]     0: 0x00000068 -> 0x0000009a
> [    0.000000]     0: 0x00000100 -> 0x00000800
> [    0.000000]     0: 0x00000a00 -> 0x000bc1a1
> [    0.000000]     0: 0x000bc1a7 -> 0x000bc2b7
> [    0.000000]     0: 0x000bc30f -> 0x000bc3c6
> [    0.000000] TBOOT: found shared page at phys addr 0x824000:
> [    0.000000] Using APIC driver default
> [    0.000000] ACPI: PM-Timer IO Port: 0x1008
> [    0.000000] ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
> [    0.000000] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] enabled)
> [    0.000000] ACPI: LAPIC (acpi_id[0x02] lapic_id[0x02] disabled)
> [    0.000000] ACPI: LAPIC (acpi_id[0x03] lapic_id[0x03] disabled)
> [    0.000000] ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1])
> [    0.000000] ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1])
> [    0.000000] ACPI: IOAPIC (id[0x01] address[0xfec00000] gsi_base[0])
> [    0.000000] IOAPIC[0]: apic_id 1, version 32, address 0xfec00000, GSI 0-23
> [    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
> [    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
> [    0.000000] Enabling APIC mode:  Flat.  Using 1 I/O APICs
> [    0.000000] Using ACPI (MADT) for SMP configuration information
> [    0.000000] ACPI: HPET id: 0x8086a201 base: 0xfed00000
> [    0.000000] SMP: Allowing 4 CPUs, 2 hotplug CPUs
> [    0.000000] PM: Registered nosave memory: 0000000000060000 - 0000000000068000
> [    0.000000] PM: Registered nosave memory: 000000000009a000 - 000000000009b000
> [    0.000000] PM: Registered nosave memory: 000000000009b000 - 00000000000a0000
> [    0.000000] PM: Registered nosave memory: 00000000000a0000 - 00000000000d6000
> [    0.000000] PM: Registered nosave memory: 00000000000d6000 - 00000000000d8000
> [    0.000000] PM: Registered nosave memory: 00000000000d8000 - 00000000000e0000
> [    0.000000] PM: Registered nosave memory: 00000000000e0000 - 0000000000100000
> [    0.000000] PM: Registered nosave memory: 0000000000800000 - 0000000000a00000
> [    0.000000] Allocating PCI resources starting at c0000000 (gap: bf000000:21000000)
> [    0.000000] NR_CPUS:64 nr_cpumask_bits:64 nr_cpu_ids:4 nr_node_ids:1
> [    0.000000] PERCPU: Embedded 13 pages at cb04b000, static data 30268 bytes
> [    0.000000] Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 764274
> [    0.000000] Kernel command line: intel_iommu=on root=UUID=96777f17-50b1-43b1-93ba-
> d9a6a38dfb0d ro rhgb console=ttyS0,115200 3
> [    0.000000] Enabling fast FPU save and restore... done.
> [    0.000000] Enabling unmasked SIMD FPU exception support... done.
> [    0.000000] Initializing CPU#0
> [    0.000000] NR_IRQS:2304
> [    0.000000] PID hash table entries: 4096 (order: 12, 16384 bytes)
> [    0.000000] Extended CMOS year: 2000
> [    0.000000] Fast TSC calibration using PIT
> [    0.000000] Detected 2793.062 MHz processor.
> [    0.004000] Console: colour VGA+ 80x25
> [    0.004000] console [ttyS0] enabled
> [    0.004000] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
> [    0.004000] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
> [    0.004000] allocated 15420280 bytes of page_cgroup
> [    0.004000] please try cgroup_disable=memory option if you don't want
> [    0.004000] Initializing HighMem for node 0 (000373fe:000bc3c6)
> [    0.004000] Memory: 2893880k/3084056k available (2725k kernel code, 186380k reserved, 1603k
> data, 468k init, 2178472k highmem)
> [    0.004000] virtual kernel memory layout:
> [    0.004000]     fixmap  : 0xffc75000 - 0xfffff000   (3624 kB)
> [    0.004000]     pkmap   : 0xff400000 - 0xff800000   (4096 kB)
> [    0.004000]     vmalloc : 0xf7bfe000 - 0xff3fe000   ( 120 MB)
> [    0.004000]     lowmem  : 0xc0000000 - 0xf73fe000   ( 883 MB)
> [    0.004000]       .init : 0xc0e42000 - 0xc0eb7000   ( 468 kB)
> [    0.004000]       .data : 0xc0ca9591 - 0xc0e3a568   (1603 kB)
> [    0.004000]       .text : 0xc0a00000 - 0xc0ca9591   (2725 kB)
> [    0.004000] Checking if this processor honours the WP bit even in supervisor mode...Ok.
> [    0.004000] SLUB: Genslabs=13, HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1
> [    0.004000] HPET: 4 timers in total, 0 timers will be used for per-cpu timer
> [    0.004012] Calibrating delay loop (skipped), value calculated using timer frequency..
> 5586.12 BogoMIPS (lpj=11172248)
> [    0.012017] Security Framework initialized
> [    0.016008] SELinux:  Disabled at boot.
> [    0.020013] Mount-cache hash table entries: 512
> [    0.024146] Initializing cgroup subsys ns
> [    0.028007] Initializing cgroup subsys cpuacct
> [    0.032007] Initializing cgroup subsys memory
> [    0.036024] CPU: L1 I cache: 32K, L1 D cache: 32K
> [    0.044004] CPU: L2 cache: 6144K
> [    0.047225] CPU: Physical Processor ID: 0
> [    0.048004] CPU: Processor Core ID: 0
> [    0.052006] using mwait in idle threads.
> [    0.056010] Intel Performance Monitoring support detected.
> [    0.060004] ... version:         2
> [    0.063397] ... bit width:       40
> [    0.064004] ... mask length:     7
> [    0.068004] ... num counters:    2
> [    0.072004] ... value mask:      000000ffffffffff
> [    0.076004] ... fixed counters:  3
> [    0.080004] ... counter mask:    0000000700000003
> [    0.084010] Checking 'hlt' instruction... OK.
> [    0.106828] ACPI: Core revision 20090320
> [    0.136580] ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1
> [    0.180628] CPU0: Intel(R) Core(TM)2 Duo CPU     T9600  @ 2.80GHz stepping 06
> [    0.188001] Booting processor 1 APIC 0x1 ip 0x6000
> TBOOT: cpu 1 waking up, SIPI vector=6000
> [    0.004000] Initializing CPU#1
> [    0.004000] Calibrating delay using timer specific routine.. 5585.99 BogoMIPS
> (lpj=11171983)
> [    0.004000] CPU: L1 I cache: 32K, L1 D cache: 32K
> [    0.004000] CPU: L2 cache: 6144K
> [    0.004000] CPU: Physical Processor ID: 0
> [    0.004000] CPU: Processor Core ID: 1
> [    0.285275] CPU1: Intel(R) Core(TM)2 Duo CPU     T9600  @ 2.80GHz stepping 06
> [    0.293253] checking TSC synchronization [CPU#0 -> CPU#1]: passed.
> [    0.296096] Brought up 2 CPUs
> [    0.300004] Total of 2 processors activated (11172.11 BogoMIPS).
> [    0.304149] net_namespace: 1056 bytes
> [    0.308028] Booting paravirtualized kernel on bare hardware
> [    0.312196] Time: 21:05:09  Date: 04/09/09
> [    0.316050] NET: Registered protocol family 16
> [    0.320132] EISA bus registered
> [    0.324010] ACPI FADT declares the system doesn't support PCIe ASPM, so disable it
> [    0.328003] ACPI: bus type pci registered
> [    0.332096] PCI: MCFG configuration 0: base e0000000 segment 0 buses 0 - 63
> [    0.336004] PCI: MCFG area at e0000000 reserved in E820
> [    0.340002] PCI: Using MMCONFIG for extended config space
> [    0.344003] PCI: Using configuration type 1 for base access
> [    0.348432] bio: create slab <bio-0> at 0
> [    0.357904] ACPI: EC: EC description table is found, configuring boot EC
> [    0.369745] ACPI: BIOS _OSI(Linux) query ignored
> [    0.372020] ACPI: EC: non-query interrupt received, switching to interrupt mode
> [    0.404644] ACPI: Interpreter enabled
> [    0.408018] ACPI: (supports S0 S3 S4 S5)
> [    0.413173] ACPI: Using IOAPIC for interrupt routing
> [    0.450511] ACPI: EC: GPE = 0x11, I/O: command/status = 0x66, data = 0x62
> [    0.460018] ACPI: EC: driver started in interrupt mode
> [    0.464197] ACPI: Power Resource [PUBS] (on)
> [    0.473764] ACPI: ACPI Dock Station Driver: 3 docks/bays found
> [    0.480412] ACPI: PCI Root Bridge [PCI0] (0000:00)
> [    0.484279] pci 0000:00:03.0: PME# supported from D0 D3hot D3cold
> [    0.492006] pci 0000:00:03.0: PME# disabled
> [    0.496356] pci 0000:00:19.0: PME# supported from D0 D3hot D3cold
> [    0.500007] pci 0000:00:19.0: PME# disabled
> [    0.504461] pci 0000:00:1a.7: PME# supported from D0 D3hot D3cold
> [    0.512007] pci 0000:00:1a.7: PME# disabled
> [    0.516131] pci 0000:00:1b.0: PME# supported from D0 D3hot D3cold
> [    0.524007] pci 0000:00:1b.0: PME# disabled
> [    0.528093] pci 0000:00:1c.0: PME# supported from D0 D3hot D3cold
> [    0.532006] pci 0000:00:1c.0: PME# disabled
> [    0.536096] pci 0000:00:1c.1: PME# supported from D0 D3hot D3cold
> [    0.544006] pci 0000:00:1c.1: PME# disabled
> [    0.548054] pci 0000:00:1c.2: PME# supported from D0 D3hot D3cold
> [    0.552006] pci 0000:00:1c.2: PME# disabled
> [    0.560097] pci 0000:00:1c.3: PME# supported from D0 D3hot D3cold
> [    0.564006] pci 0000:00:1c.3: PME# disabled
> [    0.568096] pci 0000:00:1c.4: PME# supported from D0 D3hot D3cold
> [    0.576007] pci 0000:00:1c.4: PME# disabled
> [    0.580474] pci 0000:00:1d.7: PME# supported from D0 D3hot D3cold
> [    0.584008] pci 0000:00:1d.7: PME# disabled
> [    0.588376] pci 0000:00:1f.2: PME# supported from D3hot
> [    0.596007] pci 0000:00:1f.2: PME# disabled
> [    0.600392] pci 0000:03:00.0: PME# supported from D0 D3hot D3cold
> [    0.604010] pci 0000:03:00.0: PME# disabled
> [    0.612647] pci 0000:15:00.0: PME# supported from D0 D1 D2 D3hot D3cold
> [    0.616008] pci 0000:15:00.0: PME# disabled
> [    0.620139] pci 0000:15:00.1: PME# supported from D0 D1 D2 D3hot D3cold
> [    0.628008] pci 0000:15:00.1: PME# disabled
> [    0.632092] pci 0000:00:1e.0: transparent bridge
> [    0.648070] ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 9 10 *11)
> [    0.653451] ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 7 9 10 *11)
> [    0.660591] ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 6 7 9 10 *11)
> [    0.666439] ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 7 9 10 *11)
> [    0.674439] ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 6 7 9 10 *11)
> [    0.681449] ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 6 7 9 10 *11)
> [    0.688478] ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 5 6 7 9 10 *11)
> [    0.694439] ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 5 6 7 9 10 *11)
> [    0.704167] PCI: Using ACPI for IRQ routing
> [    0.724027] NET: Registered protocol family 8
> [    0.728004] NET: Registered protocol family 20
> [    0.732022] NetLabel: Initializing
> [    0.736004] NetLabel:  domain hash size = 128
> [    0.740003] NetLabel:  protocols = UNLABELED CIPSOv4
> [    0.744018] NetLabel:  unlabeled traffic allowed by default
> [    0.752013] hpet0: at MMIO 0xfed00000, IRQs 2, 8, 0, 0
> [    0.757054] hpet0: 4 comparators, 64-bit 14.318180 MHz counter
> [    0.788510] pnp: PnP ACPI init
> [    0.791565] ACPI: bus type pnp registered
> [    0.862510] pnp: PnP ACPI: found 12 devices
> [    0.866703] ACPI: ACPI bus type pnp unregistered
> [    0.871322] PnPBIOS: Disabled by ACPI PNP
> [    0.875345] system 00:00: iomem range 0x0-0x9ffff could not be reserved
> [    0.881957] system 00:00: iomem range 0xc0000-0xc3fff could not be reserved
> [    0.888912] system 00:00: iomem range 0xc4000-0xc7fff could not be reserved
> [    0.895868] system 00:00: iomem range 0xc8000-0xcbfff has been reserved
> [    0.902479] system 00:00: iomem range 0xcc000-0xcffff has been reserved
> [    0.909087] system 00:00: iomem range 0xd0000-0xd3fff could not be reserved
> [    0.916044] system 00:00: iomem range 0xd4000-0xd7fff could not be reserved
> [    0.922999] system 00:00: iomem range 0xe0000-0xe3fff could not be reserved
> [    0.929956] system 00:00: iomem range 0xe4000-0xe7fff could not be reserved
> [    0.936910] system 00:00: iomem range 0xe8000-0xebfff could not be reserved
> [    0.943866] system 00:00: iomem range 0xec000-0xeffff could not be reserved
> [    0.950823] system 00:00: iomem range 0xf0000-0xfffff could not be reserved
> [    0.957777] system 00:00: iomem range 0x100000-0xbeffffff could not be reserved
> [    0.965073] system 00:00: iomem range 0xfec00000-0xfed3ffff could not be reserved
> [    0.972546] system 00:00: iomem range 0xfed4c000-0xffffffff could not be reserved
> [    0.980019] system 00:02: ioport range 0x1000-0x107f has been reserved
> [    0.986539] system 00:02: ioport range 0x1180-0x11ff has been reserved
> [    0.993063] system 00:02: ioport range 0x800-0x80f has been reserved
> [    0.999413] system 00:02: ioport range 0x15e0-0x15ef has been reserved
> [    1.005932] system 00:02: ioport range 0x1600-0x167f has been reserved
> [    1.012456] system 00:02: ioport range 0x1680-0x169f has been reserved
> [    1.018979] system 00:02: iomem range 0xe0000000-0xefffffff has been reserved
> [    1.026107] system 00:02: iomem range 0xfed1c000-0xfed1ffff has been reserved
> [    1.033237] system 00:02: iomem range 0xfed10000-0xfed13fff has been reserved
> [    1.040368] system 00:02: iomem range 0xfed18000-0xfed18fff has been reserved
> [    1.047499] system 00:02: iomem range 0xfed19000-0xfed19fff has been reserved
> [    1.054627] system 00:02: iomem range 0xfed45000-0xfed4bfff has been reserved
> [    1.096497] pci 0000:15:00.0: CardBus bridge, secondary bus 0000:16
> [    1.102759] pci 0000:15:00.0:   IO window: 0x005000-0x0050ff
> [    1.108419] pci 0000:15:00.0:   IO window: 0x005400-0x0054ff
> [    1.114079] pci 0000:15:00.0:   PREFETCH window: 0xf0000000-0xf3ffffff
> [    1.120600] pci 0000:15:00.0:   MEM window: 0xc4000000-0xc7ffffff
> [    1.126701] pci 0000:00:1c.0: PCI INT A -> GSI 20 (level, low) -> IRQ 20
> [    1.133406] pci 0000:00:1c.1: PCI INT B -> GSI 21 (level, low) -> IRQ 21
> [    1.140110] pci 0000:00:1c.2: PCI INT C -> GSI 22 (level, low) -> IRQ 22
> [    1.146816] pci 0000:00:1c.3: PCI INT D -> GSI 23 (level, low) -> IRQ 23
> [    1.153522] pci 0000:00:1c.4: PCI INT A -> GSI 20 (level, low) -> IRQ 20
> [    1.160239] pci 0000:15:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
> [    1.167056] NET: Registered protocol family 2
> [    1.216070] IP route cache hash table entries: 32768 (order: 5, 131072 bytes)
> [    1.223514] TCP established hash table entries: 131072 (order: 8, 1048576 bytes)
> [    1.231215] TCP bind hash table entries: 65536 (order: 7, 524288 bytes)
> [    1.237973] TCP: Hash tables configured (established 131072 bind 65536)
> [    1.244579] TCP reno registered
> [    1.256071] NET: Registered protocol family 1
> [    1.260479] checking if image is initramfs...
> [    1.408838] rootfs image is initramfs; unpacking...
> [    1.413821] Freeing initrd memory: 140098k freed
> [    1.477597] Simple Boot Flag at 0x35 set to 0x1
> [    1.482461] audit: initializing netlink socket (disabled)
> [    1.487870] type=2000 audit(1239311109.487:1): initialized
> [    1.500548] highmem bounce pool size: 64 pages
> [    1.504996] HugeTLB registered 4 MB page size, pre-allocated 0 pages
> [    1.513026] VFS: Disk quotas dquot_6.5.2
> [    1.517026] Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
> [    1.523674] msgmni has been set to 1672
> [    1.527933] alg: No test for stdrng (krng)
> [    1.532164] io scheduler noop registered
> [    1.536085] io scheduler anticipatory registered
> [    1.540720] io scheduler deadline registered
> [    1.545000] io scheduler cfq registered (default)
> [    1.551202] isapnp: Scanning for PnP cards...
> [    1.909831] isapnp: No Plug & Play device found
> [    1.935571] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
> [    1.941973] serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
> [    1.948710] 00:0a: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
> [    1.954388] serial 0000:00:03.3: PCI INT B -> GSI 17 (level, low) -> IRQ 17
> [    1.961494] 0000:00:03.3: ttyS1 at I/O 0x1830 (irq = 17) is a 16550A
> [    1.968767] brd: module loaded
> [    1.971861] input: Macintosh mouse button emulation as /devices/virtual/input/input0
> [    1.979677] PNP: PS/2 Controller [PNP0303:KBD,PNP0f13:MOU] at 0x60,0x64 irq 1,12
> [    2.005030] serio: i8042 KBD port at 0x60,0x64 irq 1
> [    2.010049] serio: i8042 AUX port at 0x60,0x64 irq 12
> [    2.017475] mice: PS/2 mouse device common for all mice
> [    2.022766] rtc_cmos 00:07: RTC can wake from S4
> [    2.027446] rtc_cmos 00:07: rtc core: registered rtc_cmos as rtc0
> [    2.033568] rtc0: alarms up to one month, y3k, 114 bytes nvram, hpet irqs
> [    2.040413] EISA: Probing bus 0 at eisa.0
> [    2.044436] Cannot allocate resource for EISA slot 1
> [    2.049405] Cannot allocate resource for EISA slot 2
> [    2.054380] Cannot allocate resource for EISA slot 3
> [    2.054927] input: AT Translated Set 2 keyboard as
> /devices/platform/i8042/serio0/input/input1
> [    2.067940] Cannot allocate resource for EISA slot 4
> [    2.072907] Cannot allocate resource for EISA slot 5
> [    2.077874] Cannot allocate resource for EISA slot 6
> [    2.082839] Cannot allocate resource for EISA slot 7
> [    2.087799] Cannot allocate resource for EISA slot 8
> [    2.092764] EISA: Detected 0 cards.
> [    2.096253] cpuidle: using governor ladder
> [    2.100347] cpuidle: using governor menu
> [    2.104793] TCP cubic registered
> [    2.108054] Using IPI No-Shortcut mode
> [    2.111910] registered taskstats version 1
> [    2.116186]   Magic number: 5:404:95
> [    2.119810] pci_express 0000:00:1c.2:pcie08: hash matches
> [    2.125268] rtc_cmos 00:07: setting system clock to 2009-04-09 21:05:11 UTC (1239311111)
> [    2.133347] BIOS EDD facility v0.16 2004-Jun-25, 0 devices found
> [    2.139352] EDD information not available.
> [    2.143600] Freeing unused kernel memory: 468k freed
> [    2.148852] Write protecting the kernel text: 2728k
> [    2.153764] Write protecting the kernel read-only data: 1052k
> Loading, please wait...
> Couldnt get a file descriptor referring to the console
> Begin: Loading essential drivers... ...
> [    2.283709] fuse init (API version 7.11)
> [    2.301669] thermal LNXTHERM:01: registered as thermal_zone0
> [    2.307343] ACPI: Thermal Zone [THM0] (36 C)
> [    2.313694] thermal LNXTHERM:02: registered as thermal_zone1
> [    2.319363] ACPI: Thermal Zone [THM1] (29 C)
> Done.
> Begin: Running /scripts/init-premount ...
> Done.
> Begin: Mounting root file system... ...
> Begin: Running /scripts/local-top ...
> Done.
> Begin: Waiting for root file system... ...
> [    2.757193] SCSI subsystem initialized
> [    2.762580] e1000e: Intel(R) PRO/1000 Network Driver - 0.3.3.4-k4
> [    2.768677] e1000e: Copyright (c) 1999-2008 Intel Corporation.
> [    2.774760] e1000e 0000:00:19.0: PCI INT A -> GSI 20 (level, low) -> IRQ 20
> [    2.798066] usbcore: registered new interface driver usbfs
> [    2.803760] usbcore: registered new interface driver hub
> [    2.809119] usbcore: registered new device driver usb
> [    2.817053] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
> [    2.819297] uhci_hcd: USB Universal Host Controller Interface driver
> [    2.829919] Warning! ehci_hcd should always be loaded before uhci_hcd and ohci_hcd, not
> after
> [    2.870564] 0000:00:19.0: eth0: (PCI Express:2.5GB/s:Width x1) 00:1c:25:a1:6c:42
> [    2.877970] 0000:00:19.0: eth0: Intel(R) PRO/1000 Network Connection
> [    2.884361] 0000:00:19.0: eth0: MAC: 7, PHY: 8, PBA No: 1008ff-0ff
> [    2.891198] uhci_hcd 0000:00:1a.0: power state changed by ACPI to D0
> [    2.897557] uhci_hcd 0000:00:1a.0: PCI INT A -> GSI 20 (level, low) -> IRQ 20
> [    2.904697] uhci_hcd 0000:00:1a.0: UHCI Host Controller
> [    2.909963] uhci_hcd 0000:00:1a.0: new USB bus registered, assigned bus number 1
> [    2.917394] uhci_hcd 0000:00:1a.0: irq 20, io base 0x00001860
> [    2.923154] uhci_hcd 0000:00:1a.0: host system error, PCI problems?
> [    2.923277] usb usb1: configuration #1 chosen from 1 choice
> [    2.923311] hub 1-0:1.0: USB hub found
> [    2.923319] hub 1-0:1.0: 2 ports detected
> [    2.924001] uhci_hcd 0000:00:1a.0: host controller halted, very bad!
> [    2.924001] uhci_hcd 0000:00:1a.0: HC died; cleaning up
> [    2.954489] ehci_hcd 0000:00:1a.7: power state changed by ACPI to D0
> [    2.960850] ehci_hcd 0000:00:1a.7: PCI INT D -> GSI 23 (level, low) -> IRQ 23
> [    2.968040] ehci_hcd 0000:00:1a.7: EHCI Host Controller
> [    2.973571] ehci_hcd 0000:00:1a.7: new USB bus registered, assigned bus number 2
> [    2.984868] ehci_hcd 0000:00:1a.7: debug port 1
> [    2.989424] ehci_hcd 0000:00:1a.7: irq 23, io mem 0xfc326c00
> [    3.008513] ehci_hcd 0000:00:1a.7: USB 2.0 started, EHCI 1.00
> [    3.014364] usb usb2: configuration #1 chosen from 1 choice
> [    3.033287] hub 2-0:1.0: USB hub found
> [    3.037048] hub 2-0:1.0: 6 ports detected
> [    3.053029] uhci_hcd 0000:00:1a.1: PCI INT B -> GSI 21 (level, low) -> IRQ 21
> [    3.060182] uhci_hcd 0000:00:1a.1: UHCI Host Controller
> [    3.065433] uhci_hcd 0000:00:1a.1: new USB bus registered, assigned bus number 3
> [    3.072856] uhci_hcd 0000:00:1a.1: irq 21, io base 0x00001880
> [    3.078654] uhci_hcd 0000:00:1a.1: host system error, PCI problems?
> [    3.082599] uhci_hcd 0000:00:1a.1: host controller halted, very bad!
> [    3.082599] uhci_hcd 0000:00:1a.1: HC died; cleaning up
> [    3.104893] uhci_hcd 0000:00:1a.1: USB bus 3 deregistered
> [    3.110320] uhci_hcd 0000:00:1a.1: PCI INT B disabled
> [    3.115382] uhci_hcd 0000:00:1a.1: init 0000:00:1a.1 fail, -108
> [    3.121477] uhci_hcd: probe of 0000:00:1a.1 failed with error -108
> [    3.127676] ahci 0000:00:1f.2: PCI INT B -> GSI 16 (level, low) -> IRQ 16
> [    3.134567] ahci: SSS flag set, parallel bus scan disabled
> [    3.140079] ahci 0000:00:1f.2: AHCI 0001.0200 32 slots 4 ports 3 Gbps 0x3 impl SATA mode
> [    3.148163] ahci 0000:00:1f.2: flags: 64bit ncq sntf stag pm led clo pio slum part
> [    3.157780] scsi0 : ahci
> [    3.160411] scsi1 : ahci
> [    3.163027] scsi2 : ahci
> [    3.165631] scsi3 : ahci
> [    3.169253] ata1: SATA max UDMA/133 abar m2048@0xfc326000 port 0xfc326100 irq 30
> [    3.176642] ata2: SATA max UDMA/133 irq_stat 0x00000040, connection status changed irq 30
> [    3.184806] ata3: DUMMY
> [    3.187256] ata4: DUMMY
> [    3.190289] ehci_hcd 0000:00:1d.7: power state changed by ACPI to D0
> [    3.196653] ehci_hcd 0000:00:1d.7: PCI INT D -> GSI 19 (level, low) -> IRQ 19
> [    3.203807] ehci_hcd 0000:00:1d.7: EHCI Host Controller
> [    3.209059] ehci_hcd 0000:00:1d.7: new USB bus registered, assigned bus number 3
> [    3.220361] ehci_hcd 0000:00:1d.7: debug port 1
> [    3.224920] ehci_hcd 0000:00:1d.7: irq 19, io mem 0xfc327000
> [    3.235143] Uhhuh. NMI received for unknown reason a1 on CPU 0.
> [    3.235143] You have some hardware problem, likely on the PCI bus.
> [    3.235143] Dazed and confused, but trying to continue
> [    3.253884] ehci_hcd 0000:00:1d.7: USB 2.0 started, EHCI 1.00
> [    3.259763] usb usb3: configuration #1 chosen from 1 choice
> [    3.265398] hub 3-0:1.0: USB hub found
> [    3.269211] hub 3-0:1.0: 6 ports detected
> [    3.273376] pata_acpi 0000:00:03.2: PCI INT C -> GSI 18 (level, low) -> IRQ 18
> [    3.280635] pata_acpi 0000:00:03.2: PCI INT C disabled
> [    3.286338] uhci_hcd 0000:00:1a.2: power state changed by ACPI to D0
> [    3.292691] uhci_hcd 0000:00:1a.2: PCI INT C -> GSI 22 (level, low) -> IRQ 22
> [    3.299826] uhci_hcd 0000:00:1a.2: UHCI Host Controller
> [    3.305086] uhci_hcd 0000:00:1a.2: new USB bus registered, assigned bus number 4
> [    3.312773] uhci_hcd 0000:00:1a.2: irq 22, io base 0x000018a0
> [    3.318555] uhci_hcd 0000:00:1a.2: host system error, PCI problems?
> [    3.318647] usb usb4: configuration #1 chosen from 1 choice
> [    3.318683] hub 4-0:1.0: USB hub found
> [    3.318691] hub 4-0:1.0: 2 ports detected
> [    3.326261] ohci1394 0000:15:00.1: PCI INT B -> GSI 17 (level, low) -> IRQ 17
> [    3.323086] uhci_hcd 0000:00:1a.2: host controller halted, very bad!
> [    3.323086] uhci_hcd 0000:00:1a.2: HC died; cleaning up
> [    3.357015] uhci_hcd 0000:00:1d.0: power state changed by ACPI to D0
> [    3.363373] uhci_hcd 0000:00:1d.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
> [    3.370555] uhci_hcd 0000:00:1d.0: UHCI Host Controller
> [    3.375834] uhci_hcd 0000:00:1d.0: new USB bus registered, assigned bus number 5
> [    3.383358] uhci_hcd 0000:00:1d.0: irq 16, io base 0x000018c0
> [    3.390041] uhci_hcd 0000:00:1d.0: host system error, PCI problems?
> [    3.390145] usb usb5: configuration #1 chosen from 1 choice
> [    3.390179] hub 5-0:1.0: USB hub found
> [    3.390187] hub 5-0:1.0: 2 ports detected
> [    3.390319] uhci_hcd 0000:00:1d.1: PCI INT B -> GSI 17 (level, low) -> IRQ 17
> [    3.390333] uhci_hcd 0000:00:1d.1: UHCI Host Controller
> [    3.390358] uhci_hcd 0000:00:1d.1: new USB bus registered, assigned bus number 6
> [    3.390408] uhci_hcd 0000:00:1d.1: irq 17, io base 0x000018e0
> [    3.390438] uhci_hcd 0000:00:1d.1: host system error, PCI problems?
> [    3.390440] uhci_hcd 0000:00:1d.1: host controller halted, very bad!
> [    3.390465] uhci_hcd 0000:00:1d.1: HC died; cleaning up
> [    3.390482] uhci_hcd 0000:00:1d.1: USB bus 6 deregistered
> [    3.390512] uhci_hcd 0000:00:1d.1: PCI INT B disabled
> [    3.390514] uhci_hcd 0000:00:1d.1: init 0000:00:1d.1 fail, -108
> [    3.390519] uhci_hcd: probe of 0000:00:1d.1 failed with error -108
> [    3.390531] uhci_hcd 0000:00:1d.2: PCI INT C -> GSI 18 (level, low) -> IRQ 18
> [    3.390544] uhci_hcd 0000:00:1d.2: UHCI Host Controller
> [    3.390568] uhci_hcd 0000:00:1d.2: new USB bus registered, assigned bus number 6
> [    3.390619] uhci_hcd 0000:00:1d.2: irq 18, io base 0x00001c00
> [    3.390722] usb usb6: configuration #1 chosen from 1 choice
> [    3.390754] hub 6-0:1.0: USB hub found
> [    3.390761] hub 6-0:1.0: 2 ports detected
> [    3.392003] uhci_hcd 0000:00:1d.0: host controller halted, very bad!
> [    3.392003] uhci_hcd 0000:00:1d.0: HC died; cleaning up
> [    3.525756] uhci_hcd 0000:00:1d.2: host system error, PCI problems?
> [    3.528514] hub 4-0:1.0: hub_port_status failed (err = -19)
> [    3.528517] hub 4-0:1.0: hub_port_status failed (err = -19)
> [    3.528520] hub 4-0:1.0: activate --> -19
> [    3.528523] hub 5-0:1.0: hub_port_status failed (err = -19)
> [    3.528525] hub 5-0:1.0: hub_port_status failed (err = -19)
> [    3.528527] hub 5-0:1.0: activate --> -19
> [    3.530883] ohci1394: fw-host0: OHCI-1394 1.1 (PCI): IRQ=[17]  MMIO=[f4801000-f48017ff]
> Max Packet=[2048]  IR/IT contexts=[4/4]
> [    3.535012] uhci_hcd 0000:00:1d.2: host controller halted, very bad!
> [    3.535012] uhci_hcd 0000:00:1d.2: HC died; cleaning up
> [    3.588522] usb 2-5: new high speed USB device using ehci_hcd and address 3
> [    3.595490] ehci_hcd 0000:00:1a.7: fatal error
> [    3.599486] ehci_hcd 0000:00:1a.7: HC died; cleaning up
> [    3.632533] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
> [    3.638735] ata1.00: failed to IDENTIFY (I/O error, err_mask=0x100)
> [    4.526505] ohci1394: fw-host0: Unrecoverable error!
> [    4.531475] ohci1394: fw-host0: Async Req Rcv Context died: ctrl[00008806] cmdptr[36dad001]
> [    4.539823] ohci1394: fw-host0: Error in reception of SelfID packets
> [0x0001000c/0x00000000] (count: 0)
> [    4.551329] ohci1394: fw-host0: SelfID received outside of bus reset sequence
> [    4.820521] ohci1394: fw-host0: Unrecoverable error!
> [    4.825485] ohci1394: fw-host0: Async Req Tx Context died: ctrl[00008806] cmdptr[096e8002]
> [    4.833741] ohci1394: fw-host0: Async Req Rcv Context died: ctrl[00008806] cmdptr[36dad001]
> [    8.592028] hub 2-0:1.0: cannot reset port 5 (err = -19)
> [    8.597342] hub 2-0:1.0: cannot disable port 5 (err = -19)
> [    8.602830] hub 2-0:1.0: cannot reset port 5 (err = -19)
> [    8.608138] hub 2-0:1.0: cannot disable port 5 (err = -19)
> [    8.613625] hub 2-0:1.0: cannot reset port 5 (err = -19)
> [    8.618935] hub 2-0:1.0: cannot disable port 5 (err = -19)
> [    8.624423] hub 2-0:1.0: cannot reset port 5 (err = -19)
> [    8.629735] hub 2-0:1.0: cannot disable port 5 (err = -19)
> [    8.635221] hub 2-0:1.0: cannot disable port 5 (err = -19)
> [    8.640723] hub 2-0:1.0: hub_port_status failed (err = -19)
> [    8.960522] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
> [    8.966726] ata1.00: failed to IDENTIFY (I/O error, err_mask=0x100)
> [    8.972990] ata1: limiting SATA link speed to 1.5 Gbps
> [   14.284022] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
> [   14.290221] ata1.00: failed to IDENTIFY (I/O error, err_mask=0x100)
> [   19.608021] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
> [   19.628017] ata1: exception Emask 0x20 SAct 0x0 SErr 0x0 action 0x1 t4
> [   19.634534] ata1: irq_stat 0x20000000, host bus error
> [   20.360022] ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
> [   20.366222] ata2.00: failed to IDENTIFY (I/O error, err_mask=0x100)
> [   25.684024] ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
> [   25.690221] ata2.00: failed to IDENTIFY (I/O error, err_mask=0x100)
> [   25.696486] ata2: limiting SATA link speed to 1.5 Gbps
> [   31.008522] ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
> [   31.014726] ata2.00: failed to IDENTIFY (I/O error, err_mask=0x100)
> Done.
> Gave up waiting for root device.  Common problems:
>   - Boot args (cat /proc/cmdline)
>     - Check rootdelay= (did the system wait long enough?)
>     - Check root= (did the system wait for the right device?)
>   - Missing modules (cat /proc/modules; ls /dev)
> ALERT! /dev/disk/by-uuid/96777f17-50b1-43b1-93ba-d9a6a38dfb0d does not exist. Dropping to a
> shell!
>
>
> BusyBox v1.10.2 (Ubuntu 1:1.10.2-1ubuntu7) built-in shell (ash)
> Enter 'help' for a list of built-in commands.
>
> (initramfs) [   36.332020] ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
> [   36.352014] ata2: exception Emask 0x20 SAct 0x0 SErr 0x0 action 0x1 t4
> [   36.358538] ata2: irq_stat 0x20000000, host bus error
> [  241.500010] INFO: task knodemgrd_0:2454 blocked for more than 120 seconds.
> [  241.506881] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> [  241.514701] knodemgrd_0   D f64d119c     0  2454      2
> [  241.519964]  f6d29e64 00000046 00000001 f64d119c cb0620e0 cb062120 00000000 1f530d12
> [  241.527898]  00000001 f66d8000 00000000 00000003 00000001 c0eb25c8 c0ca4d48 f64d0cc0
> [  241.535834]  f64d0f58 cb0620e0 00000001 fffedfa0 f66d8000 f6d29e50 c0a2eda7 f6d29e50
> [  241.543771] Call Trace:
> [  241.546234]  [<c0ca4d48>] ? _spin_lock+0x8/0x10
> [  241.550767]  [<c0a2eda7>] ? finish_task_switch+0x57/0x100
> [  241.556166]  [<c0ca29b0>] ? schedule+0x4c0/0xac0
> [  241.560788]  [<c0ca33e5>] schedule_timeout+0x135/0x1a0
> [  241.565929]  [<c0a1d978>] ? default_spin_lock_flags+0x8/0x10
> [  241.571591]  [<f7cf7072>] ? ohci_transmit+0x62/0xb0 [ohci1394]
> [  241.577423]  [<c0a1d978>] ? default_spin_lock_flags+0x8/0x10
> [  241.583082]  [<c0ca31a0>] wait_for_common+0x100/0x130
> [  241.588137]  [<c0a2f8d0>] ? default_wake_function+0x0/0x10
> [  241.593623]  [<c0ca3262>] wait_for_completion+0x12/0x20
> [  241.598856]  [<f7cdf182>] hpsb_send_packet_and_wait+0x42/0x50 [ieee1394]
> [  241.605554]  [<f7ce0505>] hpsb_read+0x65/0xd0 [ieee1394]
> [  241.610869]  [<f7ce46e6>] nodemgr_host_thread+0x3d6/0xac0 [ieee1394]
> [  241.617223]  [<c0a3a75c>] ? do_exit+0x50c/0x720
> [  241.621757]  [<c0a2eda7>] ? finish_task_switch+0x57/0x100
> [  241.627158]  [<c0a26509>] ? complete+0x49/0x60
> [  241.631614]  [<f7ce4310>] ? nodemgr_host_thread+0x0/0xac0 [ieee1394]
> [  241.637958]  [<c0a4b93c>] kthread+0x3c/0x70
> [  241.642148]  [<c0a4b900>] ? kthread+0x0/0x70
> [  241.646423]  [<c0a03b37>] kernel_thread_helper+0x7/0x10
> [  361.648010] INFO: task knodemgrd_0:2454 blocked for more than 120 seconds.
> [  361.654876] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> [  361.662699] knodemgrd_0   D f64d119c     0  2454      2
> [  361.667962]  f6d29e64 00000046 00000001 f64d119c cb0620e0 cb062120 00000000 1f530d12
> [  361.675900]  00000001 f66d8000 00000000 00000003 00000001 c0eb25c8 c0ca4d48 f64d0cc0
> [  361....
 
[truncated message content]