tboot-devel — Developer support

Re: [tboot-devel] GETSEC[SENTER] fail on HP dc7800

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

Hi Martin, thanks for those links. I've attached the output of lspci
-v when my system is booted with USB disabled. Here is an excerpt, the
only ones that have addresses listed:

00:02.0 VGA compatible controller: Intel Corporation 82Q35 Express
Integrated Graphics Controller (rev 02)
	Subsystem: Hewlett-Packard Company Device 2819
	Flags: bus master, fast devsel, latency 0, IRQ 16
	Memory at f0100000 (32-bit, non-prefetchable) [size=512K]
	I/O ports at 1230 [size=8]
	Memory at e0000000 (32-bit, prefetchable) [size=256M]
	Memory at f0000000 (32-bit, non-prefetchable) [size=1M]
	Capabilities: [90] Message Signalled Interrupts: Mask- 64bit- Queue=0/0 Enable-
	Capabilities: [d0] Power Management version 2

00:19.0 Ethernet controller: Intel Corporation 82566DM-2 Gigabit
Network Connection (rev 02)
	Subsystem: Hewlett-Packard Company Device 2818
	Flags: bus master, fast devsel, latency 0, IRQ 221
	Memory at f0180000 (32-bit, non-prefetchable) [size=128K]
	Memory at f01a1000 (32-bit, non-prefetchable) [size=4K]
	I/O ports at 1100 [size=32]
	Capabilities: [c8] Power Management version 2
	Capabilities: [d0] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable+
	Capabilities: [e0] PCIe advanced features <?>
	Kernel driver in use: e1000e
	Kernel modules: e1000e

Deviice 02.00 is the video controller. It has BARs at f0100000,
e0000000, and f0000000. This device is listed in the DMAR table as
having the DMA remapping registers at fed91000. It is also the device
listed in the RMRR reserved memory table as having addresses
0x3e600000 - 0x3effffff. My interpretation is that the PCI BAR
addresses are mapped to the card itself; the DMA remapping registers
are on a different device, part of the bus controller or chipset; and
the reserved memory region, 10 MB of system RAM, is the video display
RAM. I don't see any problem with all these addresses being different.

The only other device with a BAR in the lspci output is the ethernet
controller at 19.00. It has BARs at f0180000 and f01a1000. The first
one immediately follows the video controller BAR, but it is on a
separate page boundary so is consistent with the advice in the VT-d
spec about BARS not overlapping pages.

The one odd element is that the DMAR table shows DMA remapping
hardware #2 in a DRHD table, which covers PCI devices 03.00, 03.02,
and 03.03. However, lspci does not show any PCI devices at 03.XX. So I
don't know what devices those would be, if they exist. I don't know if
there is any requirement that the DHRD entries refer to actually
existing PCI devices. I wonder where the BIOS came up with these.

One other big question I have is, where does SINIT get the DMAR table?
Is it just looking at known addresses in RAM and parsing ACPI data?
Would it be possible for TBOOT to patch the DMAR table in memory
before launching SINIT, in order to see if SINIT liked it any better?
I should try an experiment of changing the DMAR checksum, see if SINIT
complains about that (it's an earlier error code so presumably is
checked sooner). If so, I could take out all of the DRHD's and RMRR's
and see if SINIT likes it any better.

Hal


