tboot-devel — Developer support

Re: [tboot-devel] VT-d PMRs

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

> From: Jonathan M. McCune [mailto:jon...@cm...]
> Sent: Friday, October 10, 2008 3:11 PM
> 
> Hi Joe, list,
> 
> I started digging through this.
> 
> In the VT-d spec, the very beginning of chapter 7 says that each DMA
> remapping hardware unit is placed at a system-specific 4K-aligned
> memory mapped address, and that the BIOS will report where these are.
> 
> I realized I don't know what these addresses are, and Ch. 5 told me to
> look at the DMAR table.
> 
> I wrote some code to decode the DMAR table, and the subsequent DRHD /
> RMRR entries it contains, and the subsequent Device Scope Structures
> that they contain.
> 
> When run on my system following execution of SENTER, the big long
> printout at the end of this email ensues.  I made an educated guess
> that the DRHD structure with flags = 1 (see Table 5-3 in the VT-d
spec)
> might be the DMA remapping hardware unit??? of choice.  I tried to
print its
> values at the relevant offsets for the PMRs (see Table 7-2), but I get
> all 0s:
> 
> TBOOT: ACPI VT-d DRHD structure @ 7c6a3e78:
> TBOOT:  Type: 0
> TBOOT:  Length: 0x10 (16)
> TBOOT:  Flags: 1
> TBOOT:  Register Base Address: 0xfed93000
> TBOOT:          DMAR DRHD Registers @ fed93000:
> TBOOT:                  PMR Enable: 0x0
> TBOOT:                  PMR Low Base: 0x0
> TBOOT:                  PMR Low Limit: 0x0
> TBOOT:                  PMR High Base: 0x0
> TBOOT:                  PMR High Limit: 0x0
> 
> 
> Am I on the right track here?  How do I know which of these "DMA
> remapping hardware units" is the right one?

These entries are not 4k aligned, so they aren't the right places.  The
easiest thing to do is to look at the Xen code that parses the tables
and reads the registers to see how to do it.

> 
> Thanks!
> -Jon
> 
> 
> 
> 
> 
> TBOOT: acpi_dmar = 7c6a3df0
> TBOOT: VT-d DMAR @ 7c6a3df0 (len 360 bytes):
> 44 4d 41 52 68 01 00 00 01 c7 31 30 31 36 30 37
> 4f 45 4d 44 4d 41 52 20 01 00 00 00 4d 53 46 54
> 97 00 00 00 23 00 00 00 00 00 00 00 00 00 00 00
> 00 00 18 00 00 00 00 00 00 00 d9 fe 00 00 00 00
> 01 08 00 00 00 00 1b 00 00 00 18 00 00 00 00 00
> 00 10 d9 fe 00 00 00 00 01 08 00 00 00 00 02 00
> 00 00 28 00 00 00 00 00 00 20 d9 fe 00 00 00 00
> 01 08 00 00 00 00 03 00 01 08 00 00 00 00 03 02
> 01 08 00 00 00 00 03 03 00 00 10 00 01 00 00 00
> 00 30 d9 fe 00 00 00 00 01 00 58 00 00 00 00 00
> 00 d0 0e 00 00 00 00 00 ff ff 0e 00 00 00 00 00
> 01 08 00 00 00 00 1d 00 01 08 00 00 00 00 1d 01
> 01 08 00 00 00 00 1d 02 01 08 00 00 00 00 1d 07
> 01 08 00 00 00 00 1a 00 01 08 00 00 00 00 1a 01
> 01 08 00 00 00 00 1a 02 01 08 00 00 00 00 1a 07
> 01 00 58 00 00 00 00 00 00 00 2f 7d 00 00 00 00
> ff ff 2f 7d 00 00 00 00 01 08 00 00 00 00 1d 00
> 01 08 00 00 00 00 1d 01 01 08 00 00 00 00 1d 02
> 01 08 00 00 00 00 1d 07 01 08 00 00 00 00 1a 00
> 01 08 00 00 00 00 1a 01 01 08 00 00 00 00 1a 02
> 01 08 00 00 00 00 1a 07 01 00 20 00 00 00 00 00
> 00 00 60 7d 00 00 00 00 ff ff ff 7d 00 00 00 00
> 01 08 00 00 00 00 02 00
> TBOOT: ACPI VT-d DMAR table @ 7c6a3df0 (len 48 bytes):
> TBOOT:  Signature: DMAR
> TBOOT:  Length: 0x168 (360)
> TBOOT:  Revision: 1
> TBOOT:  Checksum: c7
> TBOOT:  OEMID: 101607
> TBOOT:  OEM Table ID: OEMDMAR
> TBOOT:  OEM Revision: 1
> TBOOT:  Creator ID: MSFT
> TBOOT:  Creator Revision: 0x97
> TBOOT:  Host Address Width: 0x23 (35)
> TBOOT: ACPI VT-d DRHD structure @ 7c6a3e20:
> TBOOT:  Type: 0
> TBOOT:  Length: 0x18 (24)
> TBOOT:  Flags: 0
> TBOOT:  Register Base Address: 0xfed90000
> TBOOT:  Device Scope entry @ 7c6a3e30:
> TBOOT:          Type: 0x1
> TBOOT:          Length: 0x8
> TBOOT:          Segment Number: 0x0
> TBOOT:          Starting Bus Number: 0x0
> TBOOT:          Raw PCI Path (Length - 4): 00 00 1b 00
> 
> TBOOT: ACPI VT-d DRHD structure @ 7c6a3e38:
> TBOOT:  Type: 0
> TBOOT:  Length: 0x18 (24)
> TBOOT:  Flags: 0
> TBOOT:  Register Base Address: 0xfed91000
> TBOOT:  Device Scope entry @ 7c6a3e48:
> TBOOT:          Type: 0x1
> TBOOT:          Length: 0x8
> TBOOT:          Segment Number: 0x0
> TBOOT:          Starting Bus Number: 0x0
> TBOOT:          Raw PCI Path (Length - 4): 00 00 02 00
> 
> TBOOT: ACPI VT-d DRHD structure @ 7c6a3e50:
> TBOOT:  Type: 0
> TBOOT:  Length: 0x28 (40)
> TBOOT:  Flags: 0
> TBOOT:  Register Base Address: 0xfed92000
> TBOOT:  Device Scope entry @ 7c6a3e60:
> TBOOT:          Type: 0x1
> TBOOT:          Length: 0x8
> TBOOT:          Segment Number: 0x0
> TBOOT:          Starting Bus Number: 0x0
> TBOOT:          Raw PCI Path (Length - 4): 00 00 03 00
> 
> TBOOT:  Device Scope entry @ 7c6a3e68:
> TBOOT:          Type: 0x1
> TBOOT:          Length: 0x8
> TBOOT:          Segment Number: 0x0
> TBOOT:          Starting Bus Number: 0x0
> TBOOT:          Raw PCI Path (Length - 4): 00 00 03 02
> 
> TBOOT:  Device Scope entry @ 7c6a3e70:
> TBOOT:          Type: 0x1
> TBOOT:          Length: 0x8
> TBOOT:          Segment Number: 0x0
> TBOOT:          Starting Bus Number: 0x0
> TBOOT:          Raw PCI Path (Length - 4): 00 00 03 03
> 
> TBOOT: ACPI VT-d DRHD structure @ 7c6a3e78:
> TBOOT:  Type: 0
> TBOOT:  Length: 0x10 (16)
> TBOOT:  Flags: 1
> TBOOT:  Register Base Address: 0xfed93000
> TBOOT:          DMAR DRHD Registers @ fed93000:
> TBOOT:                  PMR Enable: 0x0
> TBOOT:                  PMR Low Base: 0x0
> TBOOT:                  PMR Low Limit: 0x0
> TBOOT:                  PMR High Base: 0x0
> TBOOT:                  PMR High Limit: 0x0
> TBOOT: ACPI VT-d RMRR structure @ 7c6a3e88:
> TBOOT:  Type: 0x1 (1)
> TBOOT:  Length: 0x58 (88)
> TBOOT:  Flag: 0x0
> TBOOT:  RMR Base Address:  ed000
> TBOOT:  RMR Limit Address: effff
> TBOOT:  Device Scope entry @ 7c6a3ea0:
> TBOOT:          Type: 0x1
> TBOOT:          Length: 0x8
> TBOOT:          Segment Number: 0x0
> TBOOT:          Starting Bus Number: 0x0
> TBOOT:          Raw PCI Path (Length - 4): 00 00 1d 00
> 
> TBOOT:  Device Scope entry @ 7c6a3ea8:
> TBOOT:          Type: 0x1
> TBOOT:          Length: 0x8
> TBOOT:          Segment Number: 0x0
> TBOOT:          Starting Bus Number: 0x0
> TBOOT:          Raw PCI Path (Length - 4): 00 00 1d 01
> 
> TBOOT:  Device Scope entry @ 7c6a3eb0:
> TBOOT:          Type: 0x1
> TBOOT:          Length: 0x8
> TBOOT:          Segment Number: 0x0
> TBOOT:          Starting Bus Number: 0x0
> TBOOT:          Raw PCI Path (Length - 4): 00 00 1d 02
> 
> TBOOT:  Device Scope entry @ 7c6a3eb8:
> TBOOT:          Type: 0x1
> TBOOT:          Length: 0x8
> TBOOT:          Segment Number: 0x0
> TBOOT:          Starting Bus Number: 0x0
> TBOOT:          Raw PCI Path (Length - 4): 00 00 1d 07
> 
> TBOOT:  Device Scope entry @ 7c6a3ec0:
> TBOOT:          Type: 0x1
> TBOOT:          Length: 0x8
> TBOOT:          Segment Number: 0x0
> TBOOT:          Starting Bus Number: 0x0
> TBOOT:          Raw PCI Path (Length - 4): 00 00 1a 00
> 
> TBOOT:  Device Scope entry @ 7c6a3ec8:
> TBOOT:          Type: 0x1
> TBOOT:          Length: 0x8
> TBOOT:          Segment Number: 0x0
> TBOOT:          Starting Bus Number: 0x0
> TBOOT:          Raw PCI Path (Length - 4): 00 00 1a 01
> 
> TBOOT:  Device Scope entry @ 7c6a3ed0:
> TBOOT:          Type: 0x1
> TBOOT:          Length: 0x8
> TBOOT:          Segment Number: 0x0
> TBOOT:          Starting Bus Number: 0x0
> TBOOT:          Raw PCI Path (Length - 4): 00 00 1a 02
> 
> TBOOT:  Device Scope entry @ 7c6a3ed8:
> TBOOT:          Type: 0x1
> TBOOT:          Length: 0x8
> TBOOT:          Segment Number: 0x0
> TBOOT:          Starting Bus Number: 0x0
> TBOOT:          Raw PCI Path (Length - 4): 00 00 1a 07
> 
> TBOOT: ACPI VT-d RMRR structure @ 7c6a3ee0:
> TBOOT:  Type: 0x1 (1)
> TBOOT:  Length: 0x58 (88)
> TBOOT:  Flag: 0x0
> TBOOT:  RMR Base Address:  7d2f0000
> TBOOT:  RMR Limit Address: 7d2fffff
> TBOOT:  Device Scope entry @ 7c6a3ef8:
> TBOOT:          Type: 0x1
> TBOOT:          Length: 0x8
> TBOOT:          Segment Number: 0x0
> TBOOT:          Starting Bus Number: 0x0
> TBOOT:          Raw PCI Path (Length - 4): 00 00 1d 00
> 
> TBOOT:  Device Scope entry @ 7c6a3f00:
> TBOOT:          Type: 0x1
> TBOOT:          Length: 0x8
> TBOOT:          Segment Number: 0x0
> TBOOT:          Starting Bus Number: 0x0
> TBOOT:          Raw PCI Path (Length - 4): 00 00 1d 01
> 
> TBOOT:  Device Scope entry @ 7c6a3f08:
> TBOOT:          Type: 0x1
> TBOOT:          Length: 0x8
> TBOOT:          Segment Number: 0x0
> TBOOT:          Starting Bus Number: 0x0
> TBOOT:          Raw PCI Path (Length - 4): 00 00 1d 02
> 
> TBOOT:  Device Scope entry @ 7c6a3f10:
> TBOOT:          Type: 0x1
> TBOOT:          Length: 0x8
> TBOOT:          Segment Number: 0x0
> TBOOT:          Starting Bus Number: 0x0
> TBOOT:          Raw PCI Path (Length - 4): 00 00 1d 07
> 
> TBOOT:  Device Scope entry @ 7c6a3f18:
> TBOOT:          Type: 0x1
> TBOOT:          Length: 0x8
> TBOOT:          Segment Number: 0x0
> TBOOT:          Starting Bus Number: 0x0
> TBOOT:          Raw PCI Path (Length - 4): 00 00 1a 00
> 
> TBOOT:  Device Scope entry @ 7c6a3f20:
> TBOOT:          Type: 0x1
> TBOOT:          Length: 0x8
> TBOOT:          Segment Number: 0x0
> TBOOT:          Starting Bus Number: 0x0
> TBOOT:          Raw PCI Path (Length - 4): 00 00 1a 01
> 
> TBOOT:  Device Scope entry @ 7c6a3f28:
> TBOOT:          Type: 0x1
> TBOOT:          Length: 0x8
> TBOOT:          Segment Number: 0x0
> TBOOT:          Starting Bus Number: 0x0
> TBOOT:          Raw PCI Path (Length - 4): 00 00 1a 02
> 
> TBOOT:  Device Scope entry @ 7c6a3f30:
> TBOOT:          Type: 0x1
> TBOOT:          Length: 0x8
> TBOOT:          Segment Number: 0x0
> TBOOT:          Starting Bus Number: 0x0
> TBOOT:          Raw PCI Path (Length - 4): 00 00 1a 07
> 
> TBOOT: ACPI VT-d RMRR structure @ 7c6a3f38:
> TBOOT:  Type: 0x1 (1)
> TBOOT:  Length: 0x20 (32)
> TBOOT:  Flag: 0x0
> TBOOT:  RMR Base Address:  7d600000
> TBOOT:  RMR Limit Address: 7dffffff
> TBOOT:  Device Scope entry @ 7c6a3f50:
> TBOOT:          Type: 0x1
> TBOOT:          Length: 0x8
> TBOOT:          Segment Number: 0x0
> TBOOT:          Starting Bus Number: 0x0
> TBOOT:          Raw PCI Path (Length - 4): 00 00 02 00
> 
> TBOOT: VT-d DMAR table OK
> 
> 
> Cihula, Joseph wrote:
> >> From: Jonathan M. McCune [mailto:jon...@cm...]
> >> Sent: Thursday, October 09, 2008 10:27 AM
> >>
> >> Hi Joe,
> >>
> >> Cihula, Joseph wrote:
> >>> It is really:
> >>> 	Current values of VT-d PMR registers do not match requested
> >>> values in SinitMleData
> >>>
> >>> which means that some code has already programmed the PMRs but not
> > to
> >>> the same values that the MLE is requesting.  Because the PMRs
> cannot
> >> be
> >>> changed reliably once they are set/enabled, this is not an allowed
> >>> condition.
> >>
> >> I am successfully invoking SENTER / SEXIT and then returning
control
> > to
> >> the legacy OS once per boot cycle.  When I try to execute SENTER a
> >> second time, the system reboots and LT.ERRORCODE is populated with
> the
> >> above error.  However, I cannot figure out what is wrong with my
PMR
> >> values.
> >>
> >> Is there a way to read the current values, so that I can see how
> they
> >> are set following the first SENTER? Looking through the MLE manual
> and
> >> the Sw Dev Manual Vol 2b has left me without much insight.
> >
> > VT-d registers are described in the VT-d spec at:
> >
>
http://download.intel.com/technology/computing/vptech/Intel(r)_VT_for_D
> i
> > rect_IO.pdf
> >
> >> My MLE resides at physical address 0x00c00000 and consumes less
than
> >> 0x200000 (2MB) bytes.
> >>
> >> TBOOT:   vtd_pmr_lo_base: 0xc00000
> >> TBOOT:   vtd_pmr_lo_size: 0x200000
> >> TBOOT:   vtd_pmr_hi_base: 0x0
> >> TBOOT:   vtd_pmr_hi_size: 0x0
> >>
> >> I'm fairly confident that the os_sinit_data_t.vtd_pmr_* values are
> >> being
> >> set identically prior to both invocations of SENTER (when I print
> them
> >> out, the above is what I see).
> >
> > If you could use the VT-d spec to read and output the PMRs before
> > launch, that should determine if they are somehow getting changed
> > between invocations.
> >
> >> Thanks,
> >> -Jon
> >

