Alexander Nilsson | 15 Mar 11:59 2014
Picon

Re: DMAR not found

Hi again!

Yes it seams it was some kind of firmware fault, however I did not have to update it, it was apparently enough to disable the VT-d feature in BIOS, doing a cold boot cycle and re-enable the feature again.

I think it's working now but on every boot I get the following TXT.ERRORCODE: 0xC0000001 which I can't figure out what it means, is this normal?

The complete log is available on: http://paste.ubuntu.com/7094797/

Anyway, thank you for your help, I would not have gotten this far without your response!

//Alexander Nilsson


2014-03-14 18:58 GMT+01:00 Ross Philipson <ross.philipson <at> citrix.com>:
On 03/14/2014 11:19 AM, Alexander Nilsson wrote:
Thank you for quick answer!

VT-d is enabled in the BIOS.

    $ ls /sys/firmware/acpi/tables
    APIC  ASF!  DBG2  DSDT  dynamic  ECDT  FACP  FACS  FPDT  HPET  MCFG
    MSDM  SSDT1  SSDT2  SSDT3  SSDT4  SSDT5  SSDT6  TCPA  UEFI1  UEFI2
    UEFI3

Right so it looks like you have firmware issues on this system. You should have a DMAR table - it is what describes the VT-d hardware and its capabilities. I guess the first step is to see if Lenovo has a firmware update.



There is nothing that look like DMAR in there. I did also a "sudo
acpidump | grep -i DMA" but nothing intresting showed up.

Once again, thank you for your quick reply!

//Alexander