On Fri, Jul 31, 2009 at 12:17 PM, Martin Thiim<ma...@th...> wrote:
> Hello Hal
>
> For a bit more on the PCI BAR, see this:
>
> http://docs.sun.com/app/docs/doc/819-3196/6n5ed4hmv?a=view
>
> Every PCI device has these registers that give the base address/range
> of its registers. It seems these ranges don't match those in DMAR. It
> makes sense SINIT would/could check this.
>
> Best regards,
>
> Martin Thiim
>
> On Thu, Jul 30, 2009 at 10:07 PM, Martin Thiim<ma...@th...> wrote:
>> Hello Hal
>>
>> I could be wrong, but I think what the "Enable VT-d" option in the
>> BIOS really refers to is whether the BIOS should set up the ACPI
>> tables related to VT-d.
>>
>> You could use acpidump to see if those tables contain anything VT-d
>> related (DMAR and the like) - the VT-d spec would be helpful for this.
>>
>> http://download.intel.com/technology/computing/vptech/Intel(r)_VT_for_Direct_IO.pdf
>>
>> I currently don't have access to my VT-d system so I can't give you a
>> table of what it looks like on my machine but perhaps others could.
>>
>> Best regards,
>>
>> Martin Thiim
>>
>> On Thu, Jul 30, 2009 at 7:28 PM, Hal Finney<hal...@gm...> wrote:
>>> Hi Shane - I'm not sure what it would do to add these switches, since
>>> tboot doesn't get as far as launching the kernel, since it hangs in
>>> SENTER. However I can try doing it and then just booting into the
>>> kernel, in case I get any error reports about VT-d.
>>>
>>> Are there any MSRs or other registers I can patch tboot to dump out,
>>> to indicate whether VT-d is turned on?
>>>
>>> My HP dc7800 was one of the very first commercially released systems
>>> to support TXT. I bought one as soon as they became available in order
>>> to experiment with this technology. It has an E6550 "Conroe" processor
>>> with a Q35 "Bearlake" chipset.
>>>
>>> Hal
>>>
>>> On Thu, Jul 30, 2009 at 12:24 AM, Shane Wang<sha...@in...> wrote:
>>>> Hal,
>>>>
>>>> If you work with Xen, please try to add "iommu=1 vtd=1" in Xen command line
>>>> (i.e. the end of "module /boot/xen.gz ...")
>>>> If you work with Linux, please try to add "iommu=on" in the command
>>>> line (i.e. the end of "module /boot/vmlinuz-2.6.30 ..."
>>>>
>>>> PS: do you know which platform HP dc7800 is? *Field or *Dale?
>>>> Can you see VTd lsoc (Azalia) WA in BIOS or somewhere?
>>>>
>>>> Thanks.
>>>> Shane
>>>>
>>>> Hal Finney wrote:
>>>>>
>>>>> Thanks for the reply, Shane. VT-d is enabled in the BIOS; in fact, the
>>>>> BIOS automatically enables VT-d when TXT is enabled.
>>>>>
>>>>> I don't know of anything I would do in any grub configuration file to
>>>>> enable VT-d for tboot and SINIT. Do you have any suggestions?
>>>>>
>>>>> Hal
>>>>>
>>>>> On Wed, Jul 29, 2009 at 10:04 PM, Shane Wang<sha...@in...> wrote:
>>>>>>
>>>>>> Hi Hal
>>>>>>
>>>>>> The error code means VTd is disabled.
>>>>>> Is your VT-d enabled in your new BIOS and grub.conf?
>>>>>>
>>>>>> Thanks.
>>>>>> Shane
>>>>>>
>>>>>> Hal Finney wrote:
>>>>>>>
>>>>>>> I haven't run tboot in a while, but I'm trying it on my HP dc7800 and
>>>>>>> finding it hangs in GETSEC[SENTER]. This is even true with old
>>>>>>> versions of tboot that used to work. My system has no USB ports
>>>>>>> plugged in, and no hardware changes.
>>>>>>>
>>>>>>> The one change is I recently updated my BIOS. I suspect this has to be
>>>>>>> the cause. One nice thing about the new BIOS is that the tboot hang
>>>>>>> actually reboots the machine with the ERRORCODE register intact. Its
>>>>>>> value is c00020a1. This is progress code 0ah, error code 1000,
>>>>>>> meaning: "device scope of VT-d DMAR ACPI table is invalid". Not clear
>>>>>>> what this means.
>>>>>>>
>>>>>>> My log is attached, including the hang and the relaunch of tboot. This
>>>>>>> is version 20090330 of tboot. Thanks very much -
>>>>>>>
>>>>>>> Hal Finney
>>>>>>
>>>>
>>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
>>> trial. Simplify your report design, integration and deployment - and focus on
>>> what you do best, core application coding. Discover what's new with
>>> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
>>> _______________________________________________
>>> tboot-devel mailing list
>>> tbo...@li...
>>> https://lists.sourceforge.net/lists/listinfo/tboot-devel
>>>
>>
>

Re: [tboot-devel] GETSEC[SENTER] fail on HP dc7800

[Martin T. <ma...@th...>]

Hello Hal

For a bit more on the PCI BAR, see this:

http://docs.sun.com/app/docs/doc/819-3196/6n5ed4hmv?a=view

Every PCI device has these registers that give the base address/range
of its registers. It seems these ranges don't match those in DMAR. It
makes sense SINIT would/could check this.

Best regards,

Martin Thiim

On Thu, Jul 30, 2009 at 10:07 PM, Martin Thiim<ma...@th...> wrote:
> Hello Hal
>
> I could be wrong, but I think what the "Enable VT-d" option in the
> BIOS really refers to is whether the BIOS should set up the ACPI
> tables related to VT-d.
>
> You could use acpidump to see if those tables contain anything VT-d
> related (DMAR and the like) - the VT-d spec would be helpful for this.
>
> http://download.intel.com/technology/computing/vptech/Intel(r)_VT_for_Direct_IO.pdf
>
> I currently don't have access to my VT-d system so I can't give you a
> table of what it looks like on my machine but perhaps others could.
>
> Best regards,
>
> Martin Thiim
>
> On Thu, Jul 30, 2009 at 7:28 PM, Hal Finney<hal...@gm...> wrote:
>> Hi Shane - I'm not sure what it would do to add these switches, since
>> tboot doesn't get as far as launching the kernel, since it hangs in
>> SENTER. However I can try doing it and then just booting into the
>> kernel, in case I get any error reports about VT-d.
>>
>> Are there any MSRs or other registers I can patch tboot to dump out,
>> to indicate whether VT-d is turned on?
>>
>> My HP dc7800 was one of the very first commercially released systems
>> to support TXT. I bought one as soon as they became available in order
>> to experiment with this technology. It has an E6550 "Conroe" processor
>> with a Q35 "Bearlake" chipset.
>>
>> Hal
>>
>> On Thu, Jul 30, 2009 at 12:24 AM, Shane Wang<sha...@in...> wrote:
>>> Hal,
>>>
>>> If you work with Xen, please try to add "iommu=1 vtd=1" in Xen command line
>>> (i.e. the end of "module /boot/xen.gz ...")
>>> If you work with Linux, please try to add "iommu=on" in the command
>>> line (i.e. the end of "module /boot/vmlinuz-2.6.30 ..."
>>>
>>> PS: do you know which platform HP dc7800 is? *Field or *Dale?
>>> Can you see VTd lsoc (Azalia) WA in BIOS or somewhere?
>>>
>>> Thanks.
>>> Shane
>>>
>>> Hal Finney wrote:
>>>>
>>>> Thanks for the reply, Shane. VT-d is enabled in the BIOS; in fact, the
>>>> BIOS automatically enables VT-d when TXT is enabled.
>>>>
>>>> I don't know of anything I would do in any grub configuration file to
>>>> enable VT-d for tboot and SINIT. Do you have any suggestions?
>>>>
>>>> Hal
>>>>
>>>> On Wed, Jul 29, 2009 at 10:04 PM, Shane Wang<sha...@in...> wrote:
>>>>>
>>>>> Hi Hal
>>>>>
>>>>> The error code means VTd is disabled.
>>>>> Is your VT-d enabled in your new BIOS and grub.conf?
>>>>>
>>>>> Thanks.
>>>>> Shane
>>>>>
>>>>> Hal Finney wrote:
>>>>>>
>>>>>> I haven't run tboot in a while, but I'm trying it on my HP dc7800 and
>>>>>> finding it hangs in GETSEC[SENTER]. This is even true with old
>>>>>> versions of tboot that used to work. My system has no USB ports
>>>>>> plugged in, and no hardware changes.
>>>>>>
>>>>>> The one change is I recently updated my BIOS. I suspect this has to be
>>>>>> the cause. One nice thing about the new BIOS is that the tboot hang
>>>>>> actually reboots the machine with the ERRORCODE register intact. Its
>>>>>> value is c00020a1. This is progress code 0ah, error code 1000,
>>>>>> meaning: "device scope of VT-d DMAR ACPI table is invalid". Not clear
>>>>>> what this means.
>>>>>>
>>>>>> My log is attached, including the hang and the relaunch of tboot. This
>>>>>> is version 20090330 of tboot. Thanks very much -
>>>>>>
>>>>>> Hal Finney
>>>>>
>>>
>>>
>>
>> ------------------------------------------------------------------------------
>> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
>> trial. Simplify your report design, integration and deployment - and focus on
>> what you do best, core application coding. Discover what's new with
>> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
>> _______________________________________________
>> tboot-devel mailing list
>> tbo...@li...
>> https://lists.sourceforge.net/lists/listinfo/tboot-devel
>>
>

Re: [tboot-devel] GETSEC[SENTER] fail on HP dc7800

[Martin T. <ma...@th...>]

>From Googling, it seems BAR is a general PCI concept. The VT-d spec
mentions it in "8.3.6 Implications with Provisioning PCI BAR
Resources" (just next to the DRHD section) but doesn't give an obvious
clue to this error message (seems to be more of a recommendation).

Could it be that the register base/range in the table is somehow in
conflict with what SINIT can see by other means of PCI enumeration?
Maybe the table is now incomplete (since the error occurred after an
apparent simplification in the table, and with an error code that
seems to relate to an earlier check than before?). Perhaps you could
send a dump from lspci - it would be interesting to cross-reference it
with the values in the DMAR.

Best regards,

Martin Thiim

On Fri, Jul 31, 2009 at 7:31 PM, Hal Finney<hal...@gm...> wrote:
> I did another experiment, disabling USB and also audio in BIOS, and
> trying tboot. It hung again in GETSEC[SENTER] as before. Upon
> restarting it, it dumped the error code register, which was different
> this time: Progress 0ah, error 6. That is:
>
> "BARs in VT-d DMAR DRHD struct mismatch"
>
> I am attaching the log of the two boot attempts (the first which hangs
> in SENTER, followed by the reboot which displays the error code). Here
> is the output of Ross's dmardump program in this state with USB
> disabled:
>
> DMAR dump utility - reading memory
> DMA Remapping Reporting Structure
> ==================================================
> Signature:        DMAR
> Length:           0x000000a0
> Revision:         0x01
> Checksum:         0xb0
> OEMID:            COMPAQ
> OEM Table ID:     BEARLAKE
> OEM Revision:     0x00000001
> Creator ID:
> Creator Revision: 0x00000000
> HAW:              0x23
> Flags:            0x00
> Reserved[10]: 00 00 00 00 00 00 00 00 00 00
>
> Remapping Structures...
>
> DMA Remapping Hardware Unit Definition (DRHD) Structure #1
> Type:           0x0000 (ACPI_DMAR_DRHD)
> Length:         0x0018
> Flags:          0x00  -- INCLUDE_ALL = no
> Reserved:       0x00
> Segment Number: 0x0000
> Register Base:  0xfed91000
>    Device Scope Structure #1
>    ==========================
>    Type:           0x01 (ACPI_DEV_ENDPOINT)
>    Length:         0x08
>    Reserved:       00 00
>    Enumeration ID: 0x00 - Reserved
>    Start Bus Num:  0x00
>    Path Depth = 1, Path Entries:
>       -- Device: 0x02 Function: 0x00
>
> DMA Remapping Hardware Unit Definition (DRHD) Structure #2
> Type:           0x0000 (ACPI_DMAR_DRHD)
> Length:         0x0028
> Flags:          0x00  -- INCLUDE_ALL = no
> Reserved:       0x00
> Segment Number: 0x0000
> Register Base:  0xfed92000
>    Device Scope Structure #1
>    ==========================
>    Type:           0x01 (ACPI_DEV_ENDPOINT)
>    Length:         0x08
>    Reserved:       00 00
>    Enumeration ID: 0x00 - Reserved
>    Start Bus Num:  0x00
>    Path Depth = 1, Path Entries:
>       -- Device: 0x03 Function: 0x00
>    Device Scope Structure #2
>    ==========================
>    Type:           0x01 (ACPI_DEV_ENDPOINT)
>    Length:         0x08
>    Reserved:       00 00
>    Enumeration ID: 0x00 - Reserved
>    Start Bus Num:  0x00
>    Path Depth = 1, Path Entries:
>       -- Device: 0x03 Function: 0x02
>    Device Scope Structure #3
>    ==========================
>    Type:           0x01 (ACPI_DEV_ENDPOINT)
>    Length:         0x08
>    Reserved:       00 00
>    Enumeration ID: 0x00 - Reserved
>    Start Bus Num:  0x00
>    Path Depth = 1, Path Entries:
>       -- Device: 0x03 Function: 0x03
>
> DMA Remapping Hardware Unit Definition (DRHD) Structure #3
> Type:           0x0000 (ACPI_DMAR_DRHD)
> Length:         0x0010
> Flags:          0x01  -- INCLUDE_ALL = yes
> Reserved:       0x00
> Segment Number: 0x0000
> Register Base:  0xfed93000
>
> Reserved Memory Region Reporting (RMRR) Structure #1
> Type:           0x0001 (ACPI_DMAR_RMRR)
> Length:         0x0020
> Reserved:       0x0000
> Segment Number: 0x0000
> Base Address:   0x3e600000
> End Address:    0x3effffff
>    Device Scope Structure #1
>    ==========================
>    Type:           0x01 (ACPI_DEV_ENDPOINT)
>    Length:         0x08
>    Reserved:       00 00
>    Enumeration ID: 0x00 - Reserved
>    Start Bus Num:  0x00
>    Path Depth = 1, Path Entries:
>       -- Device: 0x02 Function: 0x00
>
> ==================================================
> End DMAR
>
>
> A couple of differences: there is one fewer DRHD structure, 3 instead
> of 4, and there is only one RMRR structure instead of several. This
> one also avoids the potential problem Martin pointed out, that the
> device scopes under the RMRR's don't explicitly match any of the ones
> under the DRHD's. In this one, the only RMRR is device 2, function 0,
> which is covered explicitly under the first DRHD. I do agree with Ross
> that the full DMAR struct I posted earlier is kosher because of the
> INCLUDE_ALL DRHD which should cover all devices in PCI segment 0000,
> but just because we read the spec this way, that doesn't mean the
> SINIT author read it that way.
>
> (The frustrating thing is, SINIT doesn't actually seem to do anything
> with this DMAR data. It just copies it to the SinitMleData struct, for
> use by the MLE. SINIT wants to put the data into the TXT heap so it is
> protected. It is apparently just doing some sanity checks on the data
> structures before doing the copy, and obviously the SINIT author and
> the HP BIOS author were not on the same page. This happens a lot in
> implementing specs. But for me it means that we have two opaque pieces
> of code which are incompatible, and both only get updated a couple of
> times a year at best.)
>
> Anyway, back to the SINIT error, "BARs in Vt-d DMAR DRHD struct
> mismatch". It's like a Zen koan, what is the sound of one hand
> clapping. You have to try to puzzle out what on earth this could mean.
> First, what's a BAR? The closest thing I can see in the table is
> Register Base Address, which maybe could be called Base Address
> Register or BAR. Then, we have a complaint about a mismatch. Mismatch?
> What is it supposed to match against? It's just an address.
>
> The base addresses in the 3 DRHD structs are 0xfed91000, 0xfed92000,
> and 0xfed93000. Is that a problem? They seem reasonable enough to me.
> I can't figure out what it means to complain about a mismatch.
>
> This error code, 6, is less than the earlier error code with USB
> enabled, 8. I'm guessing that SINIT applies all these sanity checks to
> the DMAR data in order, and errors out when it doesn't like one. This
> suggests that it is not getting as far as it got earlier, so I don't
> know whether it still would have hit error code 8 or not (which was
> device scope invalid).
>
> The one other unusual aspect of my machine is that it has only 1 gig
> of memory. I was cheap when I ordered it, and it's run fine for what
> I've used it for. Conceivably the SINIT authors may have accidentally
> assumed a larger memory configuration would have been in use, in
> sanity checking some addresses. I suppose I could add a second gig and
> see if that makes a difference, but it seems like a long shot.
>
> At this point I will wait and hope to hear something from the SINIT
> group, if they have any ideas. I would of course be happy to run an
> experimental SINIT with additional debugging outputs or error codes if
> that would help. I'll also try reverting the BIOS version and see if
> that makes a difference.
>
> Thanks for all your help -
>
> Hal Finney
>

Re: [tboot-devel] GETSEC[SENTER] fail on HP dc7800

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

I did another experiment, disabling USB and also audio in BIOS, and
trying tboot. It hung again in GETSEC[SENTER] as before. Upon
restarting it, it dumped the error code register, which was different
this time: Progress 0ah, error 6. That is:

"BARs in VT-d DMAR DRHD struct mismatch"

I am attaching the log of the two boot attempts (the first which hangs
in SENTER, followed by the reboot which displays the error code). Here
is the output of Ross's dmardump program in this state with USB
disabled:

DMAR dump utility - reading memory
DMA Remapping Reporting Structure
==================================================
Signature:        DMAR
Length:           0x000000a0
Revision:         0x01
Checksum:         0xb0
OEMID:            COMPAQ
OEM Table ID:     BEARLAKE
OEM Revision:     0x00000001
Creator ID:
Creator Revision: 0x00000000
HAW:              0x23
Flags:            0x00
Reserved[10]: 00 00 00 00 00 00 00 00 00 00

Remapping Structures...

DMA Remapping Hardware Unit Definition (DRHD) Structure #1
Type:           0x0000 (ACPI_DMAR_DRHD)
Length:         0x0018
Flags:          0x00  -- INCLUDE_ALL = no
Reserved:       0x00
Segment Number: 0x0000
Register Base:  0xfed91000
    Device Scope Structure #1
    ==========================
    Type:           0x01 (ACPI_DEV_ENDPOINT)
    Length:         0x08
    Reserved:       00 00
    Enumeration ID: 0x00 - Reserved
    Start Bus Num:  0x00
    Path Depth = 1, Path Entries:
       -- Device: 0x02 Function: 0x00

DMA Remapping Hardware Unit Definition (DRHD) Structure #2
Type:           0x0000 (ACPI_DMAR_DRHD)
Length:         0x0028
Flags:          0x00  -- INCLUDE_ALL = no
Reserved:       0x00
Segment Number: 0x0000
Register Base:  0xfed92000
    Device Scope Structure #1
    ==========================
    Type:           0x01 (ACPI_DEV_ENDPOINT)
    Length:         0x08
    Reserved:       00 00
    Enumeration ID: 0x00 - Reserved
    Start Bus Num:  0x00
    Path Depth = 1, Path Entries:
       -- Device: 0x03 Function: 0x00
    Device Scope Structure #2
    ==========================
    Type:           0x01 (ACPI_DEV_ENDPOINT)
    Length:         0x08
    Reserved:       00 00
    Enumeration ID: 0x00 - Reserved
    Start Bus Num:  0x00
    Path Depth = 1, Path Entries:
       -- Device: 0x03 Function: 0x02
    Device Scope Structure #3
    ==========================
    Type:           0x01 (ACPI_DEV_ENDPOINT)
    Length:         0x08
    Reserved:       00 00
    Enumeration ID: 0x00 - Reserved
    Start Bus Num:  0x00
    Path Depth = 1, Path Entries:
       -- Device: 0x03 Function: 0x03

DMA Remapping Hardware Unit Definition (DRHD) Structure #3
Type:           0x0000 (ACPI_DMAR_DRHD)
Length:         0x0010
Flags:          0x01  -- INCLUDE_ALL = yes
Reserved:       0x00
Segment Number: 0x0000
Register Base:  0xfed93000

Reserved Memory Region Reporting (RMRR) Structure #1
Type:           0x0001 (ACPI_DMAR_RMRR)
Length:         0x0020
Reserved:       0x0000
Segment Number: 0x0000
Base Address:   0x3e600000
End Address:    0x3effffff
    Device Scope Structure #1
    ==========================
    Type:           0x01 (ACPI_DEV_ENDPOINT)
    Length:         0x08
    Reserved:       00 00
    Enumeration ID: 0x00 - Reserved
    Start Bus Num:  0x00
    Path Depth = 1, Path Entries:
       -- Device: 0x02 Function: 0x00

==================================================
End DMAR


A couple of differences: there is one fewer DRHD structure, 3 instead
of 4, and there is only one RMRR structure instead of several. This
one also avoids the potential problem Martin pointed out, that the
device scopes under the RMRR's don't explicitly match any of the ones
under the DRHD's. In this one, the only RMRR is device 2, function 0,
which is covered explicitly under the first DRHD. I do agree with Ross
that the full DMAR struct I posted earlier is kosher because of the
INCLUDE_ALL DRHD which should cover all devices in PCI segment 0000,
but just because we read the spec this way, that doesn't mean the
SINIT author read it that way.

(The frustrating thing is, SINIT doesn't actually seem to do anything
with this DMAR data. It just copies it to the SinitMleData struct, for
use by the MLE. SINIT wants to put the data into the TXT heap so it is
protected. It is apparently just doing some sanity checks on the data
structures before doing the copy, and obviously the SINIT author and
the HP BIOS author were not on the same page. This happens a lot in
implementing specs. But for me it means that we have two opaque pieces
of code which are incompatible, and both only get updated a couple of
times a year at best.)

Anyway, back to the SINIT error, "BARs in Vt-d DMAR DRHD struct
mismatch". It's like a Zen koan, what is the sound of one hand
clapping. You have to try to puzzle out what on earth this could mean.
First, what's a BAR? The closest thing I can see in the table is
Register Base Address, which maybe could be called Base Address
Register or BAR. Then, we have a complaint about a mismatch. Mismatch?
What is it supposed to match against? It's just an address.

The base addresses in the 3 DRHD structs are 0xfed91000, 0xfed92000,
and 0xfed93000. Is that a problem? They seem reasonable enough to me.
I can't figure out what it means to complain about a mismatch.

This error code, 6, is less than the earlier error code with USB
enabled, 8. I'm guessing that SINIT applies all these sanity checks to
the DMAR data in order, and errors out when it doesn't like one. This
suggests that it is not getting as far as it got earlier, so I don't
know whether it still would have hit error code 8 or not (which was
device scope invalid).

The one other unusual aspect of my machine is that it has only 1 gig
of memory. I was cheap when I ordered it, and it's run fine for what
I've used it for. Conceivably the SINIT authors may have accidentally
assumed a larger memory configuration would have been in use, in
sanity checking some addresses. I suppose I could add a second gig and
see if that makes a difference, but it seems like a long shot.

At this point I will wait and hope to hear something from the SINIT
group, if they have any ideas. I would of course be happy to run an
experimental SINIT with additional debugging outputs or error codes if
that would help. I'll also try reverting the BIOS version and see if
that makes a difference.

Thanks for all your help -

Hal Finney

Re: [tboot-devel] GETSEC[SENTER] fail on HP dc7800

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

Well except DRHD #4 has the INCLUDE_ALL = yes which IIRC means it is the catch-all for devices not explicitly reporting under another DRHD. So "Device: 0x1d Function: 0x07" would be under the scope of this DRHD.

Thanks
Ross

-----Original Message-----
From: Martin Thiim [mailto:ma...@th...] 
Sent: Friday, July 31, 2009 9:21 AM
To: Ross Philipson
Cc: Hal Finney; tbo...@li...
Subject: Re: [tboot-devel] GETSEC[SENTER] fail on HP dc7800

Hello Ross

Right, I had not noticed the utility operated at the ACPI-level; I
only jumped into the thread when I saw Hal's question on how to detect
if the BIOS actually had enabled VT-d. Based on the ACPI tables the
answer is a "yes" :-)

I think I may have found the error in the tables though! In the
description of the RMRR's under the DMAR the spec says on pg. 75 (in
the description of the device scope under the RMRR):