Re: [tboot-devel] VT-d PMRs

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

Hi Joe, list,

I started digging through this.

In the VT-d spec, the very beginning of chapter 7 says that each DMA
remapping hardware unit is placed at a system-specific 4K-aligned memory
mapped address, and that the BIOS will report where these are.

I realized I don't know what these addresses are, and Ch. 5 told me to
look at the DMAR table.

I wrote some code to decode the DMAR table, and the subsequent DRHD /
RMRR entries it contains, and the subsequent Device Scope Structures
that they contain.

When run on my system following execution of SENTER, the big long
printout at the end of this email ensues.  I made an educated guess that
the DRHD structure with flags = 1 (see Table 5-3 in the VT-d spec) might
be the DMA remapping hardware unit??? of choice.  I tried to print its
values at the relevant offsets for the PMRs (see Table 7-2), but I get
all 0s:

TBOOT: ACPI VT-d DRHD structure @ 7c6a3e78:
TBOOT:  Type: 0
TBOOT:  Length: 0x10 (16)
TBOOT:  Flags: 1
TBOOT:  Register Base Address: 0xfed93000
TBOOT:          DMAR DRHD Registers @ fed93000:
TBOOT:                  PMR Enable: 0x0
TBOOT:                  PMR Low Base: 0x0
TBOOT:                  PMR Low Limit: 0x0
TBOOT:                  PMR High Base: 0x0
TBOOT:                  PMR High Limit: 0x0


Am I on the right track here?  How do I know which of these "DMA
remapping hardware units" is the right one?

Thanks!
-Jon





TBOOT: acpi_dmar = 7c6a3df0
TBOOT: VT-d DMAR @ 7c6a3df0 (len 360 bytes):
44 4d 41 52 68 01 00 00 01 c7 31 30 31 36 30 37
4f 45 4d 44 4d 41 52 20 01 00 00 00 4d 53 46 54
97 00 00 00 23 00 00 00 00 00 00 00 00 00 00 00
00 00 18 00 00 00 00 00 00 00 d9 fe 00 00 00 00
01 08 00 00 00 00 1b 00 00 00 18 00 00 00 00 00
00 10 d9 fe 00 00 00 00 01 08 00 00 00 00 02 00
00 00 28 00 00 00 00 00 00 20 d9 fe 00 00 00 00
01 08 00 00 00 00 03 00 01 08 00 00 00 00 03 02
01 08 00 00 00 00 03 03 00 00 10 00 01 00 00 00
00 30 d9 fe 00 00 00 00 01 00 58 00 00 00 00 00
00 d0 0e 00 00 00 00 00 ff ff 0e 00 00 00 00 00
01 08 00 00 00 00 1d 00 01 08 00 00 00 00 1d 01
01 08 00 00 00 00 1d 02 01 08 00 00 00 00 1d 07
01 08 00 00 00 00 1a 00 01 08 00 00 00 00 1a 01
01 08 00 00 00 00 1a 02 01 08 00 00 00 00 1a 07
01 00 58 00 00 00 00 00 00 00 2f 7d 00 00 00 00
ff ff 2f 7d 00 00 00 00 01 08 00 00 00 00 1d 00
01 08 00 00 00 00 1d 01 01 08 00 00 00 00 1d 02
01 08 00 00 00 00 1d 07 01 08 00 00 00 00 1a 00
01 08 00 00 00 00 1a 01 01 08 00 00 00 00 1a 02
01 08 00 00 00 00 1a 07 01 00 20 00 00 00 00 00
00 00 60 7d 00 00 00 00 ff ff ff 7d 00 00 00 00
01 08 00 00 00 00 02 00
TBOOT: ACPI VT-d DMAR table @ 7c6a3df0 (len 48 bytes):
TBOOT:  Signature: DMAR
TBOOT:  Length: 0x168 (360)
TBOOT:  Revision: 1
TBOOT:  Checksum: c7
TBOOT:  OEMID: 101607
TBOOT:  OEM Table ID: OEMDMAR
TBOOT:  OEM Revision: 1
TBOOT:  Creator ID: MSFT
TBOOT:  Creator Revision: 0x97
TBOOT:  Host Address Width: 0x23 (35)
TBOOT: ACPI VT-d DRHD structure @ 7c6a3e20:
TBOOT:  Type: 0
TBOOT:  Length: 0x18 (24)
TBOOT:  Flags: 0
TBOOT:  Register Base Address: 0xfed90000
TBOOT:  Device Scope entry @ 7c6a3e30:
TBOOT:          Type: 0x1
TBOOT:          Length: 0x8
TBOOT:          Segment Number: 0x0
TBOOT:          Starting Bus Number: 0x0
TBOOT:          Raw PCI Path (Length - 4): 00 00 1b 00

TBOOT: ACPI VT-d DRHD structure @ 7c6a3e38:
TBOOT:  Type: 0
TBOOT:  Length: 0x18 (24)
TBOOT:  Flags: 0
TBOOT:  Register Base Address: 0xfed91000
TBOOT:  Device Scope entry @ 7c6a3e48:
TBOOT:          Type: 0x1
TBOOT:          Length: 0x8
TBOOT:          Segment Number: 0x0
TBOOT:          Starting Bus Number: 0x0
TBOOT:          Raw PCI Path (Length - 4): 00 00 02 00

TBOOT: ACPI VT-d DRHD structure @ 7c6a3e50:
TBOOT:  Type: 0
TBOOT:  Length: 0x28 (40)
TBOOT:  Flags: 0
TBOOT:  Register Base Address: 0xfed92000
TBOOT:  Device Scope entry @ 7c6a3e60:
TBOOT:          Type: 0x1
TBOOT:          Length: 0x8
TBOOT:          Segment Number: 0x0
TBOOT:          Starting Bus Number: 0x0
TBOOT:          Raw PCI Path (Length - 4): 00 00 03 00

TBOOT:  Device Scope entry @ 7c6a3e68:
TBOOT:          Type: 0x1
TBOOT:          Length: 0x8
TBOOT:          Segment Number: 0x0
TBOOT:          Starting Bus Number: 0x0
TBOOT:          Raw PCI Path (Length - 4): 00 00 03 02

TBOOT:  Device Scope entry @ 7c6a3e70:
TBOOT:          Type: 0x1
TBOOT:          Length: 0x8
TBOOT:          Segment Number: 0x0
TBOOT:          Starting Bus Number: 0x0
TBOOT:          Raw PCI Path (Length - 4): 00 00 03 03

TBOOT: ACPI VT-d DRHD structure @ 7c6a3e78:
TBOOT:  Type: 0
TBOOT:  Length: 0x10 (16)
TBOOT:  Flags: 1
TBOOT:  Register Base Address: 0xfed93000
TBOOT:          DMAR DRHD Registers @ fed93000:
TBOOT:                  PMR Enable: 0x0
TBOOT:                  PMR Low Base: 0x0
TBOOT:                  PMR Low Limit: 0x0
TBOOT:                  PMR High Base: 0x0
TBOOT:                  PMR High Limit: 0x0
TBOOT: ACPI VT-d RMRR structure @ 7c6a3e88:
TBOOT:  Type: 0x1 (1)
TBOOT:  Length: 0x58 (88)
TBOOT:  Flag: 0x0
TBOOT:  RMR Base Address:  ed000
TBOOT:  RMR Limit Address: effff
TBOOT:  Device Scope entry @ 7c6a3ea0:
TBOOT:          Type: 0x1
TBOOT:          Length: 0x8
TBOOT:          Segment Number: 0x0
TBOOT:          Starting Bus Number: 0x0
TBOOT:          Raw PCI Path (Length - 4): 00 00 1d 00

TBOOT:  Device Scope entry @ 7c6a3ea8:
TBOOT:          Type: 0x1
TBOOT:          Length: 0x8
TBOOT:          Segment Number: 0x0
TBOOT:          Starting Bus Number: 0x0
TBOOT:          Raw PCI Path (Length - 4): 00 00 1d 01

TBOOT:  Device Scope entry @ 7c6a3eb0:
TBOOT:          Type: 0x1
TBOOT:          Length: 0x8
TBOOT:          Segment Number: 0x0
TBOOT:          Starting Bus Number: 0x0
TBOOT:          Raw PCI Path (Length - 4): 00 00 1d 02

TBOOT:  Device Scope entry @ 7c6a3eb8:
TBOOT:          Type: 0x1
TBOOT:          Length: 0x8
TBOOT:          Segment Number: 0x0
TBOOT:          Starting Bus Number: 0x0
TBOOT:          Raw PCI Path (Length - 4): 00 00 1d 07