2014-03-14 15:34 GMT+01:00 Ross Philipson <ross.philipson <at> citrix.com
<mailto:ross.philipson <at> citrix.com>>:


    On 03/14/2014 09:52 AM, Alexander Nilsson wrote:

        Hi!

        I'm trying to get tboot to work, but I'm getting nowhere fast.

        I've installed tboot (1.7.4-0ubuntu1 via apt-get) on xubuntu 32-bit
        (kernel 3.11.0-18-generic) on my machine (Lenovo Thinkpad Helix
        3701).

        Then I put the 3rd_gen_i5_i7_SINIT_67.BIN file in /boot/
        directory (got
        it form intel web page).

        I edited relevant lines in /boot/grub/grub.cfg to look like this:

             submenu "tboot 1.7.4" {
             menuentry 'Ubuntu GNU/Linux, with tboot 1.7.4 and Linux
             3.11.0-18-generic' --class ubuntu --class gnu-linux --class gnu
             --class os --class tboot {
                      insmod part_msdos
                      insmod ext2
                      set root='hd1,msdos1'
                      if [ x$feature_platform_search_hint = xy ]; then
                        search --no-floppy --fs-uuid --set=root
             --hint-bios=hd1,msdos1 --hint-efi=hd1,msdos1
             --hint-baremetal=ahci1,msdos1
          1ffcf898-aa43-4729-873a-__f17bd4342ca0

                      else
                        search --no-floppy --fs-uuid --set=root
             1ffcf898-aa43-4729-873a-__f17bd4342ca0

                      fi
                      echo    'Loading tboot 1.7.4 ...'
                      multiboot       /tboot.gz /tboot.gz
             logging=serial,vga,memory vga_delay=5
                      echo    'Loading Linux 3.11.0-18-generic ...'
                      module  /vmlinuz-3.11.0-18-generic
             /vmlinuz-3.11.0-18-generic
             root=UUID=abda87ef-d7e7-4411-__a3cc-49817ad7b692 ro  quiet

        splash
             intel_iommu=on
                      echo    'Loading initial ramdisk ...'
                      module  /initrd.img-3.11.0-18-generic
             /initrd.img-3.11.0-18-generic
                      echo    'Loading ACM module ...'
                      module  /3rd_gen_i5_i7_SINIT_67.BIN
             }


        After this i reboot and select "tboot ..." in grub menu.

        After displaying "Executing GETSEC[SENTER]..." the machine
        reboots and
        on the next attempt I get the following error:

             TXT.ERRORCODE: 0xC00010c1
             AC module error: acm_type=0x1, progress=0x0c, error=0x4


        I've decoded the error code as per SINIT_Errors.pdf from the
        intel web page:

             1 - Valid
             1 - External software
             000000 - Reserved
             00000000 - Minor Error code
             0 - Sotware source
             00100 - Major error code
             001100 - Class code
             0001 - Module type


        Acording to the pdf this indcates: Class ACPI Check, DMAR not found.

        I have really no idea where to go from here, what do you guys
        suggest?

        I would have included more logs in this message, but I only have
        them in
        JPEGs since I had to take pictures of the screen to save the
        output. If
        you think it will help I will attempt to transcribe them to text and
        post a link to pastebin ?


    Do you have VT-d enabled on the system? You will need to turn that
    on. If that is not the issue, you could try using acpidump or
    looking in /sys/firmware/acpi/tables to see if your DMAR table is
    actually there.


        Thank you in advance!

        //Alexander Nilsson


        ------------------------------__------------------------------__------------------

        Learn Graph Databases - Download FREE O'Reilly Book
        "Graph Databases" is the definitive new guide to graph databases
        and their
        applications. Written by three acclaimed leaders in the field,
        this first edition is now available. Download your free book today!
        http://p.sf.net/sfu/13534___NeoTech
        <http://p.sf.net/sfu/13534_NeoTech>



        _________________________________________________
        tboot-devel mailing list
        tboot-devel <at> lists.sourceforge.__net
        <mailto:tboot-devel <at> lists.sourceforge.net>
        https://lists.sourceforge.net/__lists/listinfo/tboot-devel

        <https://lists.sourceforge.net/lists/listinfo/tboot-devel>



    --
    Ross Philipson


------------------------------------------------------------------------

No virus found in this message.
Checked by AVG - www.avg.com <http://www.avg.com>
Version: 2014.0.4336 / Virus Database: 3722/7192 - Release Date: 03/13/14



--
Ross Philipson

------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/13534_NeoTech
_______________________________________________
tboot-devel mailing list
tboot-devel <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tboot-devel
Alexander Nilsson | 14 Mar 14:52 2014
Picon

DMAR not found

Hi!

I'm trying to get tboot to work, but I'm getting nowhere fast.

I've installed tboot (1.7.4-0ubuntu1 via apt-get) on xubuntu 32-bit (kernel 3.11.0-18-generic) on my machine (Lenovo Thinkpad Helix 3701).

Then I put the 3rd_gen_i5_i7_SINIT_67.BIN file in /boot/ directory (got it form intel web page).

I edited relevant lines in /boot/grub/grub.cfg to look like this:

submenu "tboot 1.7.4" {
menuentry 'Ubuntu GNU/Linux, with tboot 1.7.4 and Linux 3.11.0-18-generic' --class ubuntu --class gnu-linux --class gnu --class os --class tboot {
        insmod part_msdos
        insmod ext2
        set root='hd1,msdos1'
        if [ x$feature_platform_search_hint = xy ]; then
          search --no-floppy --fs-uuid --set=root --hint-bios=hd1,msdos1 --hint-efi=hd1,msdos1 --hint-baremetal=ahci1,msdos1  1ffcf898-aa43-4729-873a-f17bd4342ca0
        else
          search --no-floppy --fs-uuid --set=root 1ffcf898-aa43-4729-873a-f17bd4342ca0
        fi
        echo    'Loading tboot 1.7.4 ...'
        multiboot       /tboot.gz /tboot.gz logging=serial,vga,memory vga_delay=5
        echo    'Loading Linux 3.11.0-18-generic ...'
        module  /vmlinuz-3.11.0-18-generic /vmlinuz-3.11.0-18-generic root=UUID=abda87ef-d7e7-4411-a3cc-49817ad7b692 ro  quiet splash intel_iommu=on
        echo    'Loading initial ramdisk ...'
        module  /initrd.img-3.11.0-18-generic /initrd.img-3.11.0-18-generic
        echo    'Loading ACM module ...'
        module  /3rd_gen_i5_i7_SINIT_67.BIN
}

After this i reboot and select "tboot ..." in grub menu.

After displaying "Executing GETSEC[SENTER]..." the machine reboots and on the next attempt I get the following error:

TXT.ERRORCODE: 0xC00010c1
AC module error: acm_type=0x1, progress=0x0c, error=0x4

I've decoded the error code as per SINIT_Errors.pdf from the intel web page:

1 - Valid
1 - External software
000000 - Reserved
00000000 - Minor Error code
0 - Sotware source
00100 - Major error code
001100 - Class code
0001 - Module type

Acording to the pdf this indcates: Class ACPI Check, DMAR not found.

I have really no idea where to go from here, what do you guys suggest?

I would have included more logs in this message, but I only have them in JPEGs since I had to take pictures of the screen to save the output. If you think it will help I will attempt to transcribe them to text and post a link to pastebin ?

Thank you in advance!

//Alexander Nilsson
------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/13534_NeoTech
_______________________________________________
tboot-devel mailing list
tboot-devel <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tboot-devel
Ed Swierk | 20 Feb 19:47 2014
Gravatar

[PATCH] Fix crash when TPM is missing

The latest tboot crashes during boot if there's no TPM at all, because
write_tb_error_code() tries to dereference the null g_tpm pointer.

IMHO all the functions that dereference g_tpm should first check if
it's null, and return an error code. This patch fixes only one
instance.
diff --git a/tboot/common/tb_error.c b/tboot/common/tb_error.c
index 6038929..67ddf16 100644
--- a/tboot/common/tb_error.c
+++ b/tboot/common/tb_error.c
 <at>  <at>  -157,7 +157,7  <at>  <at>  bool read_tb_error_code(tb_error_t *error)
  */
 bool write_tb_error_code(tb_error_t error)
 {
-    if ( no_err_idx )
+    if ( !g_tpm || no_err_idx )
         return false;

     if ( !g_tpm->nv_write(g_tpm, 0, g_tpm->tb_err_index, 0,
------------------------------------------------------------------------------
Managing the Performance of Cloud-Based Applications
Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
Read the Whitepaper.
http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk
_______________________________________________
tboot-devel mailing list
tboot-devel <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tboot-devel
Ed Swierk | 20 Feb 19:49 2014
Gravatar

[PATCH] Fix infinite loop in determine_multiboot_type()

This patch fixes a bug in determine_multiboot_type() that causes an
infinite loop while searching for a multiboot header.
diff --git a/tboot/common/loader.c b/tboot/common/loader.c
index 0a35545..cdc1c6d 100644
--- a/tboot/common/loader.c
+++ b/tboot/common/loader.c
 <at>  <at>  -1164,14 +1164,14  <at>  <at>  determine_multiboot_type(void *image)
      */
     int result = MB_NONE;
     void *walker;
-    for (walker = image; walker < walker + MULTIBOOT_HEADER_SEARCH_LIMIT;
+    for (walker = image; walker < image + MULTIBOOT_HEADER_SEARCH_LIMIT;
          walker += sizeof(uint32_t)){
         if (*((uint32_t *)walker) == MULTIBOOT_HEADER_MAGIC){
             result += MB1_ONLY;
             break;
         }
     }
-    for (walker = image; walker < walker + MB2_HEADER_SEARCH_LIMIT;
+    for (walker = image; walker < image + MB2_HEADER_SEARCH_LIMIT;
          walker += sizeof(uint64_t)){
         if (*((uint32_t *)walker) == MB2_HEADER_MAGIC){
             result += MB2_ONLY;
------------------------------------------------------------------------------
Managing the Performance of Cloud-Based Applications
Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
Read the Whitepaper.
http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk
_______________________________________________
tboot-devel mailing list
tboot-devel <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tboot-devel
Kevin Walsh | 14 Jan 23:56 2014
Picon

SENTER reboots/hangs with i5-2500 and Q67 chipset, invalid SMRR config?

Greetings...

I am seeing reboot upon GETSEC[SENTER], and I am pretty much out of ideas on how to diagnose or work around the problem. I'm looking for help or ideas of where to go from here. This is on an i5-2500 platform with Q67 chipset. I'm using tboot 1.7.4 and 3rd_gen_i5_i7_SINIT_67.BIN (even though the main intel page says I should use the 2nd gen SINIT, most other sources, even those from intel, say that the 3rd gen is backwards compatible and the 2nd gen SINIT is "revoked").

I get this error code:
TBOOT: TXT.ERRORCODE: 0xc0002851
TBOOT: AC module error : acm_type=0x1, progress=0x05, error=0xa

The table says 0x05="chipset configuration" and 0xa="Invalid ILP SMRR configuration"

I updated bios from A06 to A11, with no change. I haven't been successful updating to bios A19.

I can find almost no documentation whatsoever about the SMRR register. I get the same error with or without a LC policy in place. The 2nd gen SINIT doesn't reboot in this same way, instead it simply freezes at GETSEC[SENTER}, requiring me to do a cold reboot and losing any stored TXT.ERRORCODE.

Suggestions?

Thanks
kw



------------------------------------------------------------------------------
WatchGuard Dimension instantly turns raw network data into actionable 
security intelligence. It gives you real-time visual feedback on key
security issues and trends.  Skip the complicated setup - simply import
a virtual appliance and go from zero to informed in seconds.
http://pubads.g.doubleclick.net/gampad/clk?id=123612991&iu=/4140/ostg.clktrk
_______________________________________________
tboot-devel mailing list
tboot-devel <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tboot-devel
Kevin Walsh | 14 Jan 23:20 2014

SENTER reboots/hangs with i5-2500 and Q67 chipset, invalid SMRR config?


I am seeing reboot upon GETSEC[SENTER], and I am pretty much out of ideas on how to diagnose or work around the problem. I'm looking for help or ideas of where to go from here. This is on an i5-2500 platform with Q67 chipset. I'm using tboot 1.7.4 and 3rd_gen_i5_i7_SINIT_67.BIN (even though the main intel page says I should use the 2nd gen SINIT, most other sources, even those from intel, say that the 3rd gen is backwards compatible and the 2nd gen SINIT is "revoked").

I get this error code:
TBOOT: TXT.ERRORCODE: 0xc0002851
TBOOT: AC module error : acm_type=0x1, progress=0x05, error=0xa

The table says 0x05="chipset configuration" and 0xa="Invalid ILP SMRR configuration"

I updated bios from A06 to A11, with no change. I haven't been successful updating to bios A19.

I can find almost no documentation whatsoever about the SMRR register. I get the same error with or without a LC policy in place. The 2nd gen SINIT doesn't reboot in this same way, instead it simply freezes at GETSEC[SENTER}, requiring me to do a cold reboot and losing any stored TXT.ERRORCODE.

Suggestions?

Thanks
kw


------------------------------------------------------------------------------
WatchGuard Dimension instantly turns raw network data into actionable 
security intelligence. It gives you real-time visual feedback on key
security issues and trends.  Skip the complicated setup - simply import
a virtual appliance and go from zero to informed in seconds.
http://pubads.g.doubleclick.net/gampad/clk?id=123612991&iu=/4140/ostg.clktrk
_______________________________________________
tboot-devel mailing list
tboot-devel <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tboot-devel
Nehal Bandi | 29 Jan 22:33 2014

tboot issue on an AMD machine

Hi,

 

Its written in the tboot docs that on the machine with no TXT support tboot launches the kernel without secure boot.

 

We were testing the behavior of tboot on variety of hardware and I found one issue on one of the AMD machine.

 

We are using tboot-1.7.3 for our environment.

 

Dell poweredge 415.
AMD 4130 processorDell poweredge 415.
AMD 4130 processor , BIOs version: 1.8.5

 

The machine never come out of tboot and keeps restarting.

 

Has anybody else seen this issue and any probable cause ?

 

Following is trace from the machine.  

 

Thanks in advance.

 

 

===================================================================

 

[2013-10-25 05:33:11 UTC] TBOOT: ******************* TBOOT *******************
[2013-10-25 05:33:11 UTC] TBOOT: 2013-09-05 17:05 -0400 160:1c1174e91a4d
[2013-10-25 05:33:11 UTC] TBOOT: *********************************************
[2013-10-25 05:33:11 UTC] TBOOT: command line: 
[2013-10-25 05:33:11 UTC] TBOOT: BSP is cpu 0
[2013-10-25 05:33:11 UTC] TBOOT: original e820 map:
[2013-10-25 05:33:11 UTC] TBOOT: 0000000000000000 - 00000000000a0000 (1)
[2013-10-25 05:33:11 UTC] TBOOT: 0000000000100000 - 00000000df699000 (1)
[2013-10-25 05:33:11 UTC] TBOOT: 00000000df699000 - 00000000df6af000 (2)
[2013-10-25 05:33:11 UTC] TBOOT: 00000000df6af000 - 00000000df6ce000 (3)
[2013-10-25 05:33:11 UTC] TBOOT: 00000000df6ce000 - 00000000e0000000 (2)
[2013-10-25 05:33:11 UTC] TBOOT: 00000000f0000000 - 00000000f4000000 (2)
[2013-10-25 05:33:11 UTC] TBOOT: 00000000fe000000 - 00000000fec90000 (2)
[2013-10-25 05:33:11 UTC] TBOOT: 00000000fec94000 - 00000000fecd0000 (2)
[2013-10-25 05:33:11 UTC] TBOOT: 00000000fecd4000 - 0000000100000000 (2)
[2013-10-25 05:33:11 UTC] TBOOT: 0000000100000000 - 0000000220000000 (1)
[2013-10-25 05:33:11 UTC] TBOOT: TPM is ready
[2013-10-25 05:33:11 UTC] TBOOT: TPM nv_locked: FALSE
[2013-10-25 05:33:11 UTC] TBOOT: TPM timeout values: A: 750, B: 750, C: 750, D: 750
[2013-10-25 05:33:11 UTC] TBOOT: Wrong timeout B, fallback to 2000
[2013-10-25 05:33:11 UTC] TBOOT: reading Verified Launch Policy from TPM NV...
[2013-10-25 05:33:11 UTC] TBOOT: TPM: get capability, return value = 00000002
[2013-10-25 05:33:11 UTC] TBOOT: TPM: fail to get public data of 0x20000001 in TPM NV
[2013-10-25 05:33:11 UTC] TBOOT: :reading failed
[2013-10-25 05:33:11 UTC] TBOOT: reading Launch Control Policy from TPM NV...
[2013-10-25 05:33:11 UTC] TBOOT: TPM: get capability, return value = 00000002
[2013-10-25 05:33:11 UTC] TBOOT: TPM: fail to get public data of 0x40000001 in TPM NV
[2013-10-25 05:33:11 UTC] TBOOT: :reading failed
[2013-10-25 05:33:11 UTC] TBOOT: failed to read policy from TPM NV, using default
[2013-10-25 05:33:11 UTC] TBOOT: policy:
[2013-10-25 05:33:11 UTC] TBOOT: version: 2
[2013-10-25 05:33:11 UTC] TBOOT: policy_type: TB_POLTYPE_CONT_NON_FATAL
[2013-10-25 05:33:11 UTC] TBOOT: hash_alg: TB_HALG_SHA1
[2013-10-25 05:33:11 UTC] TBOOT: policy_control: 00000001 (EXTEND_PCR17)
[2013-10-25 05:33:11 UTC] TBOOT: num_entries: 2
[2013-10-25 05:33:11 UTC] TBOOT: policy entry[0]:
[2013-10-25 05:33:11 UTC] TBOOT: mod_num: 0
[2013-10-25 05:33:11 UTC] TBOOT: pcr: none
[2013-10-25 05:33:11 UTC] TBOOT: hash_type: TB_HTYPE_ANY
[2013-10-25 05:33:11 UTC] TBOOT: num_hashes: 0
[2013-10-25 05:33:11 UTC] TBOOT: policy entry[1]:
[2013-10-25 05:33:11 UTC] TBOOT: mod_num: any
[2013-10-25 05:33:11 UTC] TBOOT: pcr: 19
[2013-10-25 05:33:11 UTC] TBOOT: hash_type: TB_HTYPE_ANY
[2013-10-25 05:33:11 UTC] TBOOT: num_hashes: 0
[2013-10-25 05:33:11 UTC] TBOOT: TPM: write nv 20000002, offset 00000000, 00000004 bytes, return = 00000002
[2013-10-25 05:33:11 UTC] TBOOT: Error: write TPM error: 0x2.
[2013-10-25 05:33:11 UTC] TBOOT: no policy in TPM NV.
[2013-10-25 05:33:11 UTC] TBOOT: ******************* TBOOT *******************
[2013-10-25 05:33:11 UTC] TBOOT: 2013-09-05 17:05 -0400 160:1c1174e91a4d
[2013-10-25 05:33:11 UTC] TBOOT: *********************************************
[2013-10-25 05:33:11 UTC] TBOOT: command line: 
[2013-10-25 05:33:11 UTC] TBOOT: BSP is cpu 0
[2013-10-25 05:33:11 UTC] TBOOT: original e820 map:
[2013-10-25 05:33:11 UTC] TBOOT: 0000000000000000 - 00000000000a0000 (1)
[2013-10-25 05:33:11 UTC] TBOOT: 0000000000100000 - 00000000df699000 (1)
[2013-10-25 05:33:11 UTC] TBOOT: 00000000df699000 - 00000000df6af000 (2)
[2013-10-25 05:33:11 UTC] TBOOT: 00000000df6af000 - 00000000df6ce000 (3)
[2013-10-25 05:33:11 UTC] TBOOT: 00000000df6ce000 - 00000000e0000000 (2)
[2013-10-25 05:33:11 UTC] TBOOT: 00000000f0000000 - 00000000f4000000 (2)
[2013-10-25 05:33:11 UTC] TBOOT: 00000000fe000000 - 00000000fec90000 (2)
[2013-10-25 05:33:11 UTC] TBOOT: 00000000fec94000 - 00000000fecd0000 (2)
[2013-10-25 05:33:11 UTC] TBOOT: 00000000fecd4000 - 0000000100000000 (2)
[2013-10-25 05:33:11 UTC] TBOOT: 0000000100000000 - 0000000220000000 (1)
[2013-10-25 05:33:11 UTC] TBOOT: TPM is ready
[2013-10-25 05:33:11 UTC] TBOOT: TPM nv_locked: FALSE
[2013-10-25 05:33:11 UTC] TBOOT: TPM timeout values: A: 750, B: 750, C: 750, D: 750
[2013-10-25 05:33:11 UTC] TBOOT: Wrong timeout B, fallback to 2000
[2013-10-25 05:33:11 UTC] TBOOT: reading Verified Launch Policy from TPM NV...
[2013-10-25 05:33:11 UTC] TBOOT: TPM: get capability, return value = 00000002
[2013-10-25 05:33:11 UTC] TBOOT: TPM: fail to get public data of 0x20000001 in TPM NV
[2013-10-25 05:33:11 UTC] TBOOT: :reading failed
[2013-10-25 05:33:11 UTC] TBOOT: reading Launch Control Policy from TPM NV...
[2013-10-25 05:33:11 UTC] TBOOT: TPM: get capability, return value = 00000002
[2013-10-25 05:33:11 UTC] TBOOT: TPM: fail to get public data of 0x40000001 in TPM NV
[2013-10-25 05:33:11 UTC] TBOOT: :reading failed
[2013-10-25 05:33:11 UTC] TBOOT: failed to read policy from TPM NV, using default
[2013-10-25 05:33:11 UTC] TBOOT: policy:
[2013-10-25 05:33:11 UTC] TBOOT: version: 2
[2013-10-25 05:33:11 UTC] TBOOT: policy_type: TB_POLTYPE_CONT_NON_FATAL
[2013-10-25 05:33:12 UTC] TBOOT: hash_alg: TB_HALG_SHA1
[2013-10-25 05:33:12 UTC] TBOOT: policy_control: 00000001 (EXTEND_PCR17)
[2013-10-25 05:33:12 UTC] TBOOT: num_entries: 2
[2013-10-25 05:33:12 UTC] TBOOT: policy entry[0]:
[2013-10-25 05:33:12 UTC] TBOOT: mod_num: 0
[2013-10-25 05:33:12 UTC] TBOOT: pcr: none
[2013-10-25 05:33:12 UTC] TBOOT: hash_type: TB_HTYPE_ANY
[2013-10-25 05:33:12 UTC] TBOOT: num_hashes: 0
[2013-10-25 05:33:12 UTC] TBOOT: policy entry[1]:
[2013-10-25 05:33:12 UTC] TBOOT: mod_num: any
[2013-10-25 05:33:12 UTC] TBOOT: pcr: 19
[2013-10-25 05:33:12 UTC] TBOOT: hash_type: TB_HTYPE_ANY
[2013-10-25 05:33:12 UTC] TBOOT: num_hashes: 0
[2013-10-25 05:33:12 UTC] TBOOT: TPM: write nv 20000002, offset 00000000, 00000004 bytes, return = 00000002
[2013-10-25 05:33:12 UTC] TBOOT: Error: write TPM error: 0x2.
[2013-10-25 05:33:12 UTC] TBOOT: no policy in TPM NV.
[2013-10-25 05:33:12 UTC] TBOOT: ******************* TBOOT *******************
[2013-10-25 05:33:12 UTC] TBOOT: 2013-09-05 17:05 -0400 160:1c1174e91a4d
[2013-10-25 05:33:12 UTC] TBOOT: *********************************************
[2013-10-25 05:33:12 UTC] TBOOT: command line: 
[2013-10-25 05:33:12 UTC] TBOOT: BSP is cpu 0
[2013-10-25 05:33:12 UTC] TBOOT: original e820 map:
[2013-10-25 05:33:12 UTC] TBOOT: 0000000000000000 - 00000000000a0000 (1)
[2013-10-25 05:33:12 UTC] TBOOT: 0000000000100000 - 00000000df699000 (1)
[2013-10-25 05:33:12 UTC] TBOOT: 00000000df699000 - 00000000df6af000 (2)
[2013-10-25 05:33:12 UTC] TBOOT: 00000000df6af000 - 00000000df6ce000 (3)
[2013-10-25 05:33:12 UTC] TBOOT: 00000000df6ce000 - 00000000e0000000 (2)
[2013-10-25 05:33:12 UTC] TBOOT: 00000000f0000000 - 00000000f4000000 (2)
[2013-10-25 05:33:12 UTC] TBOOT: 00000000fe000000 - 00000000fec90000 (2)
[2013-10-25 05:33:12 UTC] TBOOT: 00000000fec94000 - 00000000fecd0000 (2)
[2013-10-25 05:33:12 UTC] TBOOT: 00000000fecd4000 - 0000000100000000 (2)
[2013-10-25 05:33:12 UTC] TBOOT: 0000000100000000 - 0000000220000000 (1)
[2013-10-25 05:33:12 UTC] TBOOT: TPM is ready
[2013-10-25 05:33:12 UTC] TBOOT: TPM nv_locked: FALSE
[2013-10-25 05:33:12 UTC] TBOOT: TPM timeout values: A: 750, B: 750, C: 750, D: 750
[2013-10-25 05:33:12 UTC] TBOOT: Wrong timeout B, fallback to 2000
[2013-10-25 05:33:12 UTC] TBOOT: reading Verified Launch Policy from TPM NV...
[2013-10-25 05:33:12 UTC] TBOOT: TPM: get capability, return value = 00000002
[2013-10-25 05:33:12 UTC] TBOOT: TPM: fail to get public data of 0x20000001 in TPM NV
[2013-10-25 05:33:12 UTC] TBOOT: :reading failed
[2013-10-25 05:33:12 UTC] TBOOT: reading Launch Control Policy from TPM NV...
[2013-10-25 05:33:12 UTC] TBOOT: TPM: get capability, return value = 00000002
[2013-10-25 05:33:12 UTC] TBOOT: TPM: fail to get public data of 0x40000001 in TPM NV
[2013-10-25 05:33:12 UTC] TBOOT: :reading failed
[2013-10-25 05:33:12 UTC] TBOOT: failed to read policy from TPM NV, using default
[2013-10-25 05:33:12 UTC] TBOOT: policy:
[2013-10-25 05:33:12 UTC] TBOOT: version: 2
[2013-10-25 05:33:12 UTC] TBOOT: policy_type: TB_POLTYPE_CONT_NON_FATAL
[2013-10-25 05:33:12 UTC] TBOOT: hash_alg: TB_HALG_SHA1
[2013-10-25 05:33:12 UTC] TBOOT: policy_control: 00000001 (EXTEND_PCR17)
[2013-10-25 05:33:12 UTC] TBOOT: num_entries: 2
[2013-10-25 05:33:12 UTC] TBOOT: policy entry[0]:
[2013-10-25 05:33:12 UTC] TBOOT: mod_num: 0
[2013-10-25 05:33:12 UTC] TBOOT: pcr: none
[2013-10-25 05:33:12 UTC] TBOOT: hash_type: TB_HTYPE_ANY
[2013-10-25 05:33:12 UTC] TBOOT: num_hashes: 0
[2013-10-25 05:33:12 UTC] TBOOT: policy entry[1]:
[2013-10-25 05:33:12 UTC] TBOOT: mod_num: any
[2013-10-25 05:33:12 UTC] TBOOT: pcr: 19
[2013-10-25 05:33:12 UTC] TBOOT: hash_type: TB_HTYPE_ANY
[2013-10-25 05:33:12 UTC] TBOOT: num_hashes: 0
[2013-10-25 05:33:12 UTC] TBOOT: TPM: write nv 20000002, offset 00000000, 00000004 bytes, return = 00000002
[2013-10-25 05:33:12 UTC] TBOOT: Error: write TPM error: 0x2.
[2013-10-25 05:33:12 UTC] TBOOT: no policy in TPM NV.

 

-Regards,

Nehal

------------------------------------------------------------------------------
WatchGuard Dimension instantly turns raw network data into actionable 
security intelligence. It gives you real-time visual feedback on key
security issues and trends.  Skip the complicated setup - simply import
a virtual appliance and go from zero to informed in seconds.
http://pubads.g.doubleclick.net/gampad/clk?id=123612991&iu=/4140/ostg.clktrk
_______________________________________________
tboot-devel mailing list
tboot-devel <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tboot-devel
Wei, Gang | 30 Jan 11:23 2014
Picon

tboot 1.8.0 released

This major release is to provide EFI boot support, TPM NV measuring, and
TPM2.0 support. The EFI & TPM2 support are not fully completed yet, more
enhancements will coming in next minor release.

Source package tboot-1.8.0.tar.gz can be downloaded from sourceforge.net.

Major changes since 1.7.4 (20130705):
	Update README for TPM2 support
	tpm2 support
	Adding sha256 algorithm implementation
	Update README for TPM NV measuring
	Update README for EFI support
	Fix typo in tboot/Makefile
	Increase the supported maximum number of cpus from 256 to 512
	Extend tboot policy supporting measuring TPM NV
	EFI support via multiboot2 changes
	Fix typo in common/hash.c
	Fix verification for extended data elements in txt heap

Please help testing it, and enjoy it.

Thanks
Jimmy
Attachment (smime.p7s): application/pkcs7-signature, 12 KiB
------------------------------------------------------------------------------
WatchGuard Dimension instantly turns raw network data into actionable 
security intelligence. It gives you real-time visual feedback on key
security issues and trends.  Skip the complicated setup - simply import
a virtual appliance and go from zero to informed in seconds.
http://pubads.g.doubleclick.net/gampad/clk?id=123612991&iu=/4140/ostg.clktrk
_______________________________________________
tboot-devel mailing list
tboot-devel <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tboot-devel
Nehal Bandi | 29 Jan 00:51 2014

Patch for inserting a hashtag in to TPM PCR from TPM NV location.

Hi,

 

I have a patch for tboot which reads a SHA1 from an index location from TPM NV ram and

Extend PCR-22 from the value within tboot.

 

This patch can be used for secure PCR  extention from TPM NV location.

 

Please let me know the feedback on the patch.

 

-Regards,

Nehal

Attachment (asset_tag.patch): application/octet-stream, 5423 bytes
------------------------------------------------------------------------------
WatchGuard Dimension instantly turns raw network data into actionable 
security intelligence. It gives you real-time visual feedback on key
security issues and trends.  Skip the complicated setup - simply import
a virtual appliance and go from zero to informed in seconds.
http://pubads.g.doubleclick.net/gampad/clk?id=123612991&iu=/4140/ostg.clktrk
_______________________________________________
tboot-devel mailing list
tboot-devel <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tboot-devel
Martin Thiim | 10 Dec 19:04 2013
Picon

TXT vs SGX

Hi

A few months back, Intel released a lot of documentation on the upcoming security technology, Software Guard Extensions. There seems to be quite some overlap between the objectives of the two technologies, but they are not directly incompatible and according to the SGX manual it is possible to launch SGX enclaves from within TXT/SMX mode (but not the other way around). Does anyone know when SGX will become available and what is the future of TXT after this? Thanks!


Best regards,


Martin Thiim

------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
_______________________________________________
tboot-devel mailing list
tboot-devel <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tboot-devel
Qiaowei Ren | 10 Dec 07:16 2013
Picon

[PATCH] Documentation: move intel_txt.txt to Documentation/x86

Documentation/x86 is a more fitting place for intel_txt.txt.

Signed-off-by: Qiaowei Ren <qiaowei.ren <at> intel.com>
---
 Documentation/intel_txt.txt     |  210 ---------------------------------------
 Documentation/x86/intel_txt.txt |  210 +++++++++++++++++++++++++++++++++++++++
 2 files changed, 210 insertions(+), 210 deletions(-)
 delete mode 100644 Documentation/intel_txt.txt
 create mode 100644 Documentation/x86/intel_txt.txt

diff --git a/Documentation/intel_txt.txt b/Documentation/intel_txt.txt
deleted file mode 100644
index 91d89c5..0000000
--- a/Documentation/intel_txt.txt
+++ /dev/null
 <at>  <at>  -1,210 +0,0  <at>  <at> 
-Intel(R) TXT Overview:
-=====================
-
-Intel's technology for safer computing, Intel(R) Trusted Execution
-Technology (Intel(R) TXT), defines platform-level enhancements that
-provide the building blocks for creating trusted platforms.
-
-Intel TXT was formerly known by the code name LaGrande Technology (LT).
-
-Intel TXT in Brief:
-o  Provides dynamic root of trust for measurement (DRTM)
-o  Data protection in case of improper shutdown
-o  Measurement and verification of launched environment
-
-Intel TXT is part of the vPro(TM) brand and is also available some
-non-vPro systems.  It is currently available on desktop systems
-based on the Q35, X38, Q45, and Q43 Express chipsets (e.g. Dell
-Optiplex 755, HP dc7800, etc.) and mobile systems based on the GM45,
-PM45, and GS45 Express chipsets.
-
-For more information, see http://www.intel.com/technology/security/.
-This site also has a link to the Intel TXT MLE Developers Manual,
-which has been updated for the new released platforms.
-
-Intel TXT has been presented at various events over the past few
-years, some of which are:
-      LinuxTAG 2008:
-          http://www.linuxtag.org/2008/en/conf/events/vp-donnerstag.html
-      TRUST2008:
-          http://www.trust-conference.eu/downloads/Keynote-Speakers/
-          3_David-Grawrock_The-Front-Door-of-Trusted-Computing.pdf
-      IDF, Shanghai:
-          http://www.prcidf.com.cn/index_en.html
-      IDFs 2006, 2007 (I'm not sure if/where they are online)
-
-Trusted Boot Project Overview:
-=============================
-
-Trusted Boot (tboot) is an open source, pre-kernel/VMM module that
-uses Intel TXT to perform a measured and verified launch of an OS
-kernel/VMM.
-
-It is hosted on SourceForge at http://sourceforge.net/projects/tboot.
-The mercurial source repo is available at http://www.bughost.org/
-repos.hg/tboot.hg.
-
-Tboot currently supports launching Xen (open source VMM/hypervisor
-w/ TXT support since v3.2), and now Linux kernels.
-
-
-Value Proposition for Linux or "Why should you care?"
-=====================================================
-
-While there are many products and technologies that attempt to
-measure or protect the integrity of a running kernel, they all
-assume the kernel is "good" to begin with.  The Integrity
-Measurement Architecture (IMA) and Linux Integrity Module interface
-are examples of such solutions.
-
-To get trust in the initial kernel without using Intel TXT, a
-static root of trust must be used.  This bases trust in BIOS
-starting at system reset and requires measurement of all code
-executed between system reset through the completion of the kernel
-boot as well as data objects used by that code.  In the case of a
-Linux kernel, this means all of BIOS, any option ROMs, the
-bootloader and the boot config.  In practice, this is a lot of
-code/data, much of which is subject to change from boot to boot
-(e.g. changing NICs may change option ROMs).  Without reference
-hashes, these measurement changes are difficult to assess or
-confirm as benign.  This process also does not provide DMA
-protection, memory configuration/alias checks and locks, crash
-protection, or policy support.
-
-By using the hardware-based root of trust that Intel TXT provides,
-many of these issues can be mitigated.  Specifically: many
-pre-launch components can be removed from the trust chain, DMA
-protection is provided to all launched components, a large number
-of platform configuration checks are performed and values locked,
-protection is provided for any data in the event of an improper
-shutdown, and there is support for policy-based execution/verification.
-This provides a more stable measurement and a higher assurance of
-system configuration and initial state than would be otherwise
-possible.  Since the tboot project is open source, source code for
-almost all parts of the trust chain is available (excepting SMM and
-Intel-provided firmware).
-
-How Does it Work?
-=================
-
-o  Tboot is an executable that is launched by the bootloader as
-   the "kernel" (the binary the bootloader executes).
-o  It performs all of the work necessary to determine if the
-   platform supports Intel TXT and, if so, executes the GETSEC[SENTER]
-   processor instruction that initiates the dynamic root of trust.
-   -  If tboot determines that the system does not support Intel TXT
-      or is not configured correctly (e.g. the SINIT AC Module was
-      incorrect), it will directly launch the kernel with no changes
-      to any state.
-   -  Tboot will output various information about its progress to the
-      terminal, serial port, and/or an in-memory log; the output
-      locations can be configured with a command line switch.
-o  The GETSEC[SENTER] instruction will return control to tboot and
-   tboot then verifies certain aspects of the environment (e.g. TPM NV
-   lock, e820 table does not have invalid entries, etc.).
-o  It will wake the APs from the special sleep state the GETSEC[SENTER]
-   instruction had put them in and place them into a wait-for-SIPI
-   state.
-   -  Because the processors will not respond to an INIT or SIPI when
-      in the TXT environment, it is necessary to create a small VT-x
-      guest for the APs.  When they run in this guest, they will
-      simply wait for the INIT-SIPI-SIPI sequence, which will cause
-      VMEXITs, and then disable VT and jump to the SIPI vector.  This
-      approach seemed like a better choice than having to insert
-      special code into the kernel's MP wakeup sequence.
-o  Tboot then applies an (optional) user-defined launch policy to
-   verify the kernel and initrd.
-   -  This policy is rooted in TPM NV and is described in the tboot
-      project.  The tboot project also contains code for tools to
-      create and provision the policy.
-   -  Policies are completely under user control and if not present
-      then any kernel will be launched.
-   -  Policy action is flexible and can include halting on failures
-      or simply logging them and continuing.
-o  Tboot adjusts the e820 table provided by the bootloader to reserve
-   its own location in memory as well as to reserve certain other
-   TXT-related regions.
-o  As part of its launch, tboot DMA protects all of RAM (using the
-   VT-d PMRs).  Thus, the kernel must be booted with 'intel_iommu=on'
-   in order to remove this blanket protection and use VT-d's
-   page-level protection.
-o  Tboot will populate a shared page with some data about itself and
-   pass this to the Linux kernel as it transfers control.
-   -  The location of the shared page is passed via the boot_params
-      struct as a physical address.
-o  The kernel will look for the tboot shared page address and, if it
-   exists, map it.
-o  As one of the checks/protections provided by TXT, it makes a copy
-   of the VT-d DMARs in a DMA-protected region of memory and verifies
-   them for correctness.  The VT-d code will detect if the kernel was
-   launched with tboot and use this copy instead of the one in the
-   ACPI table.
-o  At this point, tboot and TXT are out of the picture until a
-   shutdown (S<n>)
-o  In order to put a system into any of the sleep states after a TXT
-   launch, TXT must first be exited.  This is to prevent attacks that
-   attempt to crash the system to gain control on reboot and steal
-   data left in memory.
-   -  The kernel will perform all of its sleep preparation and
-      populate the shared page with the ACPI data needed to put the
-      platform in the desired sleep state.
-   -  Then the kernel jumps into tboot via the vector specified in the
-      shared page.
-   -  Tboot will clean up the environment and disable TXT, then use the
-      kernel-provided ACPI information to actually place the platform
-      into the desired sleep state.
-   -  In the case of S3, tboot will also register itself as the resume
-      vector.  This is necessary because it must re-establish the
-      measured environment upon resume.  Once the TXT environment
-      has been restored, it will restore the TPM PCRs and then
-      transfer control back to the kernel's S3 resume vector.
-      In order to preserve system integrity across S3, the kernel
-      provides tboot with a set of memory ranges (RAM and RESERVED_KERN
-      in the e820 table, but not any memory that BIOS might alter over
-      the S3 transition) that tboot will calculate a MAC (message
-      authentication code) over and then seal with the TPM. On resume
-      and once the measured environment has been re-established, tboot
-      will re-calculate the MAC and verify it against the sealed value.
-      Tboot's policy determines what happens if the verification fails.
-      Note that the c/s 194 of tboot which has the new MAC code supports
-      this.
-
-That's pretty much it for TXT support.
-
-
-Configuring the System:
-======================
-
-This code works with 32bit, 32bit PAE, and 64bit (x86_64) kernels.
-
-In BIOS, the user must enable:  TPM, TXT, VT-x, VT-d.  Not all BIOSes
-allow these to be individually enabled/disabled and the screens in
-which to find them are BIOS-specific.
-
-grub.conf needs to be modified as follows:
-        title Linux 2.6.29-tip w/ tboot
-          root (hd0,0)
-                kernel /tboot.gz logging=serial,vga,memory
-                module /vmlinuz-2.6.29-tip intel_iommu=on ro
-                       root=LABEL=/ rhgb console=ttyS0,115200 3
-                module /initrd-2.6.29-tip.img
-                module /Q35_SINIT_17.BIN
-
-The kernel option for enabling Intel TXT support is found under the
-Security top-level menu and is called "Enable Intel(R) Trusted
-Execution Technology (TXT)".  It is considered EXPERIMENTAL and
-depends on the generic x86 support (to allow maximum flexibility in
-kernel build options), since the tboot code will detect whether the
-platform actually supports Intel TXT and thus whether any of the
-kernel code is executed.
-
-The Q35_SINIT_17.BIN file is what Intel TXT refers to as an
-Authenticated Code Module.  It is specific to the chipset in the
-system and can also be found on the Trusted Boot site.  It is an
-(unencrypted) module signed by Intel that is used as part of the
-DRTM process to verify and configure the system.  It is signed
-because it operates at a higher privilege level in the system than
-any other macrocode and its correct operation is critical to the
-establishment of the DRTM.  The process for determining the correct
-SINIT ACM for a system is documented in the SINIT-guide.txt file
-that is on the tboot SourceForge site under the SINIT ACM downloads.
diff --git a/Documentation/x86/intel_txt.txt b/Documentation/x86/intel_txt.txt
new file mode 100644
index 0000000..91d89c5
--- /dev/null
+++ b/Documentation/x86/intel_txt.txt
 <at>  <at>  -0,0 +1,210  <at>  <at> 
+Intel(R) TXT Overview:
+=====================
+
+Intel's technology for safer computing, Intel(R) Trusted Execution
+Technology (Intel(R) TXT), defines platform-level enhancements that
+provide the building blocks for creating trusted platforms.
+
+Intel TXT was formerly known by the code name LaGrande Technology (LT).
+
+Intel TXT in Brief:
+o  Provides dynamic root of trust for measurement (DRTM)
+o  Data protection in case of improper shutdown
+o  Measurement and verification of launched environment
+
+Intel TXT is part of the vPro(TM) brand and is also available some
+non-vPro systems.  It is currently available on desktop systems
+based on the Q35, X38, Q45, and Q43 Express chipsets (e.g. Dell
+Optiplex 755, HP dc7800, etc.) and mobile systems based on the GM45,
+PM45, and GS45 Express chipsets.
+
+For more information, see http://www.intel.com/technology/security/.
+This site also has a link to the Intel TXT MLE Developers Manual,
+which has been updated for the new released platforms.
+
+Intel TXT has been presented at various events over the past few
+years, some of which are:
+      LinuxTAG 2008:
+          http://www.linuxtag.org/2008/en/conf/events/vp-donnerstag.html
+      TRUST2008:
+          http://www.trust-conference.eu/downloads/Keynote-Speakers/
+          3_David-Grawrock_The-Front-Door-of-Trusted-Computing.pdf
+      IDF, Shanghai:
+          http://www.prcidf.com.cn/index_en.html
+      IDFs 2006, 2007 (I'm not sure if/where they are online)
+
+Trusted Boot Project Overview:
+=============================
+
+Trusted Boot (tboot) is an open source, pre-kernel/VMM module that
+uses Intel TXT to perform a measured and verified launch of an OS
+kernel/VMM.
+
+It is hosted on SourceForge at http://sourceforge.net/projects/tboot.
+The mercurial source repo is available at http://www.bughost.org/
+repos.hg/tboot.hg.
+
+Tboot currently supports launching Xen (open source VMM/hypervisor
+w/ TXT support since v3.2), and now Linux kernels.
+
+
+Value Proposition for Linux or "Why should you care?"
+=====================================================
+
+While there are many products and technologies that attempt to
+measure or protect the integrity of a running kernel, they all
+assume the kernel is "good" to begin with.  The Integrity
+Measurement Architecture (IMA) and Linux Integrity Module interface
+are examples of such solutions.
+
+To get trust in the initial kernel without using Intel TXT, a
+static root of trust must be used.  This bases trust in BIOS
+starting at system reset and requires measurement of all code
+executed between system reset through the completion of the kernel
+boot as well as data objects used by that code.  In the case of a
+Linux kernel, this means all of BIOS, any option ROMs, the
+bootloader and the boot config.  In practice, this is a lot of
+code/data, much of which is subject to change from boot to boot
+(e.g. changing NICs may change option ROMs).  Without reference
+hashes, these measurement changes are difficult to assess or
+confirm as benign.  This process also does not provide DMA
+protection, memory configuration/alias checks and locks, crash
+protection, or policy support.
+
+By using the hardware-based root of trust that Intel TXT provides,
+many of these issues can be mitigated.  Specifically: many
+pre-launch components can be removed from the trust chain, DMA
+protection is provided to all launched components, a large number
+of platform configuration checks are performed and values locked,
+protection is provided for any data in the event of an improper
+shutdown, and there is support for policy-based execution/verification.
+This provides a more stable measurement and a higher assurance of
+system configuration and initial state than would be otherwise
+possible.  Since the tboot project is open source, source code for
+almost all parts of the trust chain is available (excepting SMM and
+Intel-provided firmware).
+
+How Does it Work?
+=================
+
+o  Tboot is an executable that is launched by the bootloader as
+   the "kernel" (the binary the bootloader executes).
+o  It performs all of the work necessary to determine if the
+   platform supports Intel TXT and, if so, executes the GETSEC[SENTER]
+   processor instruction that initiates the dynamic root of trust.
+   -  If tboot determines that the system does not support Intel TXT
+      or is not configured correctly (e.g. the SINIT AC Module was
+      incorrect), it will directly launch the kernel with no changes
+      to any state.
+   -  Tboot will output various information about its progress to the
+      terminal, serial port, and/or an in-memory log; the output
+      locations can be configured with a command line switch.
+o  The GETSEC[SENTER] instruction will return control to tboot and
+   tboot then verifies certain aspects of the environment (e.g. TPM NV
+   lock, e820 table does not have invalid entries, etc.).
+o  It will wake the APs from the special sleep state the GETSEC[SENTER]
+   instruction had put them in and place them into a wait-for-SIPI
+   state.
+   -  Because the processors will not respond to an INIT or SIPI when
+      in the TXT environment, it is necessary to create a small VT-x
+      guest for the APs.  When they run in this guest, they will
+      simply wait for the INIT-SIPI-SIPI sequence, which will cause
+      VMEXITs, and then disable VT and jump to the SIPI vector.  This
+      approach seemed like a better choice than having to insert
+      special code into the kernel's MP wakeup sequence.
+o  Tboot then applies an (optional) user-defined launch policy to
+   verify the kernel and initrd.
+   -  This policy is rooted in TPM NV and is described in the tboot
+      project.  The tboot project also contains code for tools to
+      create and provision the policy.
+   -  Policies are completely under user control and if not present
+      then any kernel will be launched.
+   -  Policy action is flexible and can include halting on failures
+      or simply logging them and continuing.
+o  Tboot adjusts the e820 table provided by the bootloader to reserve
+   its own location in memory as well as to reserve certain other
+   TXT-related regions.
+o  As part of its launch, tboot DMA protects all of RAM (using the
+   VT-d PMRs).  Thus, the kernel must be booted with 'intel_iommu=on'
+   in order to remove this blanket protection and use VT-d's
+   page-level protection.
+o  Tboot will populate a shared page with some data about itself and
+   pass this to the Linux kernel as it transfers control.
+   -  The location of the shared page is passed via the boot_params
+      struct as a physical address.
+o  The kernel will look for the tboot shared page address and, if it
+   exists, map it.
+o  As one of the checks/protections provided by TXT, it makes a copy
+   of the VT-d DMARs in a DMA-protected region of memory and verifies
+   them for correctness.  The VT-d code will detect if the kernel was
+   launched with tboot and use this copy instead of the one in the
+   ACPI table.
+o  At this point, tboot and TXT are out of the picture until a
+   shutdown (S<n>)
+o  In order to put a system into any of the sleep states after a TXT
+   launch, TXT must first be exited.  This is to prevent attacks that
+   attempt to crash the system to gain control on reboot and steal
+   data left in memory.
+   -  The kernel will perform all of its sleep preparation and
+      populate the shared page with the ACPI data needed to put the
+      platform in the desired sleep state.
+   -  Then the kernel jumps into tboot via the vector specified in the
+      shared page.
+   -  Tboot will clean up the environment and disable TXT, then use the
+      kernel-provided ACPI information to actually place the platform
+      into the desired sleep state.
+   -  In the case of S3, tboot will also register itself as the resume
+      vector.  This is necessary because it must re-establish the
+      measured environment upon resume.  Once the TXT environment
+      has been restored, it will restore the TPM PCRs and then
+      transfer control back to the kernel's S3 resume vector.
+      In order to preserve system integrity across S3, the kernel
+      provides tboot with a set of memory ranges (RAM and RESERVED_KERN
+      in the e820 table, but not any memory that BIOS might alter over
+      the S3 transition) that tboot will calculate a MAC (message
+      authentication code) over and then seal with the TPM. On resume
+      and once the measured environment has been re-established, tboot
+      will re-calculate the MAC and verify it against the sealed value.
+      Tboot's policy determines what happens if the verification fails.
+      Note that the c/s 194 of tboot which has the new MAC code supports
+      this.
+
+That's pretty much it for TXT support.
+
+
+Configuring the System:
+======================
+
+This code works with 32bit, 32bit PAE, and 64bit (x86_64) kernels.
+
+In BIOS, the user must enable:  TPM, TXT, VT-x, VT-d.  Not all BIOSes
+allow these to be individually enabled/disabled and the screens in
+which to find them are BIOS-specific.
+
+grub.conf needs to be modified as follows:
+        title Linux 2.6.29-tip w/ tboot
+          root (hd0,0)
+                kernel /tboot.gz logging=serial,vga,memory
+                module /vmlinuz-2.6.29-tip intel_iommu=on ro
+                       root=LABEL=/ rhgb console=ttyS0,115200 3
+                module /initrd-2.6.29-tip.img
+                module /Q35_SINIT_17.BIN
+
+The kernel option for enabling Intel TXT support is found under the
+Security top-level menu and is called "Enable Intel(R) Trusted
+Execution Technology (TXT)".  It is considered EXPERIMENTAL and
+depends on the generic x86 support (to allow maximum flexibility in
+kernel build options), since the tboot code will detect whether the
+platform actually supports Intel TXT and thus whether any of the
+kernel code is executed.
+
+The Q35_SINIT_17.BIN file is what Intel TXT refers to as an
+Authenticated Code Module.  It is specific to the chipset in the
+system and can also be found on the Trusted Boot site.  It is an
+(unencrypted) module signed by Intel that is used as part of the
+DRTM process to verify and configure the system.  It is signed
+because it operates at a higher privilege level in the system than
+any other macrocode and its correct operation is critical to the
+establishment of the DRTM.  The process for determining the correct
+SINIT ACM for a system is documented in the SINIT-guide.txt file
+that is on the tboot SourceForge site under the SINIT ACM downloads.
--

-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Gmane