"The Device Scope structure contains...The
devices identified in this structure must be devices
under the scope of one of the remapping hardware
units reported in _DRHD_."

This was taken from:
http://download.intel.com/technology/computing/vptech/Intel(r)_VT_for_Direct_IO.pdf

However, consider the DeviceScope "-- Device: 0x1d Function: 0x07"
reported under RMRR #2 and of some of the other RMRR's. This device is
not present under any DRHD in the entire DMAR. This seems to be a
violation of the spec. And it makes sense with the error code Hal got,
"device scope of VT-d DMAR ACPI table is invalid"

Best regards,

Martin Thiim

On Thu, Jul 30, 2009 at 11:14 PM, Ross
Philipson<Ros...@ci...> wrote:
> Martin,
>
> The dump utility I gave Hal earlier was reading the ACPI tables and formatting/tracing out the DMAR table from his system. The DMAR is there and on the surface it looked correct to me (at least nothing obviously wrong with it). Hal attached the trace in an earlier reply.
>
> Thanks
> Ross
>
> -----Original Message-----
> From: Martin Thiim [mailto:ma...@th...]
> Sent: Thursday, July 30, 2009 4:07 PM
> To: Hal Finney
> Cc: tbo...@li...
> Subject: Re: [tboot-devel] GETSEC[SENTER] fail on HP dc7800
>
> Hello Hal
>
> I could be wrong, but I think what the "Enable VT-d" option in the
> BIOS really refers to is whether the BIOS should set up the ACPI
> tables related to VT-d.
>
> You could use acpidump to see if those tables contain anything VT-d
> related (DMAR and the like) - the VT-d spec would be helpful for this.
>
> http://download.intel.com/technology/computing/vptech/Intel(r)_VT_for_Direct_IO.pdf
>
> I currently don't have access to my VT-d system so I can't give you a
> table of what it looks like on my machine but perhaps others could.
>
> Best regards,
>
> Martin Thiim
>
> On Thu, Jul 30, 2009 at 7:28 PM, Hal Finney<hal...@gm...> wrote:
>> Hi Shane - I'm not sure what it would do to add these switches, since
>> tboot doesn't get as far as launching the kernel, since it hangs in
>> SENTER. However I can try doing it and then just booting into the
>> kernel, in case I get any error reports about VT-d.
>>
>> Are there any MSRs or other registers I can patch tboot to dump out,
>> to indicate whether VT-d is turned on?
>>
>> My HP dc7800 was one of the very first commercially released systems
>> to support TXT. I bought one as soon as they became available in order
>> to experiment with this technology. It has an E6550 "Conroe" processor
>> with a Q35 "Bearlake" chipset.
>>
>> Hal
>>
>> On Thu, Jul 30, 2009 at 12:24 AM, Shane Wang<sha...@in...> wrote:
>>> Hal,
>>>
>>> If you work with Xen, please try to add "iommu=1 vtd=1" in Xen command line
>>> (i.e. the end of "module /boot/xen.gz ...")
>>> If you work with Linux, please try to add "iommu=on" in the command
>>> line (i.e. the end of "module /boot/vmlinuz-2.6.30 ..."
>>>
>>> PS: do you know which platform HP dc7800 is? *Field or *Dale?
>>> Can you see VTd lsoc (Azalia) WA in BIOS or somewhere?
>>>
>>> Thanks.
>>> Shane
>>>
>>> Hal Finney wrote:
>>>>
>>>> Thanks for the reply, Shane. VT-d is enabled in the BIOS; in fact, the
>>>> BIOS automatically enables VT-d when TXT is enabled.
>>>>
>>>> I don't know of anything I would do in any grub configuration file to
>>>> enable VT-d for tboot and SINIT. Do you have any suggestions?
>>>>
>>>> Hal
>>>>
>>>> On Wed, Jul 29, 2009 at 10:04 PM, Shane Wang<sha...@in...> wrote:
>>>>>
>>>>> Hi Hal
>>>>>
>>>>> The error code means VTd is disabled.
>>>>> Is your VT-d enabled in your new BIOS and grub.conf?
>>>>>
>>>>> Thanks.
>>>>> Shane
>>>>>
>>>>> Hal Finney wrote:
>>>>>>
>>>>>> I haven't run tboot in a while, but I'm trying it on my HP dc7800 and
>>>>>> finding it hangs in GETSEC[SENTER]. This is even true with old
>>>>>> versions of tboot that used to work. My system has no USB ports
>>>>>> plugged in, and no hardware changes.
>>>>>>
>>>>>> The one change is I recently updated my BIOS. I suspect this has to be
>>>>>> the cause. One nice thing about the new BIOS is that the tboot hang
>>>>>> actually reboots the machine with the ERRORCODE register intact. Its
>>>>>> value is c00020a1. This is progress code 0ah, error code 1000,
>>>>>> meaning: "device scope of VT-d DMAR ACPI table is invalid". Not clear
>>>>>> what this means.
>>>>>>
>>>>>> My log is attached, including the hang and the relaunch of tboot. This
>>>>>> is version 20090330 of tboot. Thanks very much -
>>>>>>
>>>>>> Hal Finney
>>>>>
>>>
>>>
>>
>> ------------------------------------------------------------------------------
>> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
>> trial. Simplify your report design, integration and deployment - and focus on
>> what you do best, core application coding. Discover what's new with
>> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
>> _______________________________________________
>> tboot-devel mailing list
>> tbo...@li...
>> https://lists.sourceforge.net/lists/listinfo/tboot-devel
>>
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> tboot-devel mailing list
> tbo...@li...
> https://lists.sourceforge.net/lists/listinfo/tboot-devel
>

Re: [tboot-devel] GETSEC[SENTER] fail on HP dc7800

[Martin T. <ma...@th...>]

Hello Ross

Right, I had not noticed the utility operated at the ACPI-level; I
only jumped into the thread when I saw Hal's question on how to detect
if the BIOS actually had enabled VT-d. Based on the ACPI tables the
answer is a "yes" :-)