TBOOT:  Device Scope entry @ 7c6a3ec0:
TBOOT:          Type: 0x1
TBOOT:          Length: 0x8
TBOOT:          Segment Number: 0x0
TBOOT:          Starting Bus Number: 0x0
TBOOT:          Raw PCI Path (Length - 4): 00 00 1a 00

TBOOT:  Device Scope entry @ 7c6a3ec8:
TBOOT:          Type: 0x1
TBOOT:          Length: 0x8
TBOOT:          Segment Number: 0x0
TBOOT:          Starting Bus Number: 0x0
TBOOT:          Raw PCI Path (Length - 4): 00 00 1a 01

TBOOT:  Device Scope entry @ 7c6a3ed0:
TBOOT:          Type: 0x1
TBOOT:          Length: 0x8
TBOOT:          Segment Number: 0x0
TBOOT:          Starting Bus Number: 0x0
TBOOT:          Raw PCI Path (Length - 4): 00 00 1a 02

TBOOT:  Device Scope entry @ 7c6a3ed8:
TBOOT:          Type: 0x1
TBOOT:          Length: 0x8
TBOOT:          Segment Number: 0x0
TBOOT:          Starting Bus Number: 0x0
TBOOT:          Raw PCI Path (Length - 4): 00 00 1a 07

TBOOT: ACPI VT-d RMRR structure @ 7c6a3ee0:
TBOOT:  Type: 0x1 (1)
TBOOT:  Length: 0x58 (88)
TBOOT:  Flag: 0x0
TBOOT:  RMR Base Address:  7d2f0000
TBOOT:  RMR Limit Address: 7d2fffff
TBOOT:  Device Scope entry @ 7c6a3ef8:
TBOOT:          Type: 0x1
TBOOT:          Length: 0x8
TBOOT:          Segment Number: 0x0
TBOOT:          Starting Bus Number: 0x0
TBOOT:          Raw PCI Path (Length - 4): 00 00 1d 00

TBOOT:  Device Scope entry @ 7c6a3f00:
TBOOT:          Type: 0x1
TBOOT:          Length: 0x8
TBOOT:          Segment Number: 0x0
TBOOT:          Starting Bus Number: 0x0
TBOOT:          Raw PCI Path (Length - 4): 00 00 1d 01

TBOOT:  Device Scope entry @ 7c6a3f08:
TBOOT:          Type: 0x1
TBOOT:          Length: 0x8
TBOOT:          Segment Number: 0x0
TBOOT:          Starting Bus Number: 0x0
TBOOT:          Raw PCI Path (Length - 4): 00 00 1d 02

TBOOT:  Device Scope entry @ 7c6a3f10:
TBOOT:          Type: 0x1
TBOOT:          Length: 0x8
TBOOT:          Segment Number: 0x0
TBOOT:          Starting Bus Number: 0x0
TBOOT:          Raw PCI Path (Length - 4): 00 00 1d 07

TBOOT:  Device Scope entry @ 7c6a3f18:
TBOOT:          Type: 0x1
TBOOT:          Length: 0x8
TBOOT:          Segment Number: 0x0
TBOOT:          Starting Bus Number: 0x0
TBOOT:          Raw PCI Path (Length - 4): 00 00 1a 00

TBOOT:  Device Scope entry @ 7c6a3f20:
TBOOT:          Type: 0x1
TBOOT:          Length: 0x8
TBOOT:          Segment Number: 0x0
TBOOT:          Starting Bus Number: 0x0
TBOOT:          Raw PCI Path (Length - 4): 00 00 1a 01

TBOOT:  Device Scope entry @ 7c6a3f28:
TBOOT:          Type: 0x1
TBOOT:          Length: 0x8
TBOOT:          Segment Number: 0x0
TBOOT:          Starting Bus Number: 0x0
TBOOT:          Raw PCI Path (Length - 4): 00 00 1a 02

TBOOT:  Device Scope entry @ 7c6a3f30:
TBOOT:          Type: 0x1
TBOOT:          Length: 0x8
TBOOT:          Segment Number: 0x0
TBOOT:          Starting Bus Number: 0x0
TBOOT:          Raw PCI Path (Length - 4): 00 00 1a 07

TBOOT: ACPI VT-d RMRR structure @ 7c6a3f38:
TBOOT:  Type: 0x1 (1)
TBOOT:  Length: 0x20 (32)
TBOOT:  Flag: 0x0
TBOOT:  RMR Base Address:  7d600000
TBOOT:  RMR Limit Address: 7dffffff
TBOOT:  Device Scope entry @ 7c6a3f50:
TBOOT:          Type: 0x1
TBOOT:          Length: 0x8
TBOOT:          Segment Number: 0x0
TBOOT:          Starting Bus Number: 0x0
TBOOT:          Raw PCI Path (Length - 4): 00 00 02 00

TBOOT: VT-d DMAR table OK


Cihula, Joseph wrote:
>> From: Jonathan M. McCune [mailto:jon...@cm...]
>> Sent: Thursday, October 09, 2008 10:27 AM
>>
>> Hi Joe,
>>
>> Cihula, Joseph wrote:
>>> It is really:
>>> 	Current values of VT-d PMR registers do not match requested
>>> values in SinitMleData
>>>
>>> which means that some code has already programmed the PMRs but not
> to
>>> the same values that the MLE is requesting.  Because the PMRs cannot
>> be
>>> changed reliably once they are set/enabled, this is not an allowed
>>> condition.
>>
>> I am successfully invoking SENTER / SEXIT and then returning control
> to
>> the legacy OS once per boot cycle.  When I try to execute SENTER a
>> second time, the system reboots and LT.ERRORCODE is populated with the
>> above error.  However, I cannot figure out what is wrong with my PMR
>> values.
>>
>> Is there a way to read the current values, so that I can see how they
>> are set following the first SENTER? Looking through the MLE manual and
>> the Sw Dev Manual Vol 2b has left me without much insight.
> 
> VT-d registers are described in the VT-d spec at:
> http://download.intel.com/technology/computing/vptech/Intel(r)_VT_for_Di
> rect_IO.pdf
> 
>> My MLE resides at physical address 0x00c00000 and consumes less than
>> 0x200000 (2MB) bytes.
>>
>> TBOOT:   vtd_pmr_lo_base: 0xc00000
>> TBOOT:   vtd_pmr_lo_size: 0x200000
>> TBOOT:   vtd_pmr_hi_base: 0x0
>> TBOOT:   vtd_pmr_hi_size: 0x0
>>
>> I'm fairly confident that the os_sinit_data_t.vtd_pmr_* values are
>> being
>> set identically prior to both invocations of SENTER (when I print them
>> out, the above is what I see).
> 
> If you could use the VT-d spec to read and output the PMRs before
> launch, that should determine if they are somehow getting changed
> between invocations.
> 
>> Thanks,
>> -Jon
> 

Re: [tboot-devel] Buying a machine that will actually work with TXT

[Karthik . <tr...@gm...>]

HP Desktop Bios team is working on this issue and may release it in couple
of weeks. Thanks

Karthik


*Re: [tboot-devel] Buying a machine that will actually work with TXT*
From: Jonathan M. McCune <jonmccune@cm...> - 2008-10-09 17:18
  fyi...

It seems that the HP Compaq dc7800 does _not_ include a reset button either.

-Jon


Jonathan M. McCune wrote:
> Hal Finney wrote:
>> When Trusted Execution was announced, 3 models of computers were
>> identified as supporting it: The HP Compaq dc7800, Dell OptiPlex 755
>> PC, and the Lenovo ThinkCentre M57p. I don't know of any others that
>> have been added to that list since then.
>>
>
> Does anybody know whether the HP or Lenovo systems include a reset
> button? At least the Ultra Slim Form Factor Optiplex 755s have no reset
> button, meaning that debugging a system hang requires a power cycle that
> clears LT.ERRORCODE, making debugging substantially more difficult.
>
>
> Alternatively, does anybody know another way to trigger a reset on one
> of these systems? I'm told that there is a CMOS reset byte, and that it
> may be possible to write a value to it that causes the "soft" power
> button on the Optiplex to cause a reset instead of a power off. I have
> not investigated this yet, as I'd rather just get a different machine.
>
>
> Thanks,
> -Jon
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's
challenge
> Build the coolest Linux based applications with Moblin SDK & win great
prizes
> Grand prize is a trip for two to an Open Source event anywhere in the
world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> tboot-devel mailing list
> tboot-devel@li...
> https://lists.sourceforge.net/lists/listinfo/tboot-devel
>

Re: [tboot-devel] VT-d PMRs

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

> From: Jonathan M. McCune [mailto:jon...@cm...]
> Sent: Thursday, October 09, 2008 10:27 AM
> 
> Hi Joe,
> 
> Cihula, Joseph wrote:
> > It is really:
> > 	Current values of VT-d PMR registers do not match requested
> > values in SinitMleData
> >
> > which means that some code has already programmed the PMRs but not
to
> > the same values that the MLE is requesting.  Because the PMRs cannot
> be
> > changed reliably once they are set/enabled, this is not an allowed
> > condition.
> 
> 
> I am successfully invoking SENTER / SEXIT and then returning control
to
> the legacy OS once per boot cycle.  When I try to execute SENTER a
> second time, the system reboots and LT.ERRORCODE is populated with the
> above error.  However, I cannot figure out what is wrong with my PMR
> values.
> 
> Is there a way to read the current values, so that I can see how they
> are set following the first SENTER? Looking through the MLE manual and
> the Sw Dev Manual Vol 2b has left me without much insight.

VT-d registers are described in the VT-d spec at:
http://download.intel.com/technology/computing/vptech/Intel(r)_VT_for_Di
rect_IO.pdf

> My MLE resides at physical address 0x00c00000 and consumes less than
> 0x200000 (2MB) bytes.
> 
> TBOOT:   vtd_pmr_lo_base: 0xc00000
> TBOOT:   vtd_pmr_lo_size: 0x200000
> TBOOT:   vtd_pmr_hi_base: 0x0
> TBOOT:   vtd_pmr_hi_size: 0x0
> 
> I'm fairly confident that the os_sinit_data_t.vtd_pmr_* values are
> being
> set identically prior to both invocations of SENTER (when I print them
> out, the above is what I see).

If you could use the VT-d spec to read and output the PMRs before
launch, that should determine if they are somehow getting changed
between invocations.

> 
> Thanks,
> -Jon

Re: [tboot-devel] Buying a machine that will actually work with TXT

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

fyi...

It seems that the HP Compaq dc7800 does _not_ include a reset button either.

-Jon


Jonathan M. McCune wrote:
> Hal Finney wrote:
>> When Trusted Execution was announced, 3 models of computers were
>> identified as supporting it: The HP Compaq dc7800, Dell OptiPlex 755
>> PC, and the Lenovo ThinkCentre M57p. I don't know of any others that
>> have been added to that list since then.
>>   
> 
> Does anybody know whether the HP or Lenovo systems include a reset 
> button?  At least the Ultra Slim Form Factor Optiplex 755s have no reset 
> button, meaning that debugging a system hang requires a power cycle that 
> clears LT.ERRORCODE, making debugging substantially more difficult.
> 
> 
> Alternatively, does anybody know another way to trigger a reset on one 
> of these systems? I'm told that there is a CMOS reset byte, and that it 
> may be possible to write a value to it that causes the "soft" power 
> button on the Optiplex to cause a reset instead of a power off. I have 
> not investigated this yet, as I'd rather just get a different machine.
> 
> 
> Thanks,
> -Jon
> 
> 
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> tboot-devel mailing list
> tbo...@li...
> https://lists.sourceforge.net/lists/listinfo/tboot-devel
> 

Re: [tboot-devel] new location for mercurial repo

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

> From: Lil Evil [mailto:Lil...@gm...]
> Sent: Thursday, October 09, 2008 3:21 AM
> 
> Hi,
> 
> okay verification works now fine. Must have skipped that part in the
> README :).
> 
> I said broadcasted, because I assumed that it hasn't indeed been
> broadcasted.
> Meaning it didn't show up on the serial console.
> As I said it showed up during powering off, but not during rebooting.

Can you send me the serial output?  And what system is this?

> However, if I issue a reboot, the machine will hang with no screen at
> all.
> Only a hard reset brings it back to life.
> Hence, I assumed that TXT is protecting the machine, because it hasn't
> successfully issued SEXIT.
> But, it also could be an issue of my machine's BIOS, as I already
> encountered some.

This sounds like SEXIT is not finishing.  Typical reasons for that are if not all of the CPUs got woken up or if some still had VMX on.

> 
> I keep on playing around and let you know what's happening.
> 
> Cheers
> lIl
> 
> 
> -------- Original-Nachricht --------
> > Datum: Wed, 8 Oct 2008 11:26:51 -0700
> > Von: "Cihula, Joseph" <jos...@in...>
> > An: "Lil Evil" <Lil...@gm...>, tbo...@li...
> > Betreff: RE: [tboot-devel] new location for mercurial repo
> 
> > > From: Lil Evil [mailto:Lil...@gm...]
> > > Sent: Wednesday, October 08, 2008 2:11 AM
> > >
> > > 1) Compilation
> > > to reproduce the compilation error, I did the following:
> > >
> > > [root@lil staging]  hg clone
> http://www.bughost.org/repos.hg/tboot.hg
> > > destination directory: tboot.hg
> > > requesting all changes
> > > adding changesets
> > > adding manifests
> > > adding file changes
> > > added 91 changesets with 393 changes to 122 files
> > > updating working directory
> > > 118 files updated, 0 files merged, 0 files removed, 0 files
> unresolved
> > > [root@lil staging]  cd tboot.hg
> > > [root@lil tboot.hg] make
> > > ...
> > > <compile>
> > > ...
> > >
> > > mlehash.c:47:34: error: ../include/elf_defns.h: No such file or
> > > directory
> > >
> > >
> > > [root@lil tboot.hg]# ls -la include/elf_defns.h
> > > ls: cannot access include/elf_defns.h: No such file or directory
> > > [root@lil tboot.hg]#
> > >
> > > hg reports the following changeset:
> > >
> > > changeset:   90:5d19b96f7c0e
> > > tag:         tip
> > > user:        Joseph Cihula <jos...@in...>
> > > date:        Tue Oct 07 12:03:27 2008 -0700
> > > summary:     Added hg repo location to README
> > >
> > > I tried two different machines on different networks, same error.
> > > which changeset are you on?
> >
> > OK, my bad (I only re-built tboot and not the tools).  I have fixed
> this
> > in the tip and uploaded a new tarfile.
> >
> > > 2) I already adopted to the new policy format already, as I have
> been
> > > playing around with the mercurial repository a while ago.
> > > The debug line I added, just prints out the PCR before extending. I
> was
> > > a little bit surprised to see a none 0 row there.
> > > Something is fishy, either with me, or the build :)
> > >
> > > here is my policy gen script, btw:
> > >
> > > modprobe tpm_tis
> > > tcsd
> > > rm -rf mle_hash lcp.pol vl.pol
> > >
> > >
> > > #create hash of tboot
> > > lcp_mlehash /boot/tboot.gz > mle_hash
> > >
> > > # transform hash into policy
> > > lcp_crtpol -t hashonly -m mle_hash -o lcp.pol
> > >
> > > XENLINE="/xen.gz tboot=0x01019040 iommu=1 vtd=1 dom0_mem=1024mb
> > > com1=1115200,8n1 console=vga,com1"
> > > KERNEL="/vmlinuz-2.6.18.8-xen_unstable ro
> root=/dev/VolGroup01/LogVol01
> > > rhgb pciback.hide=(00:1d.7)(00:1d.1)"
> > > TPM_PW=""
> >
> > The new policy code strips the module name from the module string
> provided
> > by GRUB so that location isn't part of the measurement (which it
> shouldn't
> > be).  Thus, you should not have '/xen.gz ' or
> > '/vmlinuz-2.6.18.8-xen_unstable ' in your strings.
> >
> > > #create launch policy of the VMM
> > > tb_polgen --create --type nonfatal vl.pol
> > >
> > > tb_polgen --add --num 0 --pcr 18 --hash image --cmdline "$XENLINE"
> --
> > > image /boot/xen.gz vl.pol --verbose >> verbose.txt
> > > tb_polgen --add --num 1 --pcr 19 --hash image --cmdline "$KERNEL" -
> -
> > > image /boot/vmlinuz-2.6.18.8-xen_unstable vl.pol --verbose >>
> > > verbose.txt
> > > tb_polgen --add --num 2 --pcr 19 --hash image --cmdline "" --image
> > > /boot/initrd-2.6.18.8-xen_unstable.img vl.pol --verbose >>
> verbose.txt
> > >
> > > #write policy
> > > lcp_writepol -i owner -f lcp.pol -p
> > > lcp_writepol -i 0x20000001 -f vl.pol  -p
> > >
> > >
> > > 3) I also noticed with the stable tboot, on a reboot the
> GETSEC[SEXIT]
> > > command is not broadcasted.
> > >    It is however on a shutdown.
> >
> > When you say "broadcasted" do you mean it doesn't appear on the
> serial
> > output?  That is likely just due to buffering and when/how the
> platform
> > actually disables the serial port.  If SEXIT were not done, the
> system could not
> > reboot successfully (it would TXT_RESET and then the subsequent boot
> could
> > not launch TXT until a power cycle).
> >
> > > Just to let you know where I am standing at the moment.
> >
> > Thanks for your comments and we'll try to keep things fixed up
> better.
> >
> > > Cheers
> > > lIl
> > >
> > > --
> > > Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
> > > Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer
> 
> --
> Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
> Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer
> 
> -----------------------------------------------------------------------
> --
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the
> world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> tboot-devel mailing list
> tbo...@li...
> https://lists.sourceforge.net/lists/listinfo/tboot-devel

Re: [tboot-devel] new location for mercurial repo

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

Hi,

okay verification works now fine. Must have skipped that part in the README :).

I said broadcasted, because I assumed that it hasn't indeed been broadcasted.
Meaning it didn't show up on the serial console.
As I said it showed up during powering off, but not during rebooting.

However, if I issue a reboot, the machine will hang with no screen at all.
Only a hard reset brings it back to life.
Hence, I assumed that TXT is protecting the machine, because it hasn't successfully issued SEXIT.
But, it also could be an issue of my machine's BIOS, as I already encountered some.

I keep on playing around and let you know what's happening. 

Cheers
lIl


-------- Original-Nachricht --------
> Datum: Wed, 8 Oct 2008 11:26:51 -0700
> Von: "Cihula, Joseph" <jos...@in...>
> An: "Lil Evil" <Lil...@gm...>, tbo...@li...
> Betreff: RE: [tboot-devel] new location for mercurial repo

> > From: Lil Evil [mailto:Lil...@gm...]
> > Sent: Wednesday, October 08, 2008 2:11 AM
> > 
> > 1) Compilation
> > to reproduce the compilation error, I did the following:
> > 
> > [root@lil staging]  hg clone http://www.bughost.org/repos.hg/tboot.hg
> > destination directory: tboot.hg
> > requesting all changes
> > adding changesets
> > adding manifests
> > adding file changes
> > added 91 changesets with 393 changes to 122 files
> > updating working directory
> > 118 files updated, 0 files merged, 0 files removed, 0 files unresolved
> > [root@lil staging]  cd tboot.hg
> > [root@lil tboot.hg] make
> > ...
> > <compile>
> > ...
> > 
> > mlehash.c:47:34: error: ../include/elf_defns.h: No such file or
> > directory
> > 
> > 
> > [root@lil tboot.hg]# ls -la include/elf_defns.h
> > ls: cannot access include/elf_defns.h: No such file or directory
> > [root@lil tboot.hg]#
> > 
> > hg reports the following changeset:
> > 
> > changeset:   90:5d19b96f7c0e
> > tag:         tip
> > user:        Joseph Cihula <jos...@in...>
> > date:        Tue Oct 07 12:03:27 2008 -0700
> > summary:     Added hg repo location to README
> > 
> > I tried two different machines on different networks, same error.
> > which changeset are you on?
> 
> OK, my bad (I only re-built tboot and not the tools).  I have fixed this
> in the tip and uploaded a new tarfile.
> 
> > 2) I already adopted to the new policy format already, as I have been
> > playing around with the mercurial repository a while ago.
> > The debug line I added, just prints out the PCR before extending. I was
> > a little bit surprised to see a none 0 row there.
> > Something is fishy, either with me, or the build :)
> > 
> > here is my policy gen script, btw:
> > 
> > modprobe tpm_tis
> > tcsd
> > rm -rf mle_hash lcp.pol vl.pol
> > 
> > 
> > #create hash of tboot
> > lcp_mlehash /boot/tboot.gz > mle_hash
> > 
> > # transform hash into policy
> > lcp_crtpol -t hashonly -m mle_hash -o lcp.pol
> > 
> > XENLINE="/xen.gz tboot=0x01019040 iommu=1 vtd=1 dom0_mem=1024mb
> > com1=1115200,8n1 console=vga,com1"
> > KERNEL="/vmlinuz-2.6.18.8-xen_unstable ro root=/dev/VolGroup01/LogVol01
> > rhgb pciback.hide=(00:1d.7)(00:1d.1)"
> > TPM_PW=""
> 
> The new policy code strips the module name from the module string provided
> by GRUB so that location isn't part of the measurement (which it shouldn't
> be).  Thus, you should not have '/xen.gz ' or
> '/vmlinuz-2.6.18.8-xen_unstable ' in your strings.
> 
> > #create launch policy of the VMM
> > tb_polgen --create --type nonfatal vl.pol
> > 
> > tb_polgen --add --num 0 --pcr 18 --hash image --cmdline "$XENLINE" --
> > image /boot/xen.gz vl.pol --verbose >> verbose.txt
> > tb_polgen --add --num 1 --pcr 19 --hash image --cmdline "$KERNEL" --
> > image /boot/vmlinuz-2.6.18.8-xen_unstable vl.pol --verbose >>
> > verbose.txt
> > tb_polgen --add --num 2 --pcr 19 --hash image --cmdline "" --image
> > /boot/initrd-2.6.18.8-xen_unstable.img vl.pol --verbose >> verbose.txt
> > 
> > #write policy
> > lcp_writepol -i owner -f lcp.pol -p
> > lcp_writepol -i 0x20000001 -f vl.pol  -p
> > 
> > 
> > 3) I also noticed with the stable tboot, on a reboot the GETSEC[SEXIT]
> > command is not broadcasted.
> >    It is however on a shutdown.
> 
> When you say "broadcasted" do you mean it doesn't appear on the serial
> output?  That is likely just due to buffering and when/how the platform
> actually disables the serial port.  If SEXIT were not done, the system could not
> reboot successfully (it would TXT_RESET and then the subsequent boot could
> not launch TXT until a power cycle).
> 
> > Just to let you know where I am standing at the moment.
> 
> Thanks for your comments and we'll try to keep things fixed up better.
> 
> > Cheers
> > lIl
> > 
> > --
> > Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
> > Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer

-- 
Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! 
Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer

Re: [tboot-devel] new location for mercurial repo

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

> From: Lil Evil [mailto:Lil...@gm...]
> Sent: Wednesday, October 08, 2008 2:11 AM
> 
> 1) Compilation
> to reproduce the compilation error, I did the following:
> 
> [root@lil staging]  hg clone http://www.bughost.org/repos.hg/tboot.hg
> destination directory: tboot.hg
> requesting all changes
> adding changesets
> adding manifests
> adding file changes
> added 91 changesets with 393 changes to 122 files
> updating working directory
> 118 files updated, 0 files merged, 0 files removed, 0 files unresolved
> [root@lil staging]  cd tboot.hg
> [root@lil tboot.hg] make
> ...
> <compile>
> ...
> 
> mlehash.c:47:34: error: ../include/elf_defns.h: No such file or
> directory
> 
> 
> [root@lil tboot.hg]# ls -la include/elf_defns.h
> ls: cannot access include/elf_defns.h: No such file or directory
> [root@lil tboot.hg]#
> 
> hg reports the following changeset:
> 
> changeset:   90:5d19b96f7c0e
> tag:         tip
> user:        Joseph Cihula <jos...@in...>
> date:        Tue Oct 07 12:03:27 2008 -0700
> summary:     Added hg repo location to README
> 
> I tried two different machines on different networks, same error.
> which changeset are you on?

OK, my bad (I only re-built tboot and not the tools).  I have fixed this in the tip and uploaded a new tarfile.