I think I may have found the error in the tables though! In the
description of the RMRR's under the DMAR the spec says on pg. 75 (in
the description of the device scope under the RMRR):

"The Device Scope structure contains...The
devices identified in this structure must be devices
under the scope of one of the remapping hardware
units reported in _DRHD_."

This was taken from:
http://download.intel.com/technology/computing/vptech/Intel(r)_VT_for_Direct_IO.pdf

However, consider the DeviceScope "-- Device: 0x1d Function: 0x07"
reported under RMRR #2 and of some of the other RMRR's. This device is
not present under any DRHD in the entire DMAR. This seems to be a
violation of the spec. And it makes sense with the error code Hal got,
"device scope of VT-d DMAR ACPI table is invalid"

Best regards,

Martin Thiim

On Thu, Jul 30, 2009 at 11:14 PM, Ross
Philipson<Ros...@ci...> wrote:
> Martin,
>
> The dump utility I gave Hal earlier was reading the ACPI tables and formatting/tracing out the DMAR table from his system. The DMAR is there and on the surface it looked correct to me (at least nothing obviously wrong with it). Hal attached the trace in an earlier reply.
>
> Thanks
> Ross
>
> -----Original Message-----
> From: Martin Thiim [mailto:ma...@th...]
> Sent: Thursday, July 30, 2009 4:07 PM
> To: Hal Finney
> Cc: tbo...@li...
> Subject: Re: [tboot-devel] GETSEC[SENTER] fail on HP dc7800
>
> Hello Hal
>
> I could be wrong, but I think what the "Enable VT-d" option in the
> BIOS really refers to is whether the BIOS should set up the ACPI
> tables related to VT-d.
>
> You could use acpidump to see if those tables contain anything VT-d
> related (DMAR and the like) - the VT-d spec would be helpful for this.
>
> http://download.intel.com/technology/computing/vptech/Intel(r)_VT_for_Direct_IO.pdf
>
> I currently don't have access to my VT-d system so I can't give you a
> table of what it looks like on my machine but perhaps others could.
>
> Best regards,
>
> Martin Thiim
>
> On Thu, Jul 30, 2009 at 7:28 PM, Hal Finney<hal...@gm...> wrote:
>> Hi Shane - I'm not sure what it would do to add these switches, since
>> tboot doesn't get as far as launching the kernel, since it hangs in
>> SENTER. However I can try doing it and then just booting into the
>> kernel, in case I get any error reports about VT-d.
>>
>> Are there any MSRs or other registers I can patch tboot to dump out,
>> to indicate whether VT-d is turned on?
>>
>> My HP dc7800 was one of the very first commercially released systems
>> to support TXT. I bought one as soon as they became available in order
>> to experiment with this technology. It has an E6550 "Conroe" processor
>> with a Q35 "Bearlake" chipset.
>>
>> Hal
>>
>> On Thu, Jul 30, 2009 at 12:24 AM, Shane Wang<sha...@in...> wrote:
>>> Hal,
>>>
>>> If you work with Xen, please try to add "iommu=1 vtd=1" in Xen command line
>>> (i.e. the end of "module /boot/xen.gz ...")
>>> If you work with Linux, please try to add "iommu=on" in the command
>>> line (i.e. the end of "module /boot/vmlinuz-2.6.30 ..."
>>>
>>> PS: do you know which platform HP dc7800 is? *Field or *Dale?
>>> Can you see VTd lsoc (Azalia) WA in BIOS or somewhere?
>>>
>>> Thanks.
>>> Shane
>>>
>>> Hal Finney wrote:
>>>>
>>>> Thanks for the reply, Shane. VT-d is enabled in the BIOS; in fact, the
>>>> BIOS automatically enables VT-d when TXT is enabled.
>>>>
>>>> I don't know of anything I would do in any grub configuration file to
>>>> enable VT-d for tboot and SINIT. Do you have any suggestions?
>>>>
>>>> Hal
>>>>
>>>> On Wed, Jul 29, 2009 at 10:04 PM, Shane Wang<sha...@in...> wrote:
>>>>>
>>>>> Hi Hal
>>>>>
>>>>> The error code means VTd is disabled.
>>>>> Is your VT-d enabled in your new BIOS and grub.conf?
>>>>>
>>>>> Thanks.
>>>>> Shane
>>>>>
>>>>> Hal Finney wrote:
>>>>>>
>>>>>> I haven't run tboot in a while, but I'm trying it on my HP dc7800 and
>>>>>> finding it hangs in GETSEC[SENTER]. This is even true with old
>>>>>> versions of tboot that used to work. My system has no USB ports
>>>>>> plugged in, and no hardware changes.
>>>>>>
>>>>>> The one change is I recently updated my BIOS. I suspect this has to be
>>>>>> the cause. One nice thing about the new BIOS is that the tboot hang
>>>>>> actually reboots the machine with the ERRORCODE register intact. Its
>>>>>> value is c00020a1. This is progress code 0ah, error code 1000,
>>>>>> meaning: "device scope of VT-d DMAR ACPI table is invalid". Not clear
>>>>>> what this means.
>>>>>>
>>>>>> My log is attached, including the hang and the relaunch of tboot. This
>>>>>> is version 20090330 of tboot. Thanks very much -
>>>>>>
>>>>>> Hal Finney
>>>>>
>>>
>>>
>>
>> ------------------------------------------------------------------------------
>> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
>> trial. Simplify your report design, integration and deployment - and focus on
>> what you do best, core application coding. Discover what's new with
>> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
>> _______________________________________________
>> tboot-devel mailing list
>> tbo...@li...
>> https://lists.sourceforge.net/lists/listinfo/tboot-devel
>>
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> tboot-devel mailing list
> tbo...@li...
> https://lists.sourceforge.net/lists/listinfo/tboot-devel
>

Re: [tboot-devel] GETSEC[SENTER] fail on HP dc7800

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

Hal

My fault, since you have no chance to run into Xen or kernel.
I suspect it is the BIOS issue.

I am not sure whether it is convenient for you to downgrade the BIOS and 
have a try.

Shane

Hal Finney wrote:
> Hi Shane - I'm not sure what it would do to add these switches, since
> tboot doesn't get as far as launching the kernel, since it hangs in
> SENTER. However I can try doing it and then just booting into the
> kernel, in case I get any error reports about VT-d.
> 
> Are there any MSRs or other registers I can patch tboot to dump out,
> to indicate whether VT-d is turned on?
> 
> My HP dc7800 was one of the very first commercially released systems
> to support TXT. I bought one as soon as they became available in order
> to experiment with this technology. It has an E6550 "Conroe" processor
> with a Q35 "Bearlake" chipset.
> 
> Hal
> 
> On Thu, Jul 30, 2009 at 12:24 AM, Shane Wang<sha...@in...> wrote:
>> Hal,
>>
>> If you work with Xen, please try to add "iommu=1 vtd=1" in Xen command line
>> (i.e. the end of "module /boot/xen.gz ...")
>> If you work with Linux, please try to add "iommu=on" in the command
>> line (i.e. the end of "module /boot/vmlinuz-2.6.30 ..."
>>
>> PS: do you know which platform HP dc7800 is? *Field or *Dale?
>> Can you see VTd lsoc (Azalia) WA in BIOS or somewhere?
>>
>> Thanks.
>> Shane
>>
>> Hal Finney wrote:
>>> Thanks for the reply, Shane. VT-d is enabled in the BIOS; in fact, the
>>> BIOS automatically enables VT-d when TXT is enabled.
>>>
>>> I don't know of anything I would do in any grub configuration file to
>>> enable VT-d for tboot and SINIT. Do you have any suggestions?
>>>
>>> Hal
>>>
>>> On Wed, Jul 29, 2009 at 10:04 PM, Shane Wang<sha...@in...> wrote:
>>>> Hi Hal
>>>>
>>>> The error code means VTd is disabled.
>>>> Is your VT-d enabled in your new BIOS and grub.conf?
>>>>
>>>> Thanks.
>>>> Shane
>>>>
>>>> Hal Finney wrote:
>>>>> I haven't run tboot in a while, but I'm trying it on my HP dc7800 and
>>>>> finding it hangs in GETSEC[SENTER]. This is even true with old
>>>>> versions of tboot that used to work. My system has no USB ports
>>>>> plugged in, and no hardware changes.
>>>>>
>>>>> The one change is I recently updated my BIOS. I suspect this has to be
>>>>> the cause. One nice thing about the new BIOS is that the tboot hang
>>>>> actually reboots the machine with the ERRORCODE register intact. Its
>>>>> value is c00020a1. This is progress code 0ah, error code 1000,
>>>>> meaning: "device scope of VT-d DMAR ACPI table is invalid". Not clear
>>>>> what this means.
>>>>>
>>>>> My log is attached, including the hang and the relaunch of tboot. This
>>>>> is version 20090330 of tboot. Thanks very much -
>>>>>
>>>>> Hal Finney
>>

Re: [tboot-devel] GETSEC[SENTER] fail on HP dc7800

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

I just want to confirm you don't have Azalia, because Azalia in some old 
bios will enable the Isochronous VT-d table, which causes SINIT fails.

Forget this.

Shane

Hal Finney wrote:
> (Forgot to respond to this last part):
>> Can you see VTd lsoc (Azalia) WA in BIOS or somewhere?
> 
> I'm afraid these terms mean nothing to me. Azalia is something about
> HD Audio? I don't know what that has to do with VT-d. Googling for
> lsoc with VT-d or with Intel finds nothing relevant. And WA could be
> anything. But no, I don't see anything in BIOS about any of this.
> 
> Hal

Re: [tboot-devel] GETSEC[SENTER] fail on HP dc7800

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

Right, you can see my output from Ross's dmardump utility at
http://docs.google.com/View?id=df2b4r7r_1hcbtgbnd

Or here is the binary output of acpidump -t DMAR. BTW you can see the
BEARLAKE chipset ID right there:

DMAR @ 0x3e2c225f
  0000: 44 4d 41 52 98 01 00 00 01 ce 43 4f 4d 50 41 51  DMAR......COMPAQ
  0010: 42 45 41 52 4c 41 4b 45 01 00 00 00 00 00 00 00  BEARLAKE........
  0020: 00 00 00 00 23 00 00 00 00 00 00 00 00 00 00 00  ....#...........
  0030: 00 00 18 00 00 00 00 00 00 00 d9 fe 00 00 00 00  ................
  0040: 01 08 00 00 00 00 1b 00 00 00 18 00 00 00 00 00  ................
  0050: 00 10 d9 fe 00 00 00 00 01 08 00 00 00 00 02 00  ................
  0060: 00 00 28 00 00 00 00 00 00 20 d9 fe 00 00 00 00  ..(...... ......
  0070: 01 08 00 00 00 00 03 00 01 08 00 00 00 00 03 02  ................
  0080: 01 08 00 00 00 00 03 03 00 00 10 00 01 00 00 00  ................
  0090: 00 30 d9 fe 00 00 00 00 01 00 20 00 00 00 00 00  .0........ .....
  00a0: 00 00 60 3e 00 00 00 00 ff ff ff 3e 00 00 00 00  ..`>.......>....
  00b0: 01 08 00 00 00 00 02 00 01 00 20 00 00 00 00 00  .......... .....
  00c0: 00 00 2d 3e 00 00 00 00 ff 0f 2d 3e 00 00 00 00  ..->......->....
  00d0: 01 08 00 00 00 00 1d 07 01 00 20 00 00 00 00 00  .......... .....
  00e0: 00 10 2d 3e 00 00 00 00 ff 1f 2d 3e 00 00 00 00  ..->......->....
  00f0: 01 08 00 00 00 00 1a 07 01 00 20 00 00 00 00 00  .......... .....
  0100: 00 20 2d 3e 00 00 00 00 ff 2f 2d 3e 00 00 00 00  . ->...../->....
  0110: 01 08 00 00 00 00 1d 00 01 00 20 00 00 00 00 00  .......... .....
  0120: 00 30 2d 3e 00 00 00 00 ff 3f 2d 3e 00 00 00 00  .0->.....?->....
  0130: 01 08 00 00 00 00 1d 01 01 00 20 00 00 00 00 00  .......... .....
  0140: 00 40 2d 3e 00 00 00 00 ff 4f 2d 3e 00 00 00 00  .@->.....O->....
  0150: 01 08 00 00 00 00 1d 02 01 00 20 00 00 00 00 00  .......... .....
  0160: 00 50 2d 3e 00 00 00 00 ff 5f 2d 3e 00 00 00 00  .P->....._->....
  0170: 01 08 00 00 00 00 1a 00 01 00 20 00 00 00 00 00  .......... .....
  0180: 00 60 2d 3e 00 00 00 00 ff 6f 2d 3e 00 00 00 00  .`->.....o->....
  0190: 01 08 00 00 00 00 1a 01                          ........

Comparing with the VT-d spec, it looks pretty reasonable to me. But I
may be missing some details. There must be something about it that
SINIT doesn't like.

Hal

On Thu, Jul 30, 2009 at 2:14 PM, Ross
Philipson<Ros...@ci...> wrote:
> Martin,
>
> The dump utility I gave Hal earlier was reading the ACPI tables and formatting/tracing out the DMAR table from his system. The DMAR is there and on the surface it looked correct to me (at least nothing obviously wrong with it). Hal attached the trace in an earlier reply.
>
> Thanks
> Ross
>
> -----Original Message-----
> From: Martin Thiim [mailto:ma...@th...]
> Sent: Thursday, July 30, 2009 4:07 PM
> To: Hal Finney
> Cc: tbo...@li...
> Subject: Re: [tboot-devel] GETSEC[SENTER] fail on HP dc7800
>
> Hello Hal
>
> I could be wrong, but I think what the "Enable VT-d" option in the
> BIOS really refers to is whether the BIOS should set up the ACPI
> tables related to VT-d.
>
> You could use acpidump to see if those tables contain anything VT-d
> related (DMAR and the like) - the VT-d spec would be helpful for this.
>
> http://download.intel.com/technology/computing/vptech/Intel(r)_VT_for_Direct_IO.pdf
>
> I currently don't have access to my VT-d system so I can't give you a
> table of what it looks like on my machine but perhaps others could.
>
> Best regards,
>
> Martin Thiim
>
> On Thu, Jul 30, 2009 at 7:28 PM, Hal Finney<hal...@gm...> wrote:
>> Hi Shane - I'm not sure what it would do to add these switches, since
>> tboot doesn't get as far as launching the kernel, since it hangs in
>> SENTER. However I can try doing it and then just booting into the
>> kernel, in case I get any error reports about VT-d.
>>
>> Are there any MSRs or other registers I can patch tboot to dump out,
>> to indicate whether VT-d is turned on?
>>
>> My HP dc7800 was one of the very first commercially released systems
>> to support TXT. I bought one as soon as they became available in order
>> to experiment with this technology. It has an E6550 "Conroe" processor
>> with a Q35 "Bearlake" chipset.
>>
>> Hal
>>
>> On Thu, Jul 30, 2009 at 12:24 AM, Shane Wang<sha...@in...> wrote:
>>> Hal,
>>>
>>> If you work with Xen, please try to add "iommu=1 vtd=1" in Xen command line
>>> (i.e. the end of "module /boot/xen.gz ...")
>>> If you work with Linux, please try to add "iommu=on" in the command
>>> line (i.e. the end of "module /boot/vmlinuz-2.6.30 ..."
>>>
>>> PS: do you know which platform HP dc7800 is? *Field or *Dale?
>>> Can you see VTd lsoc (Azalia) WA in BIOS or somewhere?
>>>
>>> Thanks.
>>> Shane
>>>
>>> Hal Finney wrote:
>>>>
>>>> Thanks for the reply, Shane. VT-d is enabled in the BIOS; in fact, the
>>>> BIOS automatically enables VT-d when TXT is enabled.
>>>>
>>>> I don't know of anything I would do in any grub configuration file to
>>>> enable VT-d for tboot and SINIT. Do you have any suggestions?
>>>>
>>>> Hal
>>>>
>>>> On Wed, Jul 29, 2009 at 10:04 PM, Shane Wang<sha...@in...> wrote:
>>>>>
>>>>> Hi Hal
>>>>>
>>>>> The error code means VTd is disabled.
>>>>> Is your VT-d enabled in your new BIOS and grub.conf?
>>>>>
>>>>> Thanks.
>>>>> Shane
>>>>>
>>>>> Hal Finney wrote:
>>>>>>
>>>>>> I haven't run tboot in a while, but I'm trying it on my HP dc7800 and
>>>>>> finding it hangs in GETSEC[SENTER]. This is even true with old
>>>>>> versions of tboot that used to work. My system has no USB ports
>>>>>> plugged in, and no hardware changes.
>>>>>>
>>>>>> The one change is I recently updated my BIOS. I suspect this has to be
>>>>>> the cause. One nice thing about the new BIOS is that the tboot hang
>>>>>> actually reboots the machine with the ERRORCODE register intact. Its
>>>>>> value is c00020a1. This is progress code 0ah, error code 1000,
>>>>>> meaning: "device scope of VT-d DMAR ACPI table is invalid". Not clear
>>>>>> what this means.
>>>>>>
>>>>>> My log is attached, including the hang and the relaunch of tboot. This
>>>>>> is version 20090330 of tboot. Thanks very much -
>>>>>>
>>>>>> Hal Finney
>>>>>
>>>
>>>
>>
>> ------------------------------------------------------------------------------
>> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
>> trial. Simplify your report design, integration and deployment - and focus on
>> what you do best, core application coding. Discover what's new with
>> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
>> _______________________________________________
>> tboot-devel mailing list
>> tbo...@li...
>> https://lists.sourceforge.net/lists/listinfo/tboot-devel
>>
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> tboot-devel mailing list
> tbo...@li...
> https://lists.sourceforge.net/lists/listinfo/tboot-devel
>

Re: [tboot-devel] GETSEC[SENTER] fail on HP dc7800

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

Martin,

The dump utility I gave Hal earlier was reading the ACPI tables and formatting/tracing out the DMAR table from his system. The DMAR is there and on the surface it looked correct to me (at least nothing obviously wrong with it). Hal attached the trace in an earlier reply.

Thanks
Ross

-----Original Message-----
From: Martin Thiim [mailto:ma...@th...] 
Sent: Thursday, July 30, 2009 4:07 PM
To: Hal Finney
Cc: tbo...@li...
Subject: Re: [tboot-devel] GETSEC[SENTER] fail on HP dc7800

Hello Hal

I could be wrong, but I think what the "Enable VT-d" option in the
BIOS really refers to is whether the BIOS should set up the ACPI
tables related to VT-d.

You could use acpidump to see if those tables contain anything VT-d
related (DMAR and the like) - the VT-d spec would be helpful for this.

http://download.intel.com/technology/computing/vptech/Intel(r)_VT_for_Direct_IO.pdf

I currently don't have access to my VT-d system so I can't give you a
table of what it looks like on my machine but perhaps others could.

Best regards,

Martin Thiim

On Thu, Jul 30, 2009 at 7:28 PM, Hal Finney<hal...@gm...> wrote:
> Hi Shane - I'm not sure what it would do to add these switches, since
> tboot doesn't get as far as launching the kernel, since it hangs in
> SENTER. However I can try doing it and then just booting into the
> kernel, in case I get any error reports about VT-d.
>
> Are there any MSRs or other registers I can patch tboot to dump out,
> to indicate whether VT-d is turned on?
>
> My HP dc7800 was one of the very first commercially released systems
> to support TXT. I bought one as soon as they became available in order
> to experiment with this technology. It has an E6550 "Conroe" processor
> with a Q35 "Bearlake" chipset.
>
> Hal
>
> On Thu, Jul 30, 2009 at 12:24 AM, Shane Wang<sha...@in...> wrote:
>> Hal,
>>
>> If you work with Xen, please try to add "iommu=1 vtd=1" in Xen command line
>> (i.e. the end of "module /boot/xen.gz ...")
>> If you work with Linux, please try to add "iommu=on" in the command
>> line (i.e. the end of "module /boot/vmlinuz-2.6.30 ..."
>>
>> PS: do you know which platform HP dc7800 is? *Field or *Dale?
>> Can you see VTd lsoc (Azalia) WA in BIOS or somewhere?
>>
>> Thanks.
>> Shane
>>
>> Hal Finney wrote:
>>>
>>> Thanks for the reply, Shane. VT-d is enabled in the BIOS; in fact, the
>>> BIOS automatically enables VT-d when TXT is enabled.
>>>
>>> I don't know of anything I would do in any grub configuration file to
>>> enable VT-d for tboot and SINIT. Do you have any suggestions?
>>>
>>> Hal
>>>
>>> On Wed, Jul 29, 2009 at 10:04 PM, Shane Wang<sha...@in...> wrote:
>>>>
>>>> Hi Hal
>>>>
>>>> The error code means VTd is disabled.
>>>> Is your VT-d enabled in your new BIOS and grub.conf?
>>>>
>>>> Thanks.
>>>> Shane
>>>>
>>>> Hal Finney wrote:
>>>>>
>>>>> I haven't run tboot in a while, but I'm trying it on my HP dc7800 and
>>>>> finding it hangs in GETSEC[SENTER]. This is even true with old
>>>>> versions of tboot that used to work. My system has no USB ports
>>>>> plugged in, and no hardware changes.
>>>>>
>>>>> The one change is I recently updated my BIOS. I suspect this has to be
>>>>> the cause. One nice thing about the new BIOS is that the tboot hang
>>>>> actually reboots the machine with the ERRORCODE register intact. Its
>>>>> value is c00020a1. This is progress code 0ah, error code 1000,
>>>>> meaning: "device scope of VT-d DMAR ACPI table is invalid". Not clear
>>>>> what this means.
>>>>>
>>>>> My log is attached, including the hang and the relaunch of tboot. This
>>>>> is version 20090330 of tboot. Thanks very much -
>>>>>
>>>>> Hal Finney
>>>>
>>
>>
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> tboot-devel mailing list
> tbo...@li...
> https://lists.sourceforge.net/lists/listinfo/tboot-devel
>

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
tboot-devel mailing list
tbo...@li...
https://lists.sourceforge.net/lists/listinfo/tboot-devel

Re: [tboot-devel] GETSEC[SENTER] fail on HP dc7800

[Martin T. <ma...@th...>]

Hello Hal

I could be wrong, but I think what the "Enable VT-d" option in the
BIOS really refers to is whether the BIOS should set up the ACPI
tables related to VT-d.

You could use acpidump to see if those tables contain anything VT-d
related (DMAR and the like) - the VT-d spec would be helpful for this.

http://download.intel.com/technology/computing/vptech/Intel(r)_VT_for_Direct_IO.pdf

I currently don't have access to my VT-d system so I can't give you a
table of what it looks like on my machine but perhaps others could.

Best regards,

Martin Thiim

On Thu, Jul 30, 2009 at 7:28 PM, Hal Finney<hal...@gm...> wrote:
> Hi Shane - I'm not sure what it would do to add these switches, since
> tboot doesn't get as far as launching the kernel, since it hangs in
> SENTER. However I can try doing it and then just booting into the
> kernel, in case I get any error reports about VT-d.
>
> Are there any MSRs or other registers I can patch tboot to dump out,
> to indicate whether VT-d is turned on?
>
> My HP dc7800 was one of the very first commercially released systems
> to support TXT. I bought one as soon as they became available in order
> to experiment with this technology. It has an E6550 "Conroe" processor
> with a Q35 "Bearlake" chipset.
>
> Hal
>
> On Thu, Jul 30, 2009 at 12:24 AM, Shane Wang<sha...@in...> wrote:
>> Hal,
>>
>> If you work with Xen, please try to add "iommu=1 vtd=1" in Xen command line
>> (i.e. the end of "module /boot/xen.gz ...")
>> If you work with Linux, please try to add "iommu=on" in the command
>> line (i.e. the end of "module /boot/vmlinuz-2.6.30 ..."
>>
>> PS: do you know which platform HP dc7800 is? *Field or *Dale?
>> Can you see VTd lsoc (Azalia) WA in BIOS or somewhere?
>>
>> Thanks.
>> Shane
>>
>> Hal Finney wrote:
>>>
>>> Thanks for the reply, Shane. VT-d is enabled in the BIOS; in fact, the
>>> BIOS automatically enables VT-d when TXT is enabled.
>>>
>>> I don't know of anything I would do in any grub configuration file to
>>> enable VT-d for tboot and SINIT. Do you have any suggestions?
>>>
>>> Hal
>>>
>>> On Wed, Jul 29, 2009 at 10:04 PM, Shane Wang<sha...@in...> wrote:
>>>>
>>>> Hi Hal
>>>>
>>>> The error code means VTd is disabled.
>>>> Is your VT-d enabled in your new BIOS and grub.conf?
>>>>
>>>> Thanks.
>>>> Shane
>>>>
>>>> Hal Finney wrote:
>>>>>
>>>>> I haven't run tboot in a while, but I'm trying it on my HP dc7800 and
>>>>> finding it hangs in GETSEC[SENTER]. This is even true with old
>>>>> versions of tboot that used to work. My system has no USB ports
>>>>> plugged in, and no hardware changes.
>>>>>
>>>>> The one change is I recently updated my BIOS. I suspect this has to be
>>>>> the cause. One nice thing about the new BIOS is that the tboot hang
>>>>> actually reboots the machine with the ERRORCODE register intact. Its
>>>>> value is c00020a1. This is progress code 0ah, error code 1000,
>>>>> meaning: "device scope of VT-d DMAR ACPI table is invalid". Not clear
>>>>> what this means.
>>>>>
>>>>> My log is attached, including the hang and the relaunch of tboot. This
>>>>> is version 20090330 of tboot. Thanks very much -
>>>>>
>>>>> Hal Finney
>>>>
>>
>>
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> tboot-devel mailing list
> tbo...@li...
> https://lists.sourceforge.net/lists/listinfo/tboot-devel
>

[tboot-devel] build issues on Ubuntu 8.10

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

Hello,

I grabbed the latest tboot using:

hg clone http://www.bughost.org/repos.hg/tboot.hg

In trying to build it, I get the following error:

mlehash.c:270: error: ignoring return value of ‘fwrite’, declared 
with attribute warn_unused_result

# gcc -v
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 
4.3.2-1ubuntu12' --with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs 
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr 
--enable-shared --with-system-zlib --libexecdir=/usr/lib 
--without-included-gettext --enable-threads=posix --enable-nls 
--with-gxx-include-dir=/usr/include/c++/4.3 --program-suffix=-4.3 
--enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc 
--enable-mpfr --enable-targets=all --enable-checking=release 
--build=i486-linux-gnu --host=i486-linux-gnu --target=i486-linux-gnu
Thread model: posix
gcc version 4.3.2 (Ubuntu 4.3.2-1ubuntu12)


I believe something like this would be more appropriate:


         if( fwrite(tmpbuffer, 1, i, fdecompressed) != i )
             goto error;

Though I haven't tested it yet.

-Jon

Re: [tboot-devel] GETSEC[SENTER] fail on HP dc7800

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

(Forgot to respond to this last part):
> Can you see VTd lsoc (Azalia) WA in BIOS or somewhere?

I'm afraid these terms mean nothing to me. Azalia is something about
HD Audio? I don't know what that has to do with VT-d. Googling for
lsoc with VT-d or with Intel finds nothing relevant. And WA could be
anything. But no, I don't see anything in BIOS about any of this.

Hal

Re: [tboot-devel] GETSEC[SENTER] fail on HP dc7800

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

Hi Shane - I'm not sure what it would do to add these switches, since
tboot doesn't get as far as launching the kernel, since it hangs in
SENTER. However I can try doing it and then just booting into the
kernel, in case I get any error reports about VT-d.

Are there any MSRs or other registers I can patch tboot to dump out,
to indicate whether VT-d is turned on?

My HP dc7800 was one of the very first commercially released systems
to support TXT. I bought one as soon as they became available in order
to experiment with this technology. It has an E6550 "Conroe" processor
with a Q35 "Bearlake" chipset.

Hal

On Thu, Jul 30, 2009 at 12:24 AM, Shane Wang<sha...@in...> wrote:
> Hal,
>
> If you work with Xen, please try to add "iommu=1 vtd=1" in Xen command line
> (i.e. the end of "module /boot/xen.gz ...")
> If you work with Linux, please try to add "iommu=on" in the command
> line (i.e. the end of "module /boot/vmlinuz-2.6.30 ..."
>
> PS: do you know which platform HP dc7800 is? *Field or *Dale?
> Can you see VTd lsoc (Azalia) WA in BIOS or somewhere?
>
> Thanks.
> Shane
>
> Hal Finney wrote:
>>
>> Thanks for the reply, Shane. VT-d is enabled in the BIOS; in fact, the
>> BIOS automatically enables VT-d when TXT is enabled.
>>
>> I don't know of anything I would do in any grub configuration file to
>> enable VT-d for tboot and SINIT. Do you have any suggestions?
>>
>> Hal
>>
>> On Wed, Jul 29, 2009 at 10:04 PM, Shane Wang<sha...@in...> wrote:
>>>
>>> Hi Hal
>>>
>>> The error code means VTd is disabled.
>>> Is your VT-d enabled in your new BIOS and grub.conf?
>>>
>>> Thanks.
>>> Shane
>>>
>>> Hal Finney wrote:
>>>>
>>>> I haven't run tboot in a while, but I'm trying it on my HP dc7800 and
>>>> finding it hangs in GETSEC[SENTER]. This is even true with old
>>>> versions of tboot that used to work. My system has no USB ports
>>>> plugged in, and no hardware changes.
>>>>
>>>> The one change is I recently updated my BIOS. I suspect this has to be
>>>> the cause. One nice thing about the new BIOS is that the tboot hang
>>>> actually reboots the machine with the ERRORCODE register intact. Its
>>>> value is c00020a1. This is progress code 0ah, error code 1000,
>>>> meaning: "device scope of VT-d DMAR ACPI table is invalid". Not clear
>>>> what this means.
>>>>
>>>> My log is attached, including the hang and the relaunch of tboot. This
>>>> is version 20090330 of tboot. Thanks very much -
>>>>
>>>> Hal Finney
>>>
>
>

Re: [tboot-devel] [PATCH] TSS_RESULT not checked in lcptools.c

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

I'm sorry, my Patch of lcptools.c wasn't proper. I found more missing checks, here's my next try.

greetz Michael



diff --git a/lcptools/lcptools.c b/lcptools/lcptools.c
--- a/lcptools/lcptools.c
+++ b/lcptools/lcptools.c
@@ -90,7 +90,7 @@
      CHECK_TSS_RETURN_VALUE("init_tss_context", result, ret);

      if ( passwd != NULL ) {
-        set_tpm_secret(hcontext, &htpm, &hpolicy, passwd, passwd_length);
+        result = set_tpm_secret(hcontext, &htpm, &hpolicy, passwd, passwd_length);
          CHECK_TSS_RETURN_VALUE("set_tpm_secret", result, ret);
      }

@@ -105,7 +105,7 @@
       * if the nv object need authentication
       */
      if ( auth != NULL ) {
-        set_nv_secret(hcontext, hnvstore, &hpolobj, auth, auth_length);
+        result = set_nv_secret(hcontext, hnvstore, &hpolobj, auth, auth_length);
          CHECK_TSS_RETURN_VALUE("set_nv_secret", result, ret);
      }

@@ -153,6 +153,7 @@
                  result, ret);

          result = Tspi_NV_DefineSpace(hnvstore, 0, hwrtpcrcomp);
+        CHECK_TSS_RETURN_VALUE("Tspi_NV_DefineSpace failed", result, ret);
      } else {
          /*
           * Set the locality number.
@@ -253,7 +254,7 @@


      if ( passwd != NULL ) {
-        set_tpm_secret(hcontext, &htpm, &hpolicy, passwd, passwd_length);
+        result = set_tpm_secret(hcontext, &htpm, &hpolicy, passwd, passwd_length);
          CHECK_TSS_RETURN_VALUE("set_tpm_secret", result, ret);
      }

@@ -343,7 +344,7 @@
              result, ret);

      if ( password != NULL ) {
-        set_nv_secret(hcontext, hnvstore, &hnvpol, password, pwd_length);
+        result = set_nv_secret(hcontext, hnvstore, &hnvpol, password, pwd_length);
          CHECK_TSS_RETURN_VALUE("set_nv_secret", result, ret);
      }

@@ -446,7 +447,7 @@
              result, ret);

      if ( password != NULL ) {
-        set_nv_secret(hcontext, hnvstore, &hnvpol, password, pwd_length);
+        result = set_nv_secret(hcontext, hnvstore, &hnvpol, password, pwd_length);
          CHECK_TSS_RETURN_VALUE("set_nv_secret", result, ret);
      }

@@ -956,7 +957,7 @@


      if ( password != NULL ) {
-        set_tpm_secret(hcontext, &htpm, &hpolicy, password, passwd_length);
+        result = set_tpm_secret(hcontext, &htpm, &hpolicy, password, passwd_length);
          CHECK_TSS_RETURN_VALUE("set_tpm_secret", result, ret);
      }
      else {

Re: [tboot-devel] GETSEC[SENTER] fail on HP dc7800

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

Hal,

If you work with Xen, please try to add "iommu=1 vtd=1" in Xen command 
line (i.e. the end of "module /boot/xen.gz ...")
If you work with Linux, please try to add "iommu=on" in the command
line (i.e. the end of "module /boot/vmlinuz-2.6.30 ..."

PS: do you know which platform HP dc7800 is? *Field or *Dale?
Can you see VTd lsoc (Azalia) WA in BIOS or somewhere?

Thanks.
Shane

Hal Finney wrote:
> Thanks for the reply, Shane. VT-d is enabled in the BIOS; in fact, the
> BIOS automatically enables VT-d when TXT is enabled.
> 
> I don't know of anything I would do in any grub configuration file to
> enable VT-d for tboot and SINIT. Do you have any suggestions?
> 
> Hal
> 
> On Wed, Jul 29, 2009 at 10:04 PM, Shane Wang<sha...@in...> wrote:
>> Hi Hal
>>
>> The error code means VTd is disabled.
>> Is your VT-d enabled in your new BIOS and grub.conf?
>>
>> Thanks.
>> Shane
>>
>> Hal Finney wrote:
>>> I haven't run tboot in a while, but I'm trying it on my HP dc7800 and
>>> finding it hangs in GETSEC[SENTER]. This is even true with old
>>> versions of tboot that used to work. My system has no USB ports
>>> plugged in, and no hardware changes.
>>>
>>> The one change is I recently updated my BIOS. I suspect this has to be
>>> the cause. One nice thing about the new BIOS is that the tboot hang
>>> actually reboots the machine with the ERRORCODE register intact. Its
>>> value is c00020a1. This is progress code 0ah, error code 1000,
>>> meaning: "device scope of VT-d DMAR ACPI table is invalid". Not clear
>>> what this means.
>>>
>>> My log is attached, including the hang and the relaunch of tboot. This
>>> is version 20090330 of tboot. Thanks very much -
>>>
>>> Hal Finney
>>

Re: [tboot-devel] GETSEC[SENTER] fail on HP dc7800

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

Thanks for the reply, Shane. VT-d is enabled in the BIOS; in fact, the
BIOS automatically enables VT-d when TXT is enabled.

I don't know of anything I would do in any grub configuration file to
enable VT-d for tboot and SINIT. Do you have any suggestions?

Hal

On Wed, Jul 29, 2009 at 10:04 PM, Shane Wang<sha...@in...> wrote:
> Hi Hal
>
> The error code means VTd is disabled.
> Is your VT-d enabled in your new BIOS and grub.conf?
>
> Thanks.
> Shane
>
> Hal Finney wrote:
>>
>> I haven't run tboot in a while, but I'm trying it on my HP dc7800 and
>> finding it hangs in GETSEC[SENTER]. This is even true with old
>> versions of tboot that used to work. My system has no USB ports
>> plugged in, and no hardware changes.
>>
>> The one change is I recently updated my BIOS. I suspect this has to be
>> the cause. One nice thing about the new BIOS is that the tboot hang
>> actually reboots the machine with the ERRORCODE register intact. Its
>> value is c00020a1. This is progress code 0ah, error code 1000,
>> meaning: "device scope of VT-d DMAR ACPI table is invalid". Not clear
>> what this means.
>>
>> My log is attached, including the hang and the relaunch of tboot. This
>> is version 20090330 of tboot. Thanks very much -
>>
>> Hal Finney
>
>

Re: [tboot-devel] GETSEC[SENTER] fail on HP dc7800

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

Hi Hal

The error code means VTd is disabled.
Is your VT-d enabled in your new BIOS and grub.conf?

Thanks.
Shane

Hal Finney wrote:
> I haven't run tboot in a while, but I'm trying it on my HP dc7800 and
> finding it hangs in GETSEC[SENTER]. This is even true with old
> versions of tboot that used to work. My system has no USB ports
> plugged in, and no hardware changes.
> 
> The one change is I recently updated my BIOS. I suspect this has to be
> the cause. One nice thing about the new BIOS is that the tboot hang
> actually reboots the machine with the ERRORCODE register intact. Its
> value is c00020a1. This is progress code 0ah, error code 1000,
> meaning: "device scope of VT-d DMAR ACPI table is invalid". Not clear
> what this means.
> 
> My log is attached, including the hang and the relaunch of tboot. This
> is version 20090330 of tboot. Thanks very much -
> 
> Hal Finney

Re: [tboot-devel] GETSEC[SENTER] fail on HP dc7800

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

Hmm, nothing jumps out at me as to what is not correct. I guess that is a Intel Q35 (or similar) desktop system you have. The DHRD tables look like the ones I would expect from what I have seen with other Intel chipsets. The RMRR values also look reasonable for the iGfx and USB devices. The last time someone reported a similar problem on one of the lists it turned out their BIOS was missing the DHRD with the INCLUDE_ALL flag set but this looks OK in your case. Maybe someone else on the list might see something amiss with the DMAR.

Thanks
Ross

-----Original Message-----
From: Hal Finney [mailto:hal...@gm...] 
Sent: Wednesday, July 29, 2009 12:36 PM
To: Ross Philipson
Cc: tbo...@li...
Subject: Re: [tboot-devel] GETSEC[SENTER] fail on HP dc7800

Hi Ross, thanks very much for that. I have attached the output from my dc7800.

Hal

On Wed, Jul 29, 2009 at 7:40 AM, Ross
Philipson<Ros...@ci...> wrote:
> Hal,
>
> I attached a little utility I wrote to dump the DMAR tables from ACPI. If you run it and post the output it might show what TXT thinks is wrong with DMAR. You will have to build and run it on linux.
>
> Thanks
> Ross
>
> -----Original Message-----
> From: Hal Finney [mailto:hal...@gm...]
> Sent: Tuesday, July 28, 2009 7:33 PM
> To: tbo...@li...
> Subject: [tboot-devel] GETSEC[SENTER] fail on HP dc7800
>
> I haven't run tboot in a while, but I'm trying it on my HP dc7800 and finding it hangs in GETSEC[SENTER]. This is even true with old versions of tboot that used to work. My system has no USB ports plugged in, and no hardware changes.
>
> The one change is I recently updated my BIOS. I suspect this has to be the cause. One nice thing about the new BIOS is that the tboot hang actually reboots the machine with the ERRORCODE register intact. Its value is c00020a1. This is progress code 0ah, error code 1000,
> meaning: "device scope of VT-d DMAR ACPI table is invalid". Not clear what this means.
>
> My log is attached, including the hang and the relaunch of tboot. This is version 20090330 of tboot. Thanks very much -
>
> Hal Finney
>

Re: [tboot-devel] GETSEC[SENTER] fail on HP dc7800

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

Hi Ross, thanks very much for that. I have attached the output from my dc7800.

Hal

On Wed, Jul 29, 2009 at 7:40 AM, Ross
Philipson<Ros...@ci...> wrote:
> Hal,
>
> I attached a little utility I wrote to dump the DMAR tables from ACPI. If you run it and post the output it might show what TXT thinks is wrong with DMAR. You will have to build and run it on linux.
>
> Thanks
> Ross
>
> -----Original Message-----
> From: Hal Finney [mailto:hal...@gm...]
> Sent: Tuesday, July 28, 2009 7:33 PM
> To: tbo...@li...
> Subject: [tboot-devel] GETSEC[SENTER] fail on HP dc7800
>
> I haven't run tboot in a while, but I'm trying it on my HP dc7800 and finding it hangs in GETSEC[SENTER]. This is even true with old versions of tboot that used to work. My system has no USB ports plugged in, and no hardware changes.
>
> The one change is I recently updated my BIOS. I suspect this has to be the cause. One nice thing about the new BIOS is that the tboot hang actually reboots the machine with the ERRORCODE register intact. Its value is c00020a1. This is progress code 0ah, error code 1000,
> meaning: "device scope of VT-d DMAR ACPI table is invalid". Not clear what this means.
>
> My log is attached, including the hang and the relaunch of tboot. This is version 20090330 of tboot. Thanks very much -
>
> Hal Finney
>

Re: [tboot-devel] GETSEC[SENTER] fail on HP dc7800

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

Hal,

I attached a little utility I wrote to dump the DMAR tables from ACPI. If you run it and post the output it might show what TXT thinks is wrong with DMAR. You will have to build and run it on linux.

Thanks
Ross

-----Original Message-----
From: Hal Finney [mailto:hal...@gm...] 
Sent: Tuesday, July 28, 2009 7:33 PM
To: tbo...@li...
Subject: [tboot-devel] GETSEC[SENTER] fail on HP dc7800

I haven't run tboot in a while, but I'm trying it on my HP dc7800 and finding it hangs in GETSEC[SENTER]. This is even true with old versions of tboot that used to work. My system has no USB ports plugged in, and no hardware changes.

The one change is I recently updated my BIOS. I suspect this has to be the cause. One nice thing about the new BIOS is that the tboot hang actually reboots the machine with the ERRORCODE register intact. Its value is c00020a1. This is progress code 0ah, error code 1000,
meaning: "device scope of VT-d DMAR ACPI table is invalid". Not clear what this means.

My log is attached, including the hang and the relaunch of tboot. This is version 20090330 of tboot. Thanks very much -

Hal Finney

[tboot-devel] [PATCH] TSS_RESULT not checked in lcptools.c

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

greetz Michael

diff --git a/lcptools/lcptools.c b/lcptools/lcptools.c
--- a/lcptools/lcptools.c
+++ b/lcptools/lcptools.c
@@ -105,7 +105,7 @@
       * if the nv object need authentication
       */
      if ( auth != NULL ) {
-        set_nv_secret(hcontext, hnvstore, &hpolobj, auth, auth_length);
+        result = set_nv_secret(hcontext, hnvstore, &hpolobj, auth, auth_length);
          CHECK_TSS_RETURN_VALUE("set_nv_secret", result, ret);
      }

[tboot-devel] GETSEC[SENTER] fail on HP dc7800

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

I haven't run tboot in a while, but I'm trying it on my HP dc7800 and
finding it hangs in GETSEC[SENTER]. This is even true with old
versions of tboot that used to work. My system has no USB ports
plugged in, and no hardware changes.

The one change is I recently updated my BIOS. I suspect this has to be
the cause. One nice thing about the new BIOS is that the tboot hang
actually reboots the machine with the ERRORCODE register intact. Its
value is c00020a1. This is progress code 0ah, error code 1000,
meaning: "device scope of VT-d DMAR ACPI table is invalid". Not clear
what this means.

My log is attached, including the hang and the relaunch of tboot. This
is version 20090330 of tboot. Thanks very much -

Hal Finney

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

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

Sorry for the confusion here, just missed the e (willingly or subconscious, who knows :))
Of course I meant Flicker.

It reads as if it would include shared libraries.
And certainly they need to address this issue some way or another.
However, for my understanding the manifest is a payload in the applications header, which contains a signed list of integrity values of the applications data and code.

It further states in http://www.ddj.com/mobile/218401423?pgno=3 :
"If there are relocation symbols in the application (for example, a dynamically loadable library) then those are captured in the manifest to aid in runtime measurement."

So I assume you need a DLL which in itself has a manifest.
But I suspect that this potentially could would snowball until almost the whole OS is "sucked" into the p-map environment.

Maybe someone with better knowledge of the project could clarify here?

Also, I was wondering if there is any isolation of simultaneously running protected applications?
Assuming any developer could deliver an application and or library with a manifest, a malicious and a protected application would potentially run in the same "protected" environment! Well and the consequences are obvious..

cheers
lIl


-------- Original-Nachricht --------
> Datum: Wed, 22 Jul 2009 10:28:37 -0700
> Von: Hal Finney <hal...@gm...>
> An: Lil Evil <Lil...@gm...>
> CC: tbo...@li...
> Betreff: Re: [tboot-devel] Intel\'s P-MAPS research project

> On Tue, Jul 21, 2009 at 6:20 AM, Lil Evil<Lil...@gm...> wrote:
> > There are many different projects with similar goals out there:
> > BitVisor(sourcecode available somewhere) or Daonity and of course
> flickr, probably more that I am not aware of.
> > They all seem to target a particular use case and scenario.
> >
> > Cutting out Operating System is certainly an elegant and interesting
> solution. However, I think in its current form and function it is limited.
> > You cannot use shared libraries and there is still the issue with the
> trusted graphics to be solved.
> >
> > Just some thoughts ....
> > lIl
> 
> Hi Lil, thank you for the pointers to those other projects, I will
> look at them more. I was a little confused about the mention of
> flickr, the photo sharing site, not where you'd expect to find the
> cutting edge of hypervisor research. But then I realized you meant Jon
> McCune's Flicker, which I agree is a very advanced implementation
> along these lines.
> 
> I have the impression that P-MAPS can handle shared libraries. Reading
> some of the older papers by the same author(s), which used a variety
> of technologies to provide "ring -1" protection to application data,
> there is discussion of a signed "manifest" which describes what should
> be in an executable, and which includes relocation information
> necessary because the dynamic loader will move things around in
> memory. I think this would be specific to shared libraries, but I'm
> not sure.
> 
> Unfortunately it appears that the Intel research blog site I linked to
> is kind of inactive, with no posts or updates for a month. Comments
> have to be approved; mine hasn't appeared after more than a week, and
> in fact no comments have been approved for the past month. Maybe the
> site administrator is on vacation, or maybe all of Intel shuts down
> during July? :)
> 
> Hal
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> tboot-devel mailing list
> tbo...@li...
> https://lists.sourceforge.net/lists/listinfo/tboot-devel

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

Re: [tboot-devel] SINIT module license

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

The new license for SINIT allows to _redistribute_ in binary form 
without modification.

To make SINIT to be part of firmware, I think it will meet the upgrade 
problem. The upgrade of firmware is rare and not so easy for users.

Thanks.
Shane

Jonathan M. McCune wrote:
> Is it not also the case that the long-term plan is for the module 
> specific to a particular system to be included with that system as part 
> of its firmware?  I.e., code that wants to use TXT can just read the 
> appropriate module out of a well-known memory location?
> 
> If this is the case, then it solves the distribution problem, at least 
> in the long run.
> 
> Thanks,
> -Jon
> 
> 
> 
> Shane Wang wrote:
>> Yes, you are right.
>>
>> Shane
>>
>> Martin Pirker wrote:
>>> Reading the "Intel Software License Agreement" packaged along
>>> with the SINIT binaries, I would interpret it that it is not
>>> allowed to distribute the SINIT modules.
>>> Rather, every user who wants to do a TXT boot needs to
>>> download and install the SINIT binaries by himself.
>>>
>>> Is my reading correct?
>>>
>>> Martin
>>>
>>> ------------------------------------------------------------------------------
>>> _______________________________________________
>>> tboot-devel mailing list
>>> tbo...@li...
>>> https://lists.sourceforge.net/lists/listinfo/tboot-devel
>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> tboot-devel mailing list
>> tbo...@li...
>> https://lists.sourceforge.net/lists/listinfo/tboot-devel
>>
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> tboot-devel mailing list
> tbo...@li...
> https://lists.sourceforge.net/lists/listinfo/tboot-devel