> 2) I already adopted to the new policy format already, as I have been
> playing around with the mercurial repository a while ago.
> The debug line I added, just prints out the PCR before extending. I was
> a little bit surprised to see a none 0 row there.
> Something is fishy, either with me, or the build :)
> 
> here is my policy gen script, btw:
> 
> modprobe tpm_tis
> tcsd
> rm -rf mle_hash lcp.pol vl.pol
> 
> 
> #create hash of tboot
> lcp_mlehash /boot/tboot.gz > mle_hash
> 
> # transform hash into policy
> lcp_crtpol -t hashonly -m mle_hash -o lcp.pol
> 
> XENLINE="/xen.gz tboot=0x01019040 iommu=1 vtd=1 dom0_mem=1024mb
> com1=1115200,8n1 console=vga,com1"
> KERNEL="/vmlinuz-2.6.18.8-xen_unstable ro root=/dev/VolGroup01/LogVol01
> rhgb pciback.hide=(00:1d.7)(00:1d.1)"
> TPM_PW=""

The new policy code strips the module name from the module string provided by GRUB so that location isn't part of the measurement (which it shouldn't be).  Thus, you should not have '/xen.gz ' or '/vmlinuz-2.6.18.8-xen_unstable ' in your strings.

> #create launch policy of the VMM
> tb_polgen --create --type nonfatal vl.pol
> 
> tb_polgen --add --num 0 --pcr 18 --hash image --cmdline "$XENLINE" --
> image /boot/xen.gz vl.pol --verbose >> verbose.txt
> tb_polgen --add --num 1 --pcr 19 --hash image --cmdline "$KERNEL" --
> image /boot/vmlinuz-2.6.18.8-xen_unstable vl.pol --verbose >>
> verbose.txt
> tb_polgen --add --num 2 --pcr 19 --hash image --cmdline "" --image
> /boot/initrd-2.6.18.8-xen_unstable.img vl.pol --verbose >> verbose.txt
> 
> #write policy
> lcp_writepol -i owner -f lcp.pol -p
> lcp_writepol -i 0x20000001 -f vl.pol  -p
> 
> 
> 3) I also noticed with the stable tboot, on a reboot the GETSEC[SEXIT]
> command is not broadcasted.
>    It is however on a shutdown.

When you say "broadcasted" do you mean it doesn't appear on the serial output?  That is likely just due to buffering and when/how the platform actually disables the serial port.  If SEXIT were not done, the system could not reboot successfully (it would TXT_RESET and then the subsequent boot could not launch TXT until a power cycle).

> Just to let you know where I am standing at the moment.

Thanks for your comments and we'll try to keep things fixed up better.

> Cheers
> lIl
> 
> --
> Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
> Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer

Re: [tboot-devel] new location for mercurial repo

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

1) Compilation 
to reproduce the compilation error, I did the following:

[root@lil staging]  hg clone http://www.bughost.org/repos.hg/tboot.hg
destination directory: tboot.hg
requesting all changes
adding changesets
adding manifests
adding file changes
added 91 changesets with 393 changes to 122 files
updating working directory
118 files updated, 0 files merged, 0 files removed, 0 files unresolved
[root@lil staging]  cd tboot.hg
[root@lil tboot.hg] make
...
<compile>
...

mlehash.c:47:34: error: ../include/elf_defns.h: No such file or directory


[root@lil tboot.hg]# ls -la include/elf_defns.h
ls: cannot access include/elf_defns.h: No such file or directory
[root@lil tboot.hg]#

hg reports the following changeset:

changeset:   90:5d19b96f7c0e
tag:         tip
user:        Joseph Cihula <jos...@in...>
date:        Tue Oct 07 12:03:27 2008 -0700
summary:     Added hg repo location to README

I tried two different machines on different networks, same error.
which changeset are you on?

2) I already adopted to the new policy format already, as I have been playing around with the mercurial repository a while ago.
The debug line I added, just prints out the PCR before extending. I was a little bit surprised to see a none 0 row there.
Something is fishy, either with me, or the build :)

here is my policy gen script, btw:

modprobe tpm_tis
tcsd
rm -rf mle_hash lcp.pol vl.pol


#create hash of tboot
lcp_mlehash /boot/tboot.gz > mle_hash

# transform hash into policy
lcp_crtpol -t hashonly -m mle_hash -o lcp.pol

XENLINE="/xen.gz tboot=0x01019040 iommu=1 vtd=1 dom0_mem=1024mb com1=1115200,8n1 console=vga,com1"
KERNEL="/vmlinuz-2.6.18.8-xen_unstable ro root=/dev/VolGroup01/LogVol01 rhgb pciback.hide=(00:1d.7)(00:1d.1)"
TPM_PW=""

date > verbose.txt
#create launch policy of the VMM
tb_polgen --create --type nonfatal vl.pol

tb_polgen --add --num 0 --pcr 18 --hash image --cmdline "$XENLINE" --image /boot/xen.gz vl.pol --verbose >> verbose.txt
tb_polgen --add --num 1 --pcr 19 --hash image --cmdline "$KERNEL" --image /boot/vmlinuz-2.6.18.8-xen_unstable vl.pol --verbose >> verbose.txt
tb_polgen --add --num 2 --pcr 19 --hash image --cmdline "" --image /boot/initrd-2.6.18.8-xen_unstable.img vl.pol --verbose >> verbose.txt

#write policy
lcp_writepol -i owner -f lcp.pol -p 
lcp_writepol -i 0x20000001 -f vl.pol  -p 


3) I also noticed with the stable tboot, on a reboot the GETSEC[SEXIT] command is not broadcasted.
   It is however on a shutdown.

Just to let you know where I am standing at the moment.

Cheers
lIl

-- 
Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! 
Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer

Re: [tboot-devel] new location for mercurial repo

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

> From: Lil Evil [mailto:Lil...@gm...]
> Sent: Monday, October 06, 2008 6:58 AM
> 
> Hi,
> 
> I ve been playing with the new repo straight away.
> seems that elf_defns.h got lost in revision 84, hence compilation
> fails. using old header file seems to work fine.

Try the current tip.  Some files got moved around when Linux support was
added.  I did a clean pull and it built fine.

> However, verifying against policy fails.
> after debugging it seems PCR18 is initially not 0x0 and therefore gets
> extended with wrong values.

The dynamic PCRs are set to all Fs on platform reset and only get
cleared to 0s on initiation of a DRTM (e.g. SENTER).  So if they are
really not 0s before being extended then that would mean that the SENTER
failed.  And the code should not even try to extend them if SENTER
fails.

> debug just outs me the PCR value before extending.
> 
> TBOOT: verifying module "/xen.gz iommu=1 dom0_mem=1024mb
> com1=1115200,8n1 console=vga,com1"...
> TBOOT:   debug2: 00 00 00 00 01 00 00 00 02 00 00 00 00 00 00 00 00 00
> 00 00
> TBOOT:   debug3: 93 40 0a e2 86 6b 8a a3 5e f2 70 93 8f 2d a2 48 4b a5
> a5 93
> TBOOT:   debug4: 93 40 0a e2 86 6b 8a a3 5e f2 70 93 8f 2d a2 48 4b a5
> a5 93
> 
> Hence, I experience a policy mismatch every time.

The policy format has changed as of a month or so ago and the policy
code got a lot of cleanup.  Try with the current tip.

> 
> Cheers
> lIl
> 
> 
> 
> -------- Original-Nachricht --------
> > Datum: Fri, 3 Oct 2008 15:18:43 -0700
> > Von: "Cihula, Joseph" <jos...@in...>
> > An: tbo...@li...
> > Betreff: [tboot-devel] new location for mercurial repo
> 
> > As some people noticed, the recent "upgrade" of SourceForge broke
the
> > tboot mercurial repo.  Since mercurial is not an officially
supported
> > SCM, and there is no longer shell access, I don't see how to fix it
> on
> > SourceForge.
> >
> > So I have moved the repo to a new site:
> > http://www.bughost.org/repos.hg/tboot.hg
> >
> > It contains all of the previous repo's history, etc.
> >
> > Let me know if there are any problems accessing it.
> >
> > Joe
> >
> >
---------------------------------------------------------------------
> -
> > --- This SF.Net email is sponsored by the Moblin Your Move
> Developer's
> > challenge Build the coolest Linux based applications with Moblin SDK
> &
> > win great prizes Grand prize is a trip for two to an Open Source
> event
> > anywhere in the world
> > http://moblin-contest.org/redirect.php?banner_id=100&url=/
> > _______________________________________________
> > tboot-devel mailing list
> > tbo...@li...
> > https://lists.sourceforge.net/lists/listinfo/tboot-devel
> 
> --
> GMX startet ShortView.de. Hier findest Du Leute mit Deinen Interessen!
> Jetzt dabei sein:
> http://www.shortview.de/wasistshortview.php?mc=sv_ext_mf@gmx

Re: [tboot-devel] new location for mercurial repo

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

Hi,

I ve been playing with the new repo straight away.
seems that elf_defns.h got lost in revision 84, hence compilation fails.
using old header file seems to work fine.

However, verifying against policy fails.
after debugging it seems PCR18 is initially not 0x0 and therefore gets extended with wrong values.
debug just outs me the PCR value before extending.

TBOOT: verifying module "/xen.gz iommu=1 dom0_mem=1024mb com1=1115200,8n1
console=vga,com1"...
TBOOT:   debug2: 00 00 00 00 01 00 00 00 02 00 00 00 00 00 00 00 00 00 00 00
TBOOT:   debug3: 93 40 0a e2 86 6b 8a a3 5e f2 70 93 8f 2d a2 48 4b a5 a5 93
TBOOT:   debug4: 93 40 0a e2 86 6b 8a a3 5e f2 70 93 8f 2d a2 48 4b a5 a5 93

Hence, I experience a policy mismatch every time.

Cheers
lIl



-------- Original-Nachricht --------
> Datum: Fri, 3 Oct 2008 15:18:43 -0700
> Von: "Cihula, Joseph" <jos...@in...>
> An: tbo...@li...
> Betreff: [tboot-devel] new location for mercurial repo

> As some people noticed, the recent "upgrade" of SourceForge broke the
> tboot mercurial repo.  Since mercurial is not an officially supported
> SCM, and there is no longer shell access, I don't see how to fix it on
> SourceForge.
> 
> So I have moved the repo to a new site:
> http://www.bughost.org/repos.hg/tboot.hg
> 
> It contains all of the previous repo's history, etc.
> 
> Let me know if there are any problems accessing it.
> 
> Joe
> 
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the
> world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> tboot-devel mailing list
> tbo...@li...
> https://lists.sourceforge.net/lists/listinfo/tboot-devel

-- 
GMX startet ShortView.de. Hier findest Du Leute mit Deinen Interessen!
Jetzt dabei sein: http://www.shortview.de/wasistshortview.php?mc=sv_ext_mf@gmx

Re: [tboot-devel] sealing or unsealing of hashes failed

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

> From: Lil Evil [mailto:Lil...@gm...]
> Sent: Wednesday, October 01, 2008 1:57 AM
> 
> Hi there,
> 
> I have encountered a new problem.
> I have opened a box of worms :)
> TBOOT boots and the verification of tboot,VMM,Dom0 is successful so
> far.
> Then I am getting a sealing or unsealing of hashes failed and return
> value = 00000001
> For my understanding the return value of the seal function indicates a
> TPM_AUTHFAIL.

This is most likely due to the SRK auth not being the null (all 0s)
value.  If you take ownership using the '-z' flag to tpm_takeownership,
the will use null for the SRK auth.

> I checked the source code and also noticed a significant difference
> between the mercurial (changeset:   81:601698c524fa) and stable
release
> (tboot-20080613) in those functions- see below.
> 
> If the LCP is a non-fatal one, the platform boots fine and also
reports
> a successful TXT launch.
> If the policy is of any other type(continue,halt), the machine
> hangs(stops).

The failure of the seal operation is considered fatal for these other
policies, since it means that the PCR values may not get accurately
restored on S3 resume.  Try using the '-z' flag mentioned above and see
if that fixes it.

> 
> Any ideas? I am willing to try patches ;)
> 
> Cheers lIl
> 
> ...
> TBOOT: verifying VMM policy...
> TBOOT: VMM is verified.
> TBOOT: succeeded.
> ...
> TBOOT: verifying dom0 policy...
> TBOOT: dom0 is verified.
> TBOOT: succeeded.
> ....
> 
> so good so far, then I am seeing a
> 
> TBOOT: invalid module #

This was a quirk of the older code.  The latest tboot code has changed
the policy format and doesn't do this.

> 
> followed by
> 
> TBOOT: PCRs before extending:
> TBOOT: PCR 17: b8 2a 63 85 16 d3 96 d5 bc e7 24 e8 2b b7 6b 0a cd 7b
d2
> d2
> TBOOT: PCR 18: b2 03 a0 ac b9 7d d1 0f d3 ec 64 ab dc 4d 08 24 17 2a
35
> 9a
> TBOOT: PCR 19: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00
> 00
> TBOOT: TPM: seal data, return value = 00000001
> TBOOT: sealing or unsealing of hashes failed.
> TBOOT: tboot_shared data:
> TBOOT:   version: 2
> TBOOT:   log_addr: 0x01019040
> TBOOT:   shutdown_entry32: 0x010030a0
> TBOOT:   shutdown_entry64: 0x010030f0
> TBOOT:   shutdown_type: 0
> TBOOT:   s3_tb_wakeup_entry: 0x0008a000
> TBOOT:   s3_k_wakeup_entry: 0x00000000
> TBOOT:   &acpi_sinfo: 0x0101f02c
> TBOOT:   tboot_base: 0x01003000
> TBOOT:   tboot_size: 0x33dbc
> TBOOT: g_log:
> TBOOT:   uuid={0xc0192526, 0x6b30, 0x4db4, 0x844c,
>                 {0xa3, 0xe9, 0x53, 0xb8, 0x81, 0x74}}
> TBOOT:   max_size=3000
> TBOOT:   curr_pos=8b6
> TBOOT: transfering control to xen @0x00100000...
> TBOOT: cpu 1 waking up, SIPI vector=8c000
> 
> --
> GMX startet ShortView.de. Hier findest Du Leute mit Deinen Interessen!
> Jetzt dabei sein:
> http://www.shortview.de/wasistshortview.php?mc=sv_ext_mf@gmx
> 
>
-----------------------------------------------------------------------
> --
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the
> world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> tboot-devel mailing list
> tbo...@li...
> https://lists.sourceforge.net/lists/listinfo/tboot-devel

[tboot-devel] new location for mercurial repo

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

As some people noticed, the recent "upgrade" of SourceForge broke the
tboot mercurial repo.  Since mercurial is not an officially supported
SCM, and there is no longer shell access, I don't see how to fix it on
SourceForge.

So I have moved the repo to a new site:
http://www.bughost.org/repos.hg/tboot.hg

It contains all of the previous repo's history, etc.

Let me know if there are any problems accessing it.

Joe

Re: [tboot-devel] Buying a machine that will actually work with TXT

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

Hal Finney wrote:
> When Trusted Execution was announced, 3 models of computers were
> identified as supporting it: The HP Compaq dc7800, Dell OptiPlex 755
> PC, and the Lenovo ThinkCentre M57p. I don't know of any others that
> have been added to that list since then.
>   

Does anybody know whether the HP or Lenovo systems include a reset 
button?  At least the Ultra Slim Form Factor Optiplex 755s have no reset 
button, meaning that debugging a system hang requires a power cycle that 
clears LT.ERRORCODE, making debugging substantially more difficult.


Alternatively, does anybody know another way to trigger a reset on one 
of these systems? I'm told that there is a CMOS reset byte, and that it 
may be possible to write a value to it that causes the "soft" power 
button on the Optiplex to cause a reset instead of a power off. I have 
not investigated this yet, as I'd rather just get a different machine.


Thanks,
-Jon

Re: [tboot-devel] (no subject)

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

Hi

Spot on.
I must have overlooked the z flag after resetting the TPM.

cheers
lIl

-------- Original-Nachricht --------
> Datum: Thu, 2 Oct 2008 00:15:52 -0700
> Von: "Cihula, Joseph" <jos...@in...>
> An: "Lil Evil" <Lil...@gm...>, tbo...@li...
> Betreff: RE: [tboot-devel] (no subject)

> Most likely this is due to having a non-null SRK auth.  Try re-taking
> ownership using 'tpm_takeownership -z' (the -z flag indicates to set the SRK
> auth to null (all 0s)).
> 
> Joe
> 
> > -----Original Message-----
> > From: Lil Evil [mailto:Lil...@gm...]
> > Sent: Thursday, October 02, 2008 12:06 AM
> > To: tbo...@li...
> > Subject: [tboot-devel] (no subject)
> > 
> > Hi there,
> > 
> > apologies if you get this twice, but the list didn't seem to work for
> > me yesterday..?
> > Original below.
> > 
> > I have encountered a new problem.
> > I have opened a box of worms :)
> > TBOOT boots and the verification of tboot,VMM,Dom0 is successful so
> > far.
> > Then I am getting a sealing or unsealing of hashes failed and return
> > value = 00000001
> > For my understanding the return value of the seal function indicates a
> > TPM_AUTHFAIL.
> > I checked the source code and also noticed a significant difference
> > between the mercurial (changeset:   81:601698c524fa) and stable release
> > (tboot-20080613) in those functions- see below.
> > 
> > If the LCP is a non-fatal one, the platform boots fine and also reports
> > a successful TXT launch.
> > If the policy is of any other type(continue,halt), the machine
> > hangs(stops).
> > 
> > Any ideas? I am willing to try patches ;)
> > 
> > Cheers lIl
> > 
> > 
> > ...
> > TBOOT: verifying VMM policy...
> > TBOOT: VMM is verified.
> > TBOOT: succeeded.
> > ...
> > TBOOT: verifying dom0 policy...
> > TBOOT: dom0 is verified.
> > TBOOT: succeeded.
> > ....
> > 
> > so good so far, then I am seeing a
> > 
> > TBOOT: invalid module #
> > 
> > followed by
> > 
> > TBOOT: PCRs before extending:
> > TBOOT: PCR 17: b8 2a 63 85 16 d3 96 d5 bc e7 24 e8 2b b7 6b 0a cd 7b d2
> > d2
> > TBOOT: PCR 18: b2 03 a0 ac b9 7d d1 0f d3 ec 64 ab dc 4d 08 24 17 2a 35
> > 9a
> > TBOOT: PCR 19: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > 00
> > TBOOT: TPM: seal data, return value = 00000001
> > TBOOT: sealing or unsealing of hashes failed.
> > TBOOT: tboot_shared data:
> > TBOOT:   version: 2
> > TBOOT:   log_addr: 0x01019040
> > TBOOT:   shutdown_entry32: 0x010030a0
> > TBOOT:   shutdown_entry64: 0x010030f0
> > TBOOT:   shutdown_type: 0
> > TBOOT:   s3_tb_wakeup_entry: 0x0008a000
> > TBOOT:   s3_k_wakeup_entry: 0x00000000
> > TBOOT:   &acpi_sinfo: 0x0101f02c
> > TBOOT:   tboot_base: 0x01003000
> > TBOOT:   tboot_size: 0x33dbc
> > TBOOT: g_log:
> > TBOOT:   uuid={0xc0192526, 0x6b30, 0x4db4, 0x844c,
> >                 {0xa3, 0xe9, 0x53, 0xb8, 0x81, 0x74}}
> > TBOOT:   max_size=3000
> > TBOOT:   curr_pos=8b6
> > TBOOT: transfering control to xen @0x00100000...
> > TBOOT: cpu 1 waking up, SIPI vector=8c000
> > 
> > 
> > --
> > GMX Kostenlose Spiele: Einfach online spielen und Spaß haben mit Pastry
> > Passion!
> > http://games.entertainment.gmx.net/de/entertainment/games/free/puzzle/6
> > 169196
> > 
> > -----------------------------------------------------------------------
> > --
> > This SF.Net email is sponsored by the Moblin Your Move Developer's
> > challenge
> > Build the coolest Linux based applications with Moblin SDK & win great
> > prizes
> > Grand prize is a trip for two to an Open Source event anywhere in the
> > world
> > http://moblin-contest.org/redirect.php?banner_id=100&url=/
> > _______________________________________________
> > tboot-devel mailing list
> > tbo...@li...
> > https://lists.sourceforge.net/lists/listinfo/tboot-devel

-- 
GMX startet ShortView.de. Hier findest Du Leute mit Deinen Interessen!
Jetzt dabei sein: http://www.shortview.de/wasistshortview.php?mc=sv_ext_mf@gmx

Re: [tboot-devel] SINIT versions and compatibility

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

As one of the authors of said change, I can tell you that minimizing
future compatibility issues was exactly why we made the changes we did.

When we added the MONITOR method of AP wakeup we realized that the
existing data structures had no way to accommodate this type of change,
such that the MLE and SINIT could mutually discover any
incompatibilities and "negotiate" which method to use.

Because this change was going to break backward compatibility anyway, we
decided to make whatever other necessary changes were required to allow
such discovery and negotiation for future features.  So if developers
follow the guidelines in the MLE Software Devel. Manual, hopefully they
will not need to make large changes again.  So while there may be
additional updates to SINIT, we do not foresee changing the interface
further.

Joe

> -----Original Message-----
> From: Jonathan M. McCune [mailto:jon...@cm...]
> Sent: Thursday, October 02, 2008 8:49 AM
> 
> Hello list,
> 
> The most recent release of tboot introduced some fairly large changes
> in numerous data structures, and requires the new SINIT modules.  As
> somebody who is developing another project leveraging SENTER, I need
to
> port my code forward to use these new modules.  Given the complexity
of
> all of this, I lean heavily on tboot to show me the way.
> 
> How stable can I consider the current (v16?) SINIT modules and their
> interface?  I want my implementation to be usable on commodity
> machines, so it looks like I need to go to at least v16.  Can anyone
offer any
> tips on minimizing pain when a new SINIT module is released?
> 
> Thanks,
> -Jon
> 
>
-----------------------------------------------------------------------
> --
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the
> world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> tboot-devel mailing list
> tbo...@li...
> https://lists.sourceforge.net/lists/listinfo/tboot-devel

[tboot-devel] SINIT versions and compatibility

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

Hello list,

The most recent release of tboot introduced some fairly large changes in
numerous data structures, and requires the new SINIT modules.  As
somebody who is developing another project leveraging SENTER, I need to
port my code forward to use these new modules.  Given the complexity of
all of this, I lean heavily on tboot to show me the way.

How stable can I consider the current (v16?) SINIT modules and their
interface?  I want my implementation to be usable on commodity machines,
so it looks like I need to go to at least v16.  Can anyone offer any
tips on minimizing pain when a new SINIT module is released?

Thanks,
-Jon

Re: [tboot-devel] (no subject)

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

Most likely this is due to having a non-null SRK auth.  Try re-taking ownership using 'tpm_takeownership -z' (the -z flag indicates to set the SRK auth to null (all 0s)).

Joe

> -----Original Message-----
> From: Lil Evil [mailto:Lil...@gm...]
> Sent: Thursday, October 02, 2008 12:06 AM
> To: tbo...@li...
> Subject: [tboot-devel] (no subject)
> 
> Hi there,
> 
> apologies if you get this twice, but the list didn't seem to work for
> me yesterday..?
> Original below.
> 
> I have encountered a new problem.
> I have opened a box of worms :)
> TBOOT boots and the verification of tboot,VMM,Dom0 is successful so
> far.
> Then I am getting a sealing or unsealing of hashes failed and return
> value = 00000001
> For my understanding the return value of the seal function indicates a
> TPM_AUTHFAIL.
> I checked the source code and also noticed a significant difference
> between the mercurial (changeset:   81:601698c524fa) and stable release
> (tboot-20080613) in those functions- see below.
> 
> If the LCP is a non-fatal one, the platform boots fine and also reports
> a successful TXT launch.
> If the policy is of any other type(continue,halt), the machine
> hangs(stops).
> 
> Any ideas? I am willing to try patches ;)
> 
> Cheers lIl
> 
> 
> ...
> TBOOT: verifying VMM policy...
> TBOOT: VMM is verified.
> TBOOT: succeeded.
> ...
> TBOOT: verifying dom0 policy...
> TBOOT: dom0 is verified.
> TBOOT: succeeded.
> ....
> 
> so good so far, then I am seeing a
> 
> TBOOT: invalid module #
> 
> followed by
> 
> TBOOT: PCRs before extending:
> TBOOT: PCR 17: b8 2a 63 85 16 d3 96 d5 bc e7 24 e8 2b b7 6b 0a cd 7b d2
> d2
> TBOOT: PCR 18: b2 03 a0 ac b9 7d d1 0f d3 ec 64 ab dc 4d 08 24 17 2a 35
> 9a
> TBOOT: PCR 19: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 00
> TBOOT: TPM: seal data, return value = 00000001
> TBOOT: sealing or unsealing of hashes failed.
> TBOOT: tboot_shared data:
> TBOOT:   version: 2
> TBOOT:   log_addr: 0x01019040
> TBOOT:   shutdown_entry32: 0x010030a0
> TBOOT:   shutdown_entry64: 0x010030f0
> TBOOT:   shutdown_type: 0
> TBOOT:   s3_tb_wakeup_entry: 0x0008a000
> TBOOT:   s3_k_wakeup_entry: 0x00000000
> TBOOT:   &acpi_sinfo: 0x0101f02c
> TBOOT:   tboot_base: 0x01003000
> TBOOT:   tboot_size: 0x33dbc
> TBOOT: g_log:
> TBOOT:   uuid={0xc0192526, 0x6b30, 0x4db4, 0x844c,
>                 {0xa3, 0xe9, 0x53, 0xb8, 0x81, 0x74}}
> TBOOT:   max_size=3000
> TBOOT:   curr_pos=8b6
> TBOOT: transfering control to xen @0x00100000...
> TBOOT: cpu 1 waking up, SIPI vector=8c000
> 
> 
> --
> GMX Kostenlose Spiele: Einfach online spielen und Spaß haben mit Pastry
> Passion!
> http://games.entertainment.gmx.net/de/entertainment/games/free/puzzle/6
> 169196
> 
> -----------------------------------------------------------------------
> --
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the
> world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> tboot-devel mailing list
> tbo...@li...
> https://lists.sourceforge.net/lists/listinfo/tboot-devel

[tboot-devel] (no subject)

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

Hi there,

apologies if you get this twice, but the list didn't seem to work for me yesterday..?
Original below.

I have encountered a new problem.
I have opened a box of worms :)
TBOOT boots and the verification of tboot,VMM,Dom0 is successful so far.
Then I am getting a sealing or unsealing of hashes failed and return value = 00000001
For my understanding the return value of the seal function indicates a TPM_AUTHFAIL.
I checked the source code and also noticed a significant difference between the mercurial (changeset:   81:601698c524fa) and stable release (tboot-20080613) in those functions- see below.

If the LCP is a non-fatal one, the platform boots fine and also reports a successful TXT launch.
If the policy is of any other type(continue,halt), the machine hangs(stops).

Any ideas? I am willing to try patches ;)

Cheers lIl


...
TBOOT: verifying VMM policy...
TBOOT: VMM is verified.
TBOOT: succeeded.
...
TBOOT: verifying dom0 policy...
TBOOT: dom0 is verified.
TBOOT: succeeded.
....

so good so far, then I am seeing a

TBOOT: invalid module # 

followed by 

TBOOT: PCRs before extending:
TBOOT: PCR 17: b8 2a 63 85 16 d3 96 d5 bc e7 24 e8 2b b7 6b 0a cd 7b d2 d2
TBOOT: PCR 18: b2 03 a0 ac b9 7d d1 0f d3 ec 64 ab dc 4d 08 24 17 2a 35 9a
TBOOT: PCR 19: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
TBOOT: TPM: seal data, return value = 00000001
TBOOT: sealing or unsealing of hashes failed.
TBOOT: tboot_shared data:
TBOOT:   version: 2
TBOOT:   log_addr: 0x01019040
TBOOT:   shutdown_entry32: 0x010030a0
TBOOT:   shutdown_entry64: 0x010030f0
TBOOT:   shutdown_type: 0
TBOOT:   s3_tb_wakeup_entry: 0x0008a000
TBOOT:   s3_k_wakeup_entry: 0x00000000
TBOOT:   &acpi_sinfo: 0x0101f02c
TBOOT:   tboot_base: 0x01003000
TBOOT:   tboot_size: 0x33dbc
TBOOT: g_log:
TBOOT:   uuid={0xc0192526, 0x6b30, 0x4db4, 0x844c,
                {0xa3, 0xe9, 0x53, 0xb8, 0x81, 0x74}}
TBOOT:   max_size=3000
TBOOT:   curr_pos=8b6
TBOOT: transfering control to xen @0x00100000...
TBOOT: cpu 1 waking up, SIPI vector=8c000


-- 
GMX Kostenlose Spiele: Einfach online spielen und Spaß haben mit Pastry Passion!
http://games.entertainment.gmx.net/de/entertainment/games/free/puzzle/6169196

[tboot-devel] sealing or unsealing of hashes failed

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

Hi there,

I have encountered a new problem.
I have opened a box of worms :)
TBOOT boots and the verification of tboot,VMM,Dom0 is successful so far.
Then I am getting a sealing or unsealing of hashes failed and return value = 00000001
For my understanding the return value of the seal function indicates a TPM_AUTHFAIL.
I checked the source code and also noticed a significant difference between the mercurial (changeset:   81:601698c524fa) and stable release (tboot-20080613) in those functions- see below.

If the LCP is a non-fatal one, the platform boots fine and also reports a successful TXT launch.
If the policy is of any other type(continue,halt), the machine hangs(stops).

Any ideas? I am willing to try patches ;)

Cheers lIl

...
TBOOT: verifying VMM policy...
TBOOT: VMM is verified.
TBOOT: succeeded.
...
TBOOT: verifying dom0 policy...
TBOOT: dom0 is verified.
TBOOT: succeeded.
....

so good so far, then I am seeing a

TBOOT: invalid module # 

followed by 

TBOOT: PCRs before extending:
TBOOT: PCR 17: b8 2a 63 85 16 d3 96 d5 bc e7 24 e8 2b b7 6b 0a cd 7b d2 d2
TBOOT: PCR 18: b2 03 a0 ac b9 7d d1 0f d3 ec 64 ab dc 4d 08 24 17 2a 35 9a
TBOOT: PCR 19: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
TBOOT: TPM: seal data, return value = 00000001
TBOOT: sealing or unsealing of hashes failed.
TBOOT: tboot_shared data:
TBOOT:   version: 2
TBOOT:   log_addr: 0x01019040
TBOOT:   shutdown_entry32: 0x010030a0
TBOOT:   shutdown_entry64: 0x010030f0
TBOOT:   shutdown_type: 0
TBOOT:   s3_tb_wakeup_entry: 0x0008a000
TBOOT:   s3_k_wakeup_entry: 0x00000000
TBOOT:   &acpi_sinfo: 0x0101f02c
TBOOT:   tboot_base: 0x01003000
TBOOT:   tboot_size: 0x33dbc
TBOOT: g_log:
TBOOT:   uuid={0xc0192526, 0x6b30, 0x4db4, 0x844c,
                {0xa3, 0xe9, 0x53, 0xb8, 0x81, 0x74}}
TBOOT:   max_size=3000
TBOOT:   curr_pos=8b6
TBOOT: transfering control to xen @0x00100000...
TBOOT: cpu 1 waking up, SIPI vector=8c000

-- 
GMX startet ShortView.de. Hier findest Du Leute mit Deinen Interessen!
Jetzt dabei sein: http://www.shortview.de/wasistshortview.php?mc=sv_ext_mf@gmx

Re: [tboot-devel] Roadmap for trusted IO

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

Mike (and others interested in trusted I/O),

 

Unfortunately, I can only give you the marketing/PR –speak about TXT/Trusted Computing/Security roadmaps.  Typically we would announce new features and capabilities at an IDF (Intel Developers Forum).  We won’t do so on mailing lists (though it is fair game to discuss already announced ones).  We did not announce anything new for TXT or Trusted I/O at this past IDF.

 

That said, we are continuing to progress TXT.  And we do understand the various usage models that would benefit from some form of Trusted I/O.

 

Joe

 

From: Mike Hearn [mailto:mi...@pl...] 
Sent: Monday, September 29, 2008 10:08 AM
To: tbo...@li...
Subject: Re: [tboot-devel] Roadmap for trusted IO

 

 

On Mon, Sep 15, 2008 at 7:22 PM, Mike Hearn <mi...@pl...> wrote:

Hiya,

Given that the general plan for TXT/Trusted Computing in general has
been published for ~6 years now, does Intel plan to publish a more
detailed roadmap for the technology?

In particular I'm interested in whether anybody is working on trusted
IO (graphics/keyboard) today, and if not, what has to be completed
first before it is.



So I guess no roadmap will be forthcoming?

Re: [tboot-devel] no SINIT AC module found

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

Hello list,

You may interpret my previous email as the output provided by an older
version of tboot when used with an SINIT that is too new for it.  Maybe
the tboot.gz file should have a version number appended. :-)

-Jon


Jonathan M. McCune wrote:
> Hello,
> 
> I'm trying to use tboot-20080613.tar.gz on a Dell Optiplex 755 with a
> Q35 chipset.  I built tboot without issue.  I pulled xen-unstable.hg and
> built Xen; it boots successfully.  I grabbed the Q35_X38-SINIT.tar.gz
> from sourceforge and configured grub to include Q35_SINIT_16.BIN as a
> module:
> 
> title tboot-20080613 + xen-unstable.hg-20080929
> root (hd0,2)
> kernel /boot/txt/tboot.gz
> module /boot/xen.gz com1=115200,8n1 console=vga,com1
> module /boot/vmlinuz-2.6.18.8-xen0 root=/dev/sda3 ro console=tty0
> console=ttyS0,115200
> #module /boot/initrd.img-2.6.18.8-xen0
> module /boot/Q35_SINIT_16.BIN
> boot
> 
> Here is the serial output from tboot:
> 
> 
> TBOOT: ***************************************
> TBOOT: begin launch()
> TBOOT: TPM is ready
> TBOOT: TPM: Access reg content: 0x81
> TBOOT: TPM: wait for cmd ready .
> TBOOT: TPM: wait for data available timeout.
> TBOOT: TPM: read nv index 20000001 from offset 00000000, return value =
> 00000009
> TBOOT: Error: read TPM error: 0x9.
> TBOOT: failed to read policy from TPM NV, using default
> TBOOT: tb_policy_index:
> TBOOT:   version = 1
> TBOOT:   policy_type = 0
> TBOOT:   num_policies = 2
> TBOOT:   policy[0]:
> TBOOT:           uuid = {0x756a5bfe, 0x5b0b, 0x4d33, 0xb867,
>                 {0xd7, 0x83, 0xfb, 0x46, 0x36, 0xbf}}
> TBOOT:           hash_alg = 0
> TBOOT:           hash_type = 0
> TBOOT:           num_hashes = 0
> TBOOT:   policy[1]:
> TBOOT:           uuid = {0x894c909f, 0xd614, 0x4625, 0x8a2d,
>                 {0x45, 0x3b, 0x80, 0x10, 0xca, 0x8c}}
> TBOOT:           hash_alg = 0
> TBOOT:           hash_type = 0
> TBOOT:           num_hashes = 0
> TBOOT: IA32_FEATURE_CONTROL_MSR: 0000ff03
> TBOOT: CPU is SMX-capable
> TBOOT: CPU is VMX-capable
> TBOOT: SMX is enabled
> TBOOT: TXT chipset and all needed capabilities present
> TBOOT: bios_os_data (@7d420008, 24):
> TBOOT:   version=2
> TBOOT:   bios_sinit_size=0
> TBOOT:   lcp_pd_base=0
> TBOOT:   lcp_pd_size=0
> TBOOT:   num_logical_procs=2
> TBOOT: LT.ERRORCODE=0
> TBOOT: LT.ESTS=0
> TBOOT: CR0.NE not set
> 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: Access reg content: 0x81
> TBOOT: TPM: wait for cmd ready .
> TBOOT: TPM: wait for data available timeout.
> TBOOT: TPM: read nv index 20000002 from offset 00000000, return value =
> 00000009
> TBOOT: Error: read TPM error: 0x9.
> TBOOT: last boot has no error.
> TBOOT: ACM info_table version mismatch (3a)
> TBOOT: ACM is not an SINIT ACM (aa)
> TBOOT: ACM size is too small: acmod_size=546c9c, acm_hdr->size*4=400000
> TBOOT: no SINIT AC module found
> TBOOT: transfering control to xen @0x00100000...
> 
> 
> Xen does boot, but SENTER did not execute.  That acmod_size looks too
> _big_ to me, so I thought maybe it depended on a particular number of
> entries in the grub config file, so I added the initrd (not strictly
> necessary for the default Xen dom0).  The tboot output:
> 
> TBOOT: ***************************************
> TBOOT: begin launch()
> TBOOT: TPM is ready
> TBOOT: TPM: Access reg content: 0x81
> TBOOT: TPM: wait for cmd ready .
> TBOOT: TPM: wait for data available timeout.
> TBOOT: TPM: read nv index 20000001 from offset 00000000, return value =
> 00000009
> TBOOT: Error: read TPM error: 0x9.
> TBOOT: failed to read policy from TPM NV, using default
> TBOOT: tb_policy_index:
> TBOOT:   version = 1
> TBOOT:   policy_type = 0
> TBOOT:   num_policies = 2
> TBOOT:   policy[0]:
> TBOOT:           uuid = {0x756a5bfe, 0x5b0b, 0x4d33, 0xb867,
>                 {0xd7, 0x83, 0xfb, 0x46, 0x36, 0xbf}}
> TBOOT:           hash_alg = 0
> TBOOT:           hash_type = 0
> TBOOT:           num_hashes = 0
> TBOOT:   policy[1]:
> TBOOT:           uuid = {0x894c909f, 0xd614, 0x4625, 0x8a2d,
>                 {0x45, 0x3b, 0x80, 0x10, 0xca, 0x8c}}
> TBOOT:           hash_alg = 0
> TBOOT:           hash_type = 0
> TBOOT:           num_hashes = 0
> TBOOT: IA32_FEATURE_CONTROL_MSR: 0000ff03
> TBOOT: CPU is SMX-capable
> TBOOT: CPU is VMX-capable
> TBOOT: SMX is enabled
> TBOOT: TXT chipset and all needed capabilities present
> TBOOT: bios_os_data (@7d420008, 24):
> TBOOT:   version=2
> TBOOT:   bios_sinit_size=0
> TBOOT:   lcp_pd_base=0
> TBOOT:   lcp_pd_size=0
> TBOOT:   num_logical_procs=2
> TBOOT: LT.ERRORCODE=0
> TBOOT: LT.ESTS=0
> TBOOT: CR0.NE not set
> 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: Access reg content: 0x81
> TBOOT: TPM: wait for cmd ready .
> TBOOT: TPM: wait for data available timeout.
> TBOOT: TPM: read nv index 20000002 from offset 00000000, return value =
> 00000009
> TBOOT: Error: read TPM error: 0x9.
> TBOOT: last boot has no error.
> TBOOT: ACM info_table version mismatch (3a)
> TBOOT: ACM is not an SINIT ACM (aa)
> TBOOT: ACM size is too small: acmod_size=19f000, acm_hdr->size*4=48819194
> TBOOT: ACM size is too small: acmod_size=546c9c, acm_hdr->size*4=400000
> TBOOT: no SINIT AC module found
> TBOOT: transfering control to xen @0x00100000...
> 
> 
> This is a little bit interesting, in that it is now listing two
> different sizes.  Also, 0x19f000 = 1699840, which IS the size of my
> initrd.img. The 0x546c9c does not correspond to any of the files in my
> grub entry.
> 
> If I name a non-existent file as the final module, grub won't proceed,
> so I can't think of any problems with my grub config file.
> 
> I haven't torn into the MBI structures to see what's going on yet; has
> anybody else encountered this issue?
> 
> Thanks!
> -Jon
> 
> 
> 
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> tboot-devel mailing list
> tbo...@li...
> https://lists.sourceforge.net/lists/listinfo/tboot-devel
> 

[tboot-devel] no SINIT AC module found

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

Hello,

I'm trying to use tboot-20080613.tar.gz on a Dell Optiplex 755 with a
Q35 chipset.  I built tboot without issue.  I pulled xen-unstable.hg and
built Xen; it boots successfully.  I grabbed the Q35_X38-SINIT.tar.gz
from sourceforge and configured grub to include Q35_SINIT_16.BIN as a
module:

title tboot-20080613 + xen-unstable.hg-20080929
root (hd0,2)
kernel /boot/txt/tboot.gz
module /boot/xen.gz com1=115200,8n1 console=vga,com1
module /boot/vmlinuz-2.6.18.8-xen0 root=/dev/sda3 ro console=tty0
console=ttyS0,115200
#module /boot/initrd.img-2.6.18.8-xen0
module /boot/Q35_SINIT_16.BIN
boot

Here is the serial output from tboot:


TBOOT: ***************************************
TBOOT: begin launch()
TBOOT: TPM is ready
TBOOT: TPM: Access reg content: 0x81
TBOOT: TPM: wait for cmd ready .
TBOOT: TPM: wait for data available timeout.
TBOOT: TPM: read nv index 20000001 from offset 00000000, return value =
00000009
TBOOT: Error: read TPM error: 0x9.
TBOOT: failed to read policy from TPM NV, using default
TBOOT: tb_policy_index:
TBOOT:   version = 1
TBOOT:   policy_type = 0
TBOOT:   num_policies = 2
TBOOT:   policy[0]:
TBOOT:           uuid = {0x756a5bfe, 0x5b0b, 0x4d33, 0xb867,
                {0xd7, 0x83, 0xfb, 0x46, 0x36, 0xbf}}
TBOOT:           hash_alg = 0
TBOOT:           hash_type = 0
TBOOT:           num_hashes = 0
TBOOT:   policy[1]:
TBOOT:           uuid = {0x894c909f, 0xd614, 0x4625, 0x8a2d,
                {0x45, 0x3b, 0x80, 0x10, 0xca, 0x8c}}
TBOOT:           hash_alg = 0
TBOOT:           hash_type = 0
TBOOT:           num_hashes = 0
TBOOT: IA32_FEATURE_CONTROL_MSR: 0000ff03
TBOOT: CPU is SMX-capable
TBOOT: CPU is VMX-capable
TBOOT: SMX is enabled
TBOOT: TXT chipset and all needed capabilities present
TBOOT: bios_os_data (@7d420008, 24):
TBOOT:   version=2
TBOOT:   bios_sinit_size=0
TBOOT:   lcp_pd_base=0
TBOOT:   lcp_pd_size=0
TBOOT:   num_logical_procs=2
TBOOT: LT.ERRORCODE=0
TBOOT: LT.ESTS=0
TBOOT: CR0.NE not set
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: Access reg content: 0x81
TBOOT: TPM: wait for cmd ready .
TBOOT: TPM: wait for data available timeout.
TBOOT: TPM: read nv index 20000002 from offset 00000000, return value =
00000009
TBOOT: Error: read TPM error: 0x9.
TBOOT: last boot has no error.
TBOOT: ACM info_table version mismatch (3a)
TBOOT: ACM is not an SINIT ACM (aa)
TBOOT: ACM size is too small: acmod_size=546c9c, acm_hdr->size*4=400000
TBOOT: no SINIT AC module found
TBOOT: transfering control to xen @0x00100000...


Xen does boot, but SENTER did not execute.  That acmod_size looks too
_big_ to me, so I thought maybe it depended on a particular number of
entries in the grub config file, so I added the initrd (not strictly
necessary for the default Xen dom0).  The tboot output:

TBOOT: ***************************************
TBOOT: begin launch()
TBOOT: TPM is ready
TBOOT: TPM: Access reg content: 0x81
TBOOT: TPM: wait for cmd ready .
TBOOT: TPM: wait for data available timeout.
TBOOT: TPM: read nv index 20000001 from offset 00000000, return value =
00000009
TBOOT: Error: read TPM error: 0x9.
TBOOT: failed to read policy from TPM NV, using default
TBOOT: tb_policy_index:
TBOOT:   version = 1
TBOOT:   policy_type = 0
TBOOT:   num_policies = 2
TBOOT:   policy[0]:
TBOOT:           uuid = {0x756a5bfe, 0x5b0b, 0x4d33, 0xb867,
                {0xd7, 0x83, 0xfb, 0x46, 0x36, 0xbf}}
TBOOT:           hash_alg = 0
TBOOT:           hash_type = 0
TBOOT:           num_hashes = 0
TBOOT:   policy[1]:
TBOOT:           uuid = {0x894c909f, 0xd614, 0x4625, 0x8a2d,
                {0x45, 0x3b, 0x80, 0x10, 0xca, 0x8c}}
TBOOT:           hash_alg = 0
TBOOT:           hash_type = 0
TBOOT:           num_hashes = 0
TBOOT: IA32_FEATURE_CONTROL_MSR: 0000ff03
TBOOT: CPU is SMX-capable
TBOOT: CPU is VMX-capable
TBOOT: SMX is enabled
TBOOT: TXT chipset and all needed capabilities present
TBOOT: bios_os_data (@7d420008, 24):
TBOOT:   version=2
TBOOT:   bios_sinit_size=0
TBOOT:   lcp_pd_base=0
TBOOT:   lcp_pd_size=0
TBOOT:   num_logical_procs=2
TBOOT: LT.ERRORCODE=0
TBOOT: LT.ESTS=0
TBOOT: CR0.NE not set
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: Access reg content: 0x81
TBOOT: TPM: wait for cmd ready .
TBOOT: TPM: wait for data available timeout.
TBOOT: TPM: read nv index 20000002 from offset 00000000, return value =
00000009
TBOOT: Error: read TPM error: 0x9.
TBOOT: last boot has no error.
TBOOT: ACM info_table version mismatch (3a)
TBOOT: ACM is not an SINIT ACM (aa)
TBOOT: ACM size is too small: acmod_size=19f000, acm_hdr->size*4=48819194
TBOOT: ACM size is too small: acmod_size=546c9c, acm_hdr->size*4=400000
TBOOT: no SINIT AC module found
TBOOT: transfering control to xen @0x00100000...


This is a little bit interesting, in that it is now listing two
different sizes.  Also, 0x19f000 = 1699840, which IS the size of my
initrd.img. The 0x546c9c does not correspond to any of the files in my
grub entry.

If I name a non-existent file as the final module, grub won't proceed,
so I can't think of any problems with my grub config file.

I haven't torn into the MBI structures to see what's going on yet; has
anybody else encountered this issue?

Thanks!
-Jon

Re: [tboot-devel] Roadmap for trusted IO

[Mike H. <mi...@pl...>]

On Mon, Sep 15, 2008 at 7:22 PM, Mike Hearn <mi...@pl...> wrote:

> Hiya,
>
> Given that the general plan for TXT/Trusted Computing in general has
> been published for ~6 years now, does Intel plan to publish a more
> detailed roadmap for the technology?
>
> In particular I'm interested in whether anybody is working on trusted
> IO (graphics/keyboard) today, and if not, what has to be completed
> first before it is.
>


So I guess no roadmap will be forthcoming?

Re: [tboot-devel] tboot hang

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

Glad that you got it working (I suspected that it was some other BIOS
setting that got changed when TXT was disabled, e.g. VT-d).

I've also forwarded your issue about BIOS hanging on the reboot after an
error to a contact in HP.

As for the repo, SourceForge's recent "upgrade" broke mercurial, which
isn't a supported SCM anyway.  So I'm in the process of relocating it
(just the hg repo) to another server and will send out an email to the
list when it is up.

Joe

> -----Original Message-----
> From: Lil Evil [mailto:Lil...@gm...]
> Sent: Monday, September 29, 2008 2:10 AM
> To: tbo...@li...
> Subject: Re: [tboot-devel] tboot hang
> 
> Hi,
> 
> resetting the TPM and BIOS did the trick.
> btw, the mercurial repository doesn't seem to work anymore.
> 
> thanks
> lIl
> 
> -------- Original-Nachricht --------
> > Datum: Mon, 29 Sep 2008 10:11:37 +0200
> > Von: "Lil Evil" <Lil...@gm...>
> > An: tbo...@li...
> > Betreff: [tboot-devel] tboot hang
> 
> > Hi all,
> >
> > I have some problems getting tboot to work (again).
> > I managed to get tboot - 20080613 and tboot.hg - 18394:1ac3e2a44dc9
> to
> > work properly.
> > I played around with policies and boot parameters and it worked just
> fine.
> >
> > Now, after I disabled and enabled TXT in the Bios, I am struggling
to
> get
> > any tboot version to work.
> > After TBOOT: executing GETSEC[SENTER]... the machine reboots and
> hangs
> > after the BIOS init.
> > It requires a hard reset to power on again. Normal (tboot-less) boot
> works
> > fine.
> > I am on a HP dc7800 machine with BIOS version v1.24
> >
> > Am I missing something?
> > Attached are the tboot logs of a successful & unsuccessful tboot
boot
> > Can I increase the debug level to retrieve something more
meaningful?
> > Any hints welcome.
> >
> > Thanks
> > lil
> > --
> > GMX startet ShortView.de. Hier findest Du Leute mit Deinen
> Interessen!
> > Jetzt dabei sein:
> > http://www.shortview.de/wasistshortview.php?mc=sv_ext_mf@gmx
> 
> --
> GMX startet ShortView.de. Hier findest Du Leute mit Deinen Interessen!
> Jetzt dabei sein:
> http://www.shortview.de/wasistshortview.php?mc=sv_ext_mf@gmx
> 
>
-----------------------------------------------------------------------
> --
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the
> world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> tboot-devel mailing list
> tbo...@li...
> https://lists.sourceforge.net/lists/listinfo/tboot-devel