tboot-devel — Developer support

Re: [tboot-devel] new release of tboot and SINIT AC modules

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

>> I cannot find the "Developer guide" at
>>  http://www.intel.com/technology/security/. Perhaps it is not ready
>>  yet??
>>
>
> ah, it is still under the old name "Intel(R) Trusted Execution
> Technology Preliminary Architecture Specification"

Yes, sorry about that.  I've already asked that the link be fixed.

Joe

-----Original Message-----
From: Jun Koi [mailto:jun...@gm...] 
Sent: Sunday, June 15, 2008 7:03 PM
To: Cihula, Joseph
Cc: tbo...@li...
Subject: Re: [tboot-devel] new release of tboot and SINIT AC modules

On 6/16/08, Jun Koi <jun...@gm...> wrote:
> On 6/14/08, Cihula, Joseph <jos...@in...> wrote:
>  > I have just checked in a new release of the tboot project.  The
changes
>  >  are quite significant and numerous:
>  >         Removed support for Technology Enabling Platform (TEP)
>  >         Removed support for SINIT AC module versions <16 (i.e. <=
>  >  20070910)
>  >         Updated per changes in May 2008 Intel(R) TXT MLE
Developer's
>  >  Manual:
>  >             Updated to MLE (header) version 2.0
>  >             Updated OsSinitData, SinitMleData structs
>  >             Updated AC module InfoTable struct
>  >             Support Capabilities fields
>  >             Support MONITOR-based RLP wakeup
>  >         Added acminfo app to parse and display AC module
information
>  >         Updated for v3 of BiosData struct
>  >         Reduced TPM-related serial output
>  >         Fixed sealing of hashes for restoring PCRs after S3 resume
>  >         Misc. fixes and code cleanup
>  >
>  >  The most important of the changes is that the new code no longer
>  >  supports either the TEP or older SINIT ACMs.  So along with the
new
>  >  tboot code I have also posted new versions of the SINIT ACM for
the
>  >  Intel(r) Q35 and X38 chipsets (and a guide that helps to determine
which
>  >  one to use for a given platform).  One of these new SINITs *must*
be
>  >  used with the new tboot code--using the previous tboot code with
the new
>  >  SINIT or using the new tboot with the previous SINIT will both
result in
>  >  failure of the launch.
>  >
>  >  The TXT Preliminary Architecture Specification has also been
updated.
>  >  The content on the SMX instructions is now in the "Intel(r) 64 and
IA-32
>  >  Architectures Software Developer's Manual" volume 2B Chapt. 6.  In
place
>  >  of the Preliminary Architecture Spec is the "Intel(r) Trusted
Execution
>  >  Technology Measured Launched Environment Developer's Guide", still
>  >  located at http://www.intel.com/technology/security/.
>
>
> I cannot find the "Developer guide" at
>  http://www.intel.com/technology/security/. Perhaps it is not ready
>  yet??
>

ah, it is still under the old name "Intel(R) Trusted Execution
Technology Preliminary Architecture Specification"

Thanks,
Jun

Re: [tboot-devel] new release of tboot and SINIT AC modules

[Jun K. <jun...@gm...>]

On 6/16/08, Jun Koi <jun...@gm...> wrote:
> On 6/14/08, Cihula, Joseph <jos...@in...> wrote:
>  > I have just checked in a new release of the tboot project.  The changes
>  >  are quite significant and numerous:
>  >         Removed support for Technology Enabling Platform (TEP)
>  >         Removed support for SINIT AC module versions <16 (i.e. <=
>  >  20070910)
>  >         Updated per changes in May 2008 Intel(R) TXT MLE Developer's
>  >  Manual:
>  >             Updated to MLE (header) version 2.0
>  >             Updated OsSinitData, SinitMleData structs
>  >             Updated AC module InfoTable struct
>  >             Support Capabilities fields
>  >             Support MONITOR-based RLP wakeup
>  >         Added acminfo app to parse and display AC module information
>  >         Updated for v3 of BiosData struct
>  >         Reduced TPM-related serial output
>  >         Fixed sealing of hashes for restoring PCRs after S3 resume
>  >         Misc. fixes and code cleanup
>  >
>  >  The most important of the changes is that the new code no longer
>  >  supports either the TEP or older SINIT ACMs.  So along with the new
>  >  tboot code I have also posted new versions of the SINIT ACM for the
>  >  Intel(r) Q35 and X38 chipsets (and a guide that helps to determine which
>  >  one to use for a given platform).  One of these new SINITs *must* be
>  >  used with the new tboot code--using the previous tboot code with the new
>  >  SINIT or using the new tboot with the previous SINIT will both result in
>  >  failure of the launch.
>  >
>  >  The TXT Preliminary Architecture Specification has also been updated.
>  >  The content on the SMX instructions is now in the "Intel(r) 64 and IA-32
>  >  Architectures Software Developer's Manual" volume 2B Chapt. 6.  In place
>  >  of the Preliminary Architecture Spec is the "Intel(r) Trusted Execution
>  >  Technology Measured Launched Environment Developer's Guide", still
>  >  located at http://www.intel.com/technology/security/.
>
>
> I cannot find the "Developer guide" at
>  http://www.intel.com/technology/security/. Perhaps it is not ready
>  yet??
>

ah, it is still under the old name "Intel(R) Trusted Execution
Technology Preliminary Architecture Specification"

Thanks,
Jun

Re: [tboot-devel] new release of tboot and SINIT AC modules

[Jun K. <jun...@gm...>]

On 6/14/08, Cihula, Joseph <jos...@in...> wrote:
> I have just checked in a new release of the tboot project.  The changes
>  are quite significant and numerous:
>         Removed support for Technology Enabling Platform (TEP)
>         Removed support for SINIT AC module versions <16 (i.e. <=
>  20070910)
>         Updated per changes in May 2008 Intel(R) TXT MLE Developer's
>  Manual:
>             Updated to MLE (header) version 2.0
>             Updated OsSinitData, SinitMleData structs
>             Updated AC module InfoTable struct
>             Support Capabilities fields
>             Support MONITOR-based RLP wakeup
>         Added acminfo app to parse and display AC module information
>         Updated for v3 of BiosData struct
>         Reduced TPM-related serial output
>         Fixed sealing of hashes for restoring PCRs after S3 resume
>         Misc. fixes and code cleanup
>
>  The most important of the changes is that the new code no longer
>  supports either the TEP or older SINIT ACMs.  So along with the new
>  tboot code I have also posted new versions of the SINIT ACM for the
>  Intel(r) Q35 and X38 chipsets (and a guide that helps to determine which
>  one to use for a given platform).  One of these new SINITs *must* be
>  used with the new tboot code--using the previous tboot code with the new
>  SINIT or using the new tboot with the previous SINIT will both result in
>  failure of the launch.
>
>  The TXT Preliminary Architecture Specification has also been updated.
>  The content on the SMX instructions is now in the "Intel(r) 64 and IA-32
>  Architectures Software Developer's Manual" volume 2B Chapt. 6.  In place
>  of the Preliminary Architecture Spec is the "Intel(r) Trusted Execution
>  Technology Measured Launched Environment Developer's Guide", still
>  located at http://www.intel.com/technology/security/.

I cannot find the "Developer guide" at
http://www.intel.com/technology/security/. Perhaps it is not ready
yet??

Thanks for the update, Joseph.

Jun

[tboot-devel] new release of tboot and SINIT AC modules

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

I have just checked in a new release of the tboot project.  The changes
are quite significant and numerous:
        Removed support for Technology Enabling Platform (TEP)
        Removed support for SINIT AC module versions <16 (i.e. <=
20070910)
        Updated per changes in May 2008 Intel(R) TXT MLE Developer's
Manual:
            Updated to MLE (header) version 2.0
            Updated OsSinitData, SinitMleData structs
            Updated AC module InfoTable struct
            Support Capabilities fields
            Support MONITOR-based RLP wakeup
        Added acminfo app to parse and display AC module information
        Updated for v3 of BiosData struct
        Reduced TPM-related serial output
        Fixed sealing of hashes for restoring PCRs after S3 resume
        Misc. fixes and code cleanup

The most important of the changes is that the new code no longer
supports either the TEP or older SINIT ACMs.  So along with the new
tboot code I have also posted new versions of the SINIT ACM for the
Intel(r) Q35 and X38 chipsets (and a guide that helps to determine which
one to use for a given platform).  One of these new SINITs *must* be
used with the new tboot code--using the previous tboot code with the new
SINIT or using the new tboot with the previous SINIT will both result in
failure of the launch.

The TXT Preliminary Architecture Specification has also been updated.
The content on the SMX instructions is now in the "Intel(r) 64 and IA-32
Architectures Software Developer's Manual" volume 2B Chapt. 6.  In place
of the Preliminary Architecture Spec is the "Intel(r) Trusted Execution
Technology Measured Launched Environment Developer's Guide", still
located at http://www.intel.com/technology/security/.  It contains much
updated content and describes all of the changes to the data structures,
handoffs, etc. that the new tboot code implements.

The new SINIT ACMs can be used on all existing TXT-capable systems
without any changes to those systems or any re-provisioning of the TPM.
As they also contain a security-related change, future platforms may be
configured by the manufacturer to no longer permit using the previous
version of SINIT.  As such, MLE developers are encouraged to move to the
new SINIT as soon as possible.

Joe, Shane, Jimmy

Re: [tboot-devel] How to validate the PCR measured by TXT?

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

> -----Original Message-----
> From: Jun Koi [mailto:jun...@gm...] 
> Sent: Monday, June 09, 2008 12:55 AM
> To: Cihula, Joseph
> Cc: Martin Thiim; Hal Finney; tbo...@li...
> Subject: Re: [tboot-devel] How to validate the PCR measured by TXT?
>
> On Wed, Jun 4, 2008 at 5:31 AM, Cihula, Joseph
<jos...@in...> wrote:
>> There are a lot of challenges to making a meaningful and reproducible
>> measurement of executing or executed code.  Since BIOS will have
already
>> executed quite a bit of code, the contents of its persistent data are
likely
>> to depend on the code that was executed post-boot (i.e. MBR,
bootloader,
>> etc.) and perhaps even pluggable hardware (e.g. USB).  Thus, if any
of this
>> code changes how it uses BIOS, the BIOS's measurement may change as
well.
>> Additionally, the best you could do with this type of measurement
would be
>> to compare it to a "golden" value taken with the same boot and
hardware
>> conditions on a known-good system.
>>
>>
>>
>> For Xen, it is much easier to simply avoid calling back into BIOS.
Linux,
>> however, has many more BIOS calls and it would be more of a challenge
to
>> remove those.
>>
>
> If so, our current solution doesnt look very good to me. We have tboot
> boots first, then Xen and Dom0 are loaded as multiboot modules.
> However, Dom0 (which is Linux) executes non-measured code, that is
> BIOS interrupt handlers.
>
> Is that bad? Any way to fix this problem???
>
> Thanks,
> Jun

First, dom0 is not part of the core TCB, since the hypervisor and tboot
are isolated from it.  Thus, even if it calls unmeasured code that can't
affect the core TCB.  That said, dom0 is part of the system TCB since it
can affect all other VMs.  So we do need to be concerned if we want a
completely measured TCB.

However, tboot's measurement of dom0 doesn't really measure dom0's TCB.
This is because dom0 will continue to load modules, run root scripts,
etc. from its persistent file system, and that isn't measured by tboot.
So to complete the measurement of dom0, you need IMA or a ramfs-based
dom0 or some similar way of making the entire TCB measurable.

Once you have that, then you can look at whether dom0 invokes any
unmeasured code.  dom0 can't invoke real mode code, so it can't make
most BIOS calls.  And I don't believe it supports the BIOS32 protected
mode interfaces (which would require Xen support).  So I think the BIOS
aspect of unmeasured code is covered for dom0.  It can execute ACPI
methods via the ACPI interpreter.  If this is a concern, I suppose ACPI
could be measured by some component of dom0.

Joe

>> From: Martin Thiim [mailto:ma...@th...]
>> Sent: Monday, June 02, 2008 11:41 AM
>> To: Cihula, Joseph
>> Cc: Hal Finney; Jun Koi; tbo...@li...
>> Subject: Re: [tboot-devel] How to validate the PCR measured by TXT?
>>
>>
>>
>> Ah, so that's why you added an alternative memory map in TXT ;-)
>>
>>
>>
>> Clearly, when TXT goes to the extent of not even trusting the
BIOS-supplied
>> memory map,  one should be careful calling any BIOS code. However,
I'm
>> wondering if it would be possible to validate the BIOS after the MLE
>> launch by simply hashing the code involved without using any PCR's
etc.?
>> After all, the code in the MLE would more or less have full control
of the
>> computer and should thus be able to read the BIOS code and compare it
>> against a (trusted) list. The danger is that the MLE would have to
hash all
>> code that is included in the code paths of the functions it will
call.
>> Someone told me, but I don't know if it's true, that BIOS'es these
days are
>> so big that not all is present in the address space at any given time
(due
>> to the limited numer of addresses in real mode). Instead it does some
sort
>> of bank switching. If this is true it will require knowledge of the
>> bank-switching mechanism in order to do a full hash of the BIOS and
even
>> then the MLE would have to be able to guarentee that no one can
tamper with
>> the mechanism during execution of the BIOS functions etc.
>>
>>
>>
>> Best regards,
>>
>>
>>
>> Martin Thiim
>>
>>
>>
>> On 5/27/08, Cihula, Joseph <jos...@in...> wrote:
>>
>> Hal's answer is spot-on.  One of TXT's goals is to remove BIOS from
the
>> trust chain, and so we would prefer not to have to trust it, which
means
>> not calling into it from the TCB.  TXT does, however, support
>> verification of BIOS (of any of the static PCRs) as part of its
launch
>> control policy.
>>
>> The TXT support in Xen disables the two BIOS calls (for the e820
table
>> and video initialization) that Xen would otherwise make.  This has
>> worked fine for all of the TXT systems that I am aware of and is
likely
>> due to TXT only being available on newer systems (with fewer issues
in
>> these areas).
>>
> Joe
>
> -----Original Message-----
> From: Hal Finney [mailto:hal...@gm...]
> Sent: Sunday, May 25, 2008 3:34 PM
> To: Jun Koi
> Cc: Cihula, Joseph; tbo...@li...
> Subject: Re: [tboot-devel] How to validate the PCR measured by TXT?
>
> Hello Jun -
>
> On Thu, May 22, 2008 at 11:49 PM, Jun Koi <jun...@gm...>
wrote:
>> So basically the question is: should we execute other code outside
our
>> "trusted code"? In this example, BIOS code is not trusted. Or we
>> should avoid that as much as we can?
>
> That certainly makes sense to me. There are really two points here.
> The first is that we don't trust the BIOS because we don't know what
> is in it. The TXT launch does not measure the BIOS and so the TXT PCRs
> do not depend on BIOS contents. Any call we make to BIOS would run
> code that could not be verified.
>
> The second point is that if we did originally do a measured boot, so
> that PCR's 0-7 contain information about BIOS and other aspects of the
> computer configuration, then if we made a call to BIOS, in principle
> we could trust that. The verifier could check that the BIOS
> configuration was as expected and if the BIOS was known to be trusted
> by that verifier, the call would be OK. But there are still problems.
>
> One problem is the size of the Trusted Computer Base (TCB). Including
> the whole BIOS into the TCB makes it larger (although I don't know how
> the BIOS size will compare with Xen). Also, BIOSes often do not have
> much transparency so it may be hard to get hold of the source code and
> know what the BIOS is doing. Also, there are many different brands and
> varieties of BIOS so it would be hard to trust very many of them.
> Another point is that some BIOSes have not done measured boot properly
> and it may be possible to reflash the BIOS to lie about the measured
> boot.
>
> Part of the goal of TXT technology is to reduce the size of the TCB
> and avoid dependence on measured boot. Avoiding calls into the BIOS
> would be a good idea for any TXT Measured Launch Environment (MLE)
> including Xen. However I don't know whether Xen has done as you
> suggest, and avoids BIOS calls when in trusted mode.
>
> Hal Finney
>
>
------------------------------------------------------------------------
-
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> tboot-devel mailing list
> tbo...@li...
> https://lists.sourceforge.net/lists/listinfo/tboot-devel
>
>

Re: [tboot-devel] How to validate the PCR measured by TXT?

[Jun K. <jun...@gm...>]

On Wed, Jun 4, 2008 at 5:31 AM, Cihula, Joseph <jos...@in...> wrote:
> There are a lot of challenges to making a meaningful and reproducible
> measurement of executing or executed code.  Since BIOS will have already
> executed quite a bit of code, the contents of its persistent data are likely
> to depend on the code that was executed post-boot (i.e. MBR, bootloader,
> etc.) and perhaps even pluggable hardware (e.g. USB).  Thus, if any of this
> code changes how it uses BIOS, the BIOS's measurement may change as well.
> Additionally, the best you could do with this type of measurement would be
> to compare it to a "golden" value taken with the same boot and hardware
> conditions on a known-good system.
>
>
>
> For Xen, it is much easier to simply avoid calling back into BIOS.  Linux,
> however, has many more BIOS calls and it would be more of a challenge to
> remove those.
>

If so, our current solution doesnt look very good to me. We have tboot
boots first, then Xen and Dom0 are loaded as multiboot modules.
However, Dom0 (which is Linux) executes non-measured code, that is
BIOS interrupt handlers.

Is that bad? Any way to fix this problem???

Thanks,
Jun



> From: Martin Thiim [mailto:ma...@th...]
> Sent: Monday, June 02, 2008 11:41 AM
> To: Cihula, Joseph
> Cc: Hal Finney; Jun Koi; tbo...@li...
> Subject: Re: [tboot-devel] How to validate the PCR measured by TXT?
>
>
>
> Ah, so that's why you added an alternative memory map in TXT ;-)
>
>
>
> Clearly, when TXT goes to the extent of not even trusting the BIOS-supplied
> memory map,  one should be careful calling any BIOS code. However, I'm
> wondering if it would be possible to validate the BIOS after the MLE
> launch by simply hashing the code involved without using any PCR's etc.?
> After all, the code in the MLE would more or less have full control of the
> computer and should thus be able to read the BIOS code and compare it
> against a (trusted) list. The danger is that the MLE would have to hash all
> code that is included in the code paths of the functions it will call.
> Someone told me, but I don't know if it's true, that BIOS'es these days are
> so big that not all is present in the address space at any given time (due
> to the limited numer of addresses in real mode). Instead it does some sort
> of bank switching. If this is true it will require knowledge of the
> bank-switching mechanism in order to do a full hash of the BIOS and even
> then the MLE would have to be able to guarentee that no one can tamper with
> the mechanism during execution of the BIOS functions etc.
>
>
>
> Best regards,
>
>
>
> Martin Thiim
>
>
>
> On 5/27/08, Cihula, Joseph <jos...@in...> wrote:
>
> Hal's answer is spot-on.  One of TXT's goals is to remove BIOS from the
> trust chain, and so we would prefer not to have to trust it, which means
> not calling into it from the TCB.  TXT does, however, support
> verification of BIOS (of any of the static PCRs) as part of its launch
> control policy.
>
> The TXT support in Xen disables the two BIOS calls (for the e820 table
> and video initialization) that Xen would otherwise make.  This has
> worked fine for all of the TXT systems that I am aware of and is likely
> due to TXT only being available on newer systems (with fewer issues in
> these areas).
>
> Joe
>
> -----Original Message-----
> From: Hal Finney [mailto:hal...@gm...]
> Sent: Sunday, May 25, 2008 3:34 PM
> To: Jun Koi
> Cc: Cihula, Joseph; tbo...@li...
> Subject: Re: [tboot-devel] How to validate the PCR measured by TXT?
>
> Hello Jun -
>
> On Thu, May 22, 2008 at 11:49 PM, Jun Koi <jun...@gm...> wrote:
>> So basically the question is: should we execute other code outside our
>> "trusted code"? In this example, BIOS code is not trusted. Or we
>> should avoid that as much as we can?
>
> That certainly makes sense to me. There are really two points here.
> The first is that we don't trust the BIOS because we don't know what
> is in it. The TXT launch does not measure the BIOS and so the TXT PCRs
> do not depend on BIOS contents. Any call we make to BIOS would run
> code that could not be verified.
>
> The second point is that if we did originally do a measured boot, so
> that PCR's 0-7 contain information about BIOS and other aspects of the
> computer configuration, then if we made a call to BIOS, in principle
> we could trust that. The verifier could check that the BIOS
> configuration was as expected and if the BIOS was known to be trusted
> by that verifier, the call would be OK. But there are still problems.
>
> One problem is the size of the Trusted Computer Base (TCB). Including
> the whole BIOS into the TCB makes it larger (although I don't know how
> the BIOS size will compare with Xen). Also, BIOSes often do not have
> much transparency so it may be hard to get hold of the source code and
> know what the BIOS is doing. Also, there are many different brands and
> varieties of BIOS so it would be hard to trust very many of them.
> Another point is that some BIOSes have not done measured boot properly
> and it may be possible to reflash the BIOS to lie about the measured
> boot.
>
> Part of the goal of TXT technology is to reduce the size of the TCB
> and avoid dependence on measured boot. Avoiding calls into the BIOS
> would be a good idea for any TXT Measured Launch Environment (MLE)
> including Xen. However I don't know whether Xen has done as you
> suggest, and avoids BIOS calls when in trusted mode.
>
> Hal Finney
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> tboot-devel mailing list
> tbo...@li...
> https://lists.sourceforge.net/lists/listinfo/tboot-devel
>
>

Re: [tboot-devel] How to validate the PCR measured by TXT?

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

There are a lot of challenges to making a meaningful and reproducible
measurement of executing or executed code.  Since BIOS will have already
executed quite a bit of code, the contents of its persistent data are
likely to depend on the code that was executed post-boot (i.e. MBR,
bootloader, etc.) and perhaps even pluggable hardware (e.g. USB).  Thus,
if any of this code changes how it uses BIOS, the BIOS's measurement may
change as well.  Additionally, the best you could do with this type of
measurement would be to compare it to a "golden" value taken with the
same boot and hardware conditions on a known-good system.

 

For Xen, it is much easier to simply avoid calling back into BIOS.
Linux, however, has many more BIOS calls and it would be more of a
challenge to remove those.

 

Joe

 

From: Martin Thiim [mailto:ma...@th...] 
Sent: Monday, June 02, 2008 11:41 AM
To: Cihula, Joseph
Cc: Hal Finney; Jun Koi; tbo...@li...
Subject: Re: [tboot-devel] How to validate the PCR measured by TXT?

 

Ah, so that's why you added an alternative memory map in TXT ;-)

 

Clearly, when TXT goes to the extent of not even trusting the
BIOS-supplied memory map,  one should be careful calling any BIOS code.
However, I'm wondering if it would be possible to validate the BIOS
after the MLE launch by simply hashing the code involved without using
any PCR's etc.? After all, the code in the MLE would more or less have
full control of the computer and should thus be able to read the BIOS
code and compare it against a (trusted) list. The danger is that the MLE
would have to hash all code that is included in the code paths of the
functions it will call. Someone told me, but I don't know if it's true,
that BIOS'es these days are so big that not all is present in the
address space at any given time (due to the limited numer of addresses
in real mode). Instead it does some sort of bank switching. If this is
true it will require knowledge of the bank-switching mechanism in order
to do a full hash of the BIOS and even then the MLE would have to be
able to guarentee that no one can tamper with the mechanism during
execution of the BIOS functions etc.

 

Best regards,

 

Martin Thiim

 

On 5/27/08, Cihula, Joseph <jos...@in...> wrote:

	Hal's answer is spot-on.  One of TXT's goals is to remove BIOS
from the
	trust chain, and so we would prefer not to have to trust it,
which means
	not calling into it from the TCB.  TXT does, however, support
	verification of BIOS (of any of the static PCRs) as part of its
launch
	control policy.
	
	The TXT support in Xen disables the two BIOS calls (for the e820
table
	and video initialization) that Xen would otherwise make.  This
has
	worked fine for all of the TXT systems that I am aware of and is
likely
	due to TXT only being available on newer systems (with fewer
issues in
	these areas).
	
	Joe
	
	-----Original Message-----
	From: Hal Finney [mailto:hal...@gm...]
	Sent: Sunday, May 25, 2008 3:34 PM
	To: Jun Koi
	Cc: Cihula, Joseph; tbo...@li...
	Subject: Re: [tboot-devel] How to validate the PCR measured by
TXT?
	
	Hello Jun -
	
	On Thu, May 22, 2008 at 11:49 PM, Jun Koi <jun...@gm...>
wrote:
	> So basically the question is: should we execute other code
outside our
	> "trusted code"? In this example, BIOS code is not trusted. Or
we
	> should avoid that as much as we can?
	
	That certainly makes sense to me. There are really two points
here.
	The first is that we don't trust the BIOS because we don't know
what
	is in it. The TXT launch does not measure the BIOS and so the
TXT PCRs
	do not depend on BIOS contents. Any call we make to BIOS would
run
	code that could not be verified.
	
	The second point is that if we did originally do a measured
boot, so
	that PCR's 0-7 contain information about BIOS and other aspects
of the
	computer configuration, then if we made a call to BIOS, in
principle
	we could trust that. The verifier could check that the BIOS
	configuration was as expected and if the BIOS was known to be
trusted
	by that verifier, the call would be OK. But there are still
problems.
	
	One problem is the size of the Trusted Computer Base (TCB).
Including
	the whole BIOS into the TCB makes it larger (although I don't
know how
	the BIOS size will compare with Xen). Also, BIOSes often do not
have
	much transparency so it may be hard to get hold of the source
code and
	know what the BIOS is doing. Also, there are many different
brands and
	varieties of BIOS so it would be hard to trust very many of
them.
	Another point is that some BIOSes have not done measured boot
properly
	and it may be possible to reflash the BIOS to lie about the
measured
	boot.
	
	Part of the goal of TXT technology is to reduce the size of the
TCB
	and avoid dependence on measured boot. Avoiding calls into the
BIOS
	would be a good idea for any TXT Measured Launch Environment
(MLE)
	including Xen. However I don't know whether Xen has done as you
	suggest, and avoids BIOS calls when in trusted mode.
	
	Hal Finney
	
	
------------------------------------------------------------------------
-
	This SF.net email is sponsored by: Microsoft
	Defy all challenges. Microsoft(R) Visual Studio 2008.
	http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
	_______________________________________________
	tboot-devel mailing list
	tbo...@li...
	https://lists.sourceforge.net/lists/listinfo/tboot-devel

 

Re: [tboot-devel] How to validate the PCR measured by TXT?

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

Ah, so that's why you added an alternative memory map in TXT ;-)

Clearly, when TXT goes to the extent of not even trusting the BIOS-supplied
memory map,  one should be careful calling any BIOS code. However, I'm
wondering if it would be possible to validate the BIOS after the MLE
launch by simply hashing the code involved without using any PCR's etc.?
After all, the code in the MLE would more or less have full control of the
computer and should thus be able to read the BIOS code and compare it
against a (trusted) list. The danger is that the MLE would have to hash all
code that is included in the code paths of the functions it will call.
Someone told me, but I don't know if it's true, that BIOS'es these days are
so big that not all is present in the address space at any given time (due
to the limited numer of addresses in real mode). Instead it does some sort
of bank switching. If this is true it will require knowledge of the
bank-switching mechanism in order to do a full hash of the BIOS and even
then the MLE would have to be able to guarentee that no one can tamper with
the mechanism during execution of the BIOS functions etc.

Best regards,

Martin Thiim

On 5/27/08, Cihula, Joseph <jos...@in...> wrote:

> Hal's answer is spot-on.  One of TXT's goals is to remove BIOS from the
> trust chain, and so we would prefer not to have to trust it, which means
> not calling into it from the TCB.  TXT does, however, support
> verification of BIOS (of any of the static PCRs) as part of its launch
> control policy.
>
> The TXT support in Xen disables the two BIOS calls (for the e820 table
> and video initialization) that Xen would otherwise make.  This has
> worked fine for all of the TXT systems that I am aware of and is likely
> due to TXT only being available on newer systems (with fewer issues in
> these areas).
>
> Joe
>
> -----Original Message-----
> From: Hal Finney [mailto:hal...@gm...]
> Sent: Sunday, May 25, 2008 3:34 PM
> To: Jun Koi
> Cc: Cihula, Joseph; tbo...@li...
> Subject: Re: [tboot-devel] How to validate the PCR measured by TXT?
>
> Hello Jun -
>
> On Thu, May 22, 2008 at 11:49 PM, Jun Koi <jun...@gm...> wrote:
> > So basically the question is: should we execute other code outside our
> > "trusted code"? In this example, BIOS code is not trusted. Or we
> > should avoid that as much as we can?
>
> That certainly makes sense to me. There are really two points here.
> The first is that we don't trust the BIOS because we don't know what
> is in it. The TXT launch does not measure the BIOS and so the TXT PCRs
> do not depend on BIOS contents. Any call we make to BIOS would run
> code that could not be verified.
>
> The second point is that if we did originally do a measured boot, so
> that PCR's 0-7 contain information about BIOS and other aspects of the
> computer configuration, then if we made a call to BIOS, in principle
> we could trust that. The verifier could check that the BIOS
> configuration was as expected and if the BIOS was known to be trusted
> by that verifier, the call would be OK. But there are still problems.
>
> One problem is the size of the Trusted Computer Base (TCB). Including
> the whole BIOS into the TCB makes it larger (although I don't know how
> the BIOS size will compare with Xen). Also, BIOSes often do not have
> much transparency so it may be hard to get hold of the source code and
> know what the BIOS is doing. Also, there are many different brands and
> varieties of BIOS so it would be hard to trust very many of them.
> Another point is that some BIOSes have not done measured boot properly
> and it may be possible to reflash the BIOS to lie about the measured
> boot.
>
> Part of the goal of TXT technology is to reduce the size of the TCB
> and avoid dependence on measured boot. Avoiding calls into the BIOS
> would be a good idea for any TXT Measured Launch Environment (MLE)
> including Xen. However I don't know whether Xen has done as you
> suggest, and avoids BIOS calls when in trusted mode.
>
> Hal Finney
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> tboot-devel mailing list
> tbo...@li...
> https://lists.sourceforge.net/lists/listinfo/tboot-devel
>

[tboot-devel] new tboot release, 20080523

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

There is a new tboot release, tboot-20080523, that includes many fixes
and changes, especially to the TPM code.  Most of these changes have
been in the mercurial source code repo for some time, but there have
been some recent check-ins as well.

This will be the last release that support the Intel(r) TXT Technology
Enabling Platform (TEP) and the old TXT SDPs.

Joe

Re: [tboot-devel] How to validate the PCR measured by TXT?

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

Hal's answer is spot-on.  One of TXT's goals is to remove BIOS from the
trust chain, and so we would prefer not to have to trust it, which means
not calling into it from the TCB.  TXT does, however, support
verification of BIOS (of any of the static PCRs) as part of its launch
control policy.

The TXT support in Xen disables the two BIOS calls (for the e820 table
and video initialization) that Xen would otherwise make.  This has
worked fine for all of the TXT systems that I am aware of and is likely
due to TXT only being available on newer systems (with fewer issues in
these areas).

Joe

-----Original Message-----
From: Hal Finney [mailto:hal...@gm...] 
Sent: Sunday, May 25, 2008 3:34 PM
To: Jun Koi
Cc: Cihula, Joseph; tbo...@li...
Subject: Re: [tboot-devel] How to validate the PCR measured by TXT?

Hello Jun -

On Thu, May 22, 2008 at 11:49 PM, Jun Koi <jun...@gm...> wrote:
> So basically the question is: should we execute other code outside our
> "trusted code"? In this example, BIOS code is not trusted. Or we
> should avoid that as much as we can?

That certainly makes sense to me. There are really two points here.
The first is that we don't trust the BIOS because we don't know what
is in it. The TXT launch does not measure the BIOS and so the TXT PCRs
do not depend on BIOS contents. Any call we make to BIOS would run
code that could not be verified.

The second point is that if we did originally do a measured boot, so
that PCR's 0-7 contain information about BIOS and other aspects of the
computer configuration, then if we made a call to BIOS, in principle
we could trust that. The verifier could check that the BIOS
configuration was as expected and if the BIOS was known to be trusted
by that verifier, the call would be OK. But there are still problems.

One problem is the size of the Trusted Computer Base (TCB). Including
the whole BIOS into the TCB makes it larger (although I don't know how
the BIOS size will compare with Xen). Also, BIOSes often do not have
much transparency so it may be hard to get hold of the source code and
know what the BIOS is doing. Also, there are many different brands and
varieties of BIOS so it would be hard to trust very many of them.
Another point is that some BIOSes have not done measured boot properly
and it may be possible to reflash the BIOS to lie about the measured
boot.

Part of the goal of TXT technology is to reduce the size of the TCB
and avoid dependence on measured boot. Avoiding calls into the BIOS
would be a good idea for any TXT Measured Launch Environment (MLE)
including Xen. However I don't know whether Xen has done as you
suggest, and avoids BIOS calls when in trusted mode.

Hal Finney

Re: [tboot-devel] How to validate the PCR measured by TXT?

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

Hello Jun -

On Thu, May 22, 2008 at 11:49 PM, Jun Koi <jun...@gm...> wrote:
> So basically the question is: should we execute other code outside our
> "trusted code"? In this example, BIOS code is not trusted. Or we
> should avoid that as much as we can?

That certainly makes sense to me. There are really two points here.
The first is that we don't trust the BIOS because we don't know what
is in it. The TXT launch does not measure the BIOS and so the TXT PCRs
do not depend on BIOS contents. Any call we make to BIOS would run
code that could not be verified.

The second point is that if we did originally do a measured boot, so
that PCR's 0-7 contain information about BIOS and other aspects of the
computer configuration, then if we made a call to BIOS, in principle
we could trust that. The verifier could check that the BIOS
configuration was as expected and if the BIOS was known to be trusted
by that verifier, the call would be OK. But there are still problems.

One problem is the size of the Trusted Computer Base (TCB). Including
the whole BIOS into the TCB makes it larger (although I don't know how
the BIOS size will compare with Xen). Also, BIOSes often do not have
much transparency so it may be hard to get hold of the source code and
know what the BIOS is doing. Also, there are many different brands and
varieties of BIOS so it would be hard to trust very many of them.
Another point is that some BIOSes have not done measured boot properly
and it may be possible to reflash the BIOS to lie about the measured
boot.

Part of the goal of TXT technology is to reduce the size of the TCB
and avoid dependence on measured boot. Avoiding calls into the BIOS
would be a good idea for any TXT Measured Launch Environment (MLE)
including Xen. However I don't know whether Xen has done as you
suggest, and avoids BIOS calls when in trusted mode.

Hal Finney

Re: [tboot-devel] How to validate the PCR measured by TXT?

[Jun K. <jun...@gm...>]

On 5/16/08, Jun Koi <jun...@gm...> wrote:
> Hi Joseph,
>
>
>  >>>  In case of Static-RTM, we can validate the PCR values by using
>  >>>  the BIOS eventlog stored at ACPI table.
>  >>>  But for Dynamic-RTM we don't have such eventlog.
>  >>
>  >> Do you know if there is any good reason why tboot doesn't log events
>  >> into eventlog?
>  >
>  > Did you mean why tboot doesn't copy the extend information into the BIOS
>  > event log or why TXT itself doesn't put them there?
>  >
>  > For the former, it is a combination of lack of time, issues with the
>  > eventlog, and motivation.  Regarding the eventlog, the current TCG
>  > specification does not provide for BIOS to indicate where the log data
>  > ends.  There is a soon-to-be-released update for the spec that will
>  > specify that the end space be filled with ff's, but that will require
>  > updated BIOSes.  Regarding motivation, it wasn't clear how useful or
>  > important it would be.
>  >
>  > The values for PCR 17 and 18 are available in the SinitMleData struct in
>  > the TXT heap.  So MLEs can access it and expose it to whatever SW needs
>  > it.
>  >
>  > For TXT not doing it, the reasons are very similar.  In addition, we
>  > didn't want to tie the launch process to BIOS and its configuration.
>  >
>
>
> I think again about the above comment: we dont want to tie with BIOS,
>  thus we must not call BIOS functions to measure/extend configuration
>  data. Therefore, it is a good idea for the next code launched by tboot
>  (like Xen or a particular OS) should not use BIOS at all, right?
>
>  If so, I suppose that all the Xen code now already removed all the
>  calls to BIOS???
>

So basically the question is: should we execute other code outside our
"trusted code"? In this example, BIOS code is not trusted. Or we
should avoid that as much as we can?

Thanks,
Jun

Re: [tboot-devel] How to validate the PCR measured by TXT?

[Jun K. <jun...@gm...>]

Hi Joseph,

>>>  In case of Static-RTM, we can validate the PCR values by using
>>>  the BIOS eventlog stored at ACPI table.
>>>  But for Dynamic-RTM we don't have such eventlog.
>>
>> Do you know if there is any good reason why tboot doesn't log events
>> into eventlog?
>
> Did you mean why tboot doesn't copy the extend information into the BIOS
> event log or why TXT itself doesn't put them there?
>
> For the former, it is a combination of lack of time, issues with the
> eventlog, and motivation.  Regarding the eventlog, the current TCG
> specification does not provide for BIOS to indicate where the log data
> ends.  There is a soon-to-be-released update for the spec that will
> specify that the end space be filled with ff's, but that will require
> updated BIOSes.  Regarding motivation, it wasn't clear how useful or
> important it would be.
>
> The values for PCR 17 and 18 are available in the SinitMleData struct in
> the TXT heap.  So MLEs can access it and expose it to whatever SW needs
> it.
>
> For TXT not doing it, the reasons are very similar.  In addition, we
> didn't want to tie the launch process to BIOS and its configuration.
>

I think again about the above comment: we dont want to tie with BIOS,
thus we must not call BIOS functions to measure/extend configuration
data. Therefore, it is a good idea for the next code launched by tboot
(like Xen or a particular OS) should not use BIOS at all, right?

If so, I suppose that all the Xen code now already removed all the
calls to BIOS???

Many thanks,
Jun

Re: [tboot-devel] Launch Control & Verified Launch Policy

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

On Thursday, May 01, 2008 3:29 AM, Jun Koi wrote:
> Hello,
> 
> Could anybody help here? I am stuck with this problem.
> 
> Many thanks,
> Jun

LCP will be fully documented in the next update of the spec, which will
be available very shortly.  Unfotunately, the material is much too large
to include in an email as I did with the PCRs.  So for the time being,
the code in the lcptools directory is the best reference and
description.

If you have specific questions in the meantime, I will try to answer
them.

Joe

> On Thu, Apr 24, 2008 at 7:07 PM, Jun Koi <jun...@gm...> wrote:
>> Hi,
>> 
>>  Is there any documentation about LCP? We have some tools in tboot
>>  about this, but I found almost no docs that can help me to
understand
>>  what the policy tools are doing.
>> 
>>  Same question for Verified Launch policy. What exactly TXT is doing
with
>> that? 
>> 
>>  Many thanks,
>>  J
> 
>
------------------------------------------------------------------------
-
> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
> Don't miss this year's exciting event. There's still time to save
$100.
> Use priority code J8TL2D2.
>
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/j
avaone
> _______________________________________________
> tboot-devel mailing list
> tbo...@li...
> https://lists.sourceforge.net/lists/listinfo/tboot-devel

Re: [tboot-devel] Launch Control & Verified Launch Policy

[Jun K. <jun...@gm...>]

Hello,

Could anybody help here? I am stuck with this problem.

Many thanks,
Jun


On Thu, Apr 24, 2008 at 7:07 PM, Jun Koi <jun...@gm...> wrote:
> Hi,
>
>  Is there any documentation about LCP? We have some tools in tboot
>  about this, but I found almost no docs that can help me to understand
>  what the policy tools are doing.
>
>  Same question for Verified Launch policy. What exactly TXT is doing with that?
>
>  Many thanks,
>  J

Re: [tboot-devel] How to validate the PCR measured by TXT?

[Jun K. <jun...@gm...>]

On Sat, Apr 26, 2008 at 4:40 AM, Cihula, Joseph <jos...@in...> wrote:
>
> On Friday, April 25, 2008 7:47 AM, Jun Koi wrote:
>  > On 4/17/08, Seiji Munetoh <sei...@gm...> wrote:
>  >> Hi Folks,
>  >>
>  >>  Is there any way to validate the PCR[17] and PCR18] values?
>  >>
>  >>  In case of Static-RTM, we can validate the PCR values by using
>  >>  the BIOS eventlog stored at ACPI table.
>  >>  But for Dynamic-RTM we don't have such eventlog.
>  >
>  > Do you know if there is any good reason why tboot doesn't log events
>  > into eventlog?
>
>  Did you mean why tboot doesn't copy the extend information into the BIOS
>  event log or why TXT itself doesn't put them there?
>
>  For the former, it is a combination of lack of time, issues with the
>  eventlog, and motivation.  Regarding the eventlog, the current TCG
>  specification does not provide for BIOS to indicate where the log data
>  ends.  There is a soon-to-be-released update for the spec that will
>  specify that the end space be filled with ff's, but that will require
>  updated BIOSes.  Regarding motivation, it wasn't clear how useful or
>  important it would be.
>
>  The values for PCR 17 and 18 are available in the SinitMleData struct in
>  the TXT heap.  So MLEs can access it and expose it to whatever SW needs
>  it.
>
>  For TXT not doing it, the reasons are very similar.  In addition, we
>  didn't want to tie the launch process to BIOS and its configuration.
>

Thanks Joseph for the informative answer.

Jun

Re: [tboot-devel] SENTER -> Legacy Shutdown

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

Hi Jon - I have been working on something similar as a personal
experiment. I have successfully launched a measured environment from a
Linux device driver. It took a lot of trial and error to make it work.
On my machine, an HP dc7800, the LT.ERRORCODE register is not readable
after a TXT failure (the machine hangs and has to be power cycled) so
that made it somewhat more difficult.

Some advice I can suggest. I changed the BIOS to use only one CPU, and
then booted the single-CPU version of Linux. I don't know if downing
the CPUs from within Linux would accomplish the same thing, I haven't
tried that yet. (I am still working on returning from the measured
state back into Linux, which almost/sometimes works.) You might
consider doing this to remove one of the variables.

To make sure I recognized when I finally succeeded, I had my MLE start
with a jump to itself, an infinite loop. This was distinguishable from
the usual halt state because the display stayed on, and made sure that
I didn't have a successful launch which then failed due to something
in the MLE.

 As far as making it work, in the end it came down to careful study of
the TXT manual and attempting to verify that I had everything set up
correctly, especially the MTRRs and the page tables.

I have a smaller memory so my sinit is at 3e500000, size 5f00. Here is
how my MTRRs are set up:

MTRRCAP: 0xd08
MTRR_DEF_TYPE: 0x400
Variable MTRR Base 0: 0x3e500006, Mask: 0xfffffc800
Variable MTRR Base 1: 0x3e504006, Mask: 0xfffffe800
Remaining variable MTRRs are 0

My MLE on this run was at 0x20e00000 physical address. I put the MLE
page table at the beginning of this area:

PDPTE[0] = 0x20e01001
PDE[0] = 09x20e02003
PTE[0] = 0x20e03003
PTE[1] = 0x20e04003
PTE[2] = 0x20e05003

I loaded the MLE code at 0x20e03000 and put the MLE header at the
beginning. MLEPageTableBase was 0x20e00000. PMRLowBase is the MLE
address rounded down to a 2MB boundary; PMRLowSize is 2 MB.
MLEHeaderBase is 0 (the "virtual" address of the MLE header using the
MLE page tables).

Hopefully some of this might give you some ideas of things to try -

Hal Finney

Re: [tboot-devel] How to validate the PCR measured by TXT?

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

On Friday, April 25, 2008 7:47 AM, Jun Koi wrote:
> On 4/17/08, Seiji Munetoh <sei...@gm...> wrote:
>> Hi Folks,
>> 
>>  Is there any way to validate the PCR[17] and PCR18] values?
>> 
>>  In case of Static-RTM, we can validate the PCR values by using
>>  the BIOS eventlog stored at ACPI table.
>>  But for Dynamic-RTM we don't have such eventlog.
> 
> Do you know if there is any good reason why tboot doesn't log events
> into eventlog?

Did you mean why tboot doesn't copy the extend information into the BIOS
event log or why TXT itself doesn't put them there?

For the former, it is a combination of lack of time, issues with the
eventlog, and motivation.  Regarding the eventlog, the current TCG
specification does not provide for BIOS to indicate where the log data
ends.  There is a soon-to-be-released update for the spec that will
specify that the end space be filled with ff's, but that will require
updated BIOSes.  Regarding motivation, it wasn't clear how useful or
important it would be.

The values for PCR 17 and 18 are available in the SinitMleData struct in
the TXT heap.  So MLEs can access it and expose it to whatever SW needs
it.

For TXT not doing it, the reasons are very similar.  In addition, we
didn't want to tie the launch process to BIOS and its configuration.

Joe

Re: [tboot-devel] How to validate the PCR measured by TXT?

[Jun K. <jun...@gm...>]

On 4/17/08, Seiji Munetoh <sei...@gm...> wrote:
> Hi Folks,
>
>  Is there any way to validate the PCR[17] and PCR18] values?
>
>  In case of Static-RTM, we can validate the PCR values by using
>  the BIOS eventlog stored at ACPI table.
>  But for Dynamic-RTM we don't have such eventlog.

Do you know if there is any good reason why tboot doesn't log events
into eventlog?

thanks,
J

[tboot-devel] Launch Control & Verified Launch Policy

[Jun K. <jun...@gm...>]

Hi,

Is there any documentation about LCP? We have some tools in tboot
about this, but I found almost no docs that can help me to understand
what the policy tools are doing.

Same question for Verified Launch policy. What exactly TXT is doing with that?

Many thanks,
J

[tboot-devel] SENTER -> Legacy Shutdown

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

Hello Joseph, tboot-devel (now that I know it exists :-),

I'm hoping for some advice debugging the invocation of GETSEC[SENTER]
after Linux has booted normally (without TBOOT).  We invoke SENTER from
a custom Linux kernel module.

Our system is a D3C6100 Software Development Platform, and we are able
to boot Xen with TBOOT successfully executing GETSEC[SENTER].  I.e., I
believe our hardware works and the relevant BIOS settings are correct.

When we invoke SENTER, the system appears to freeze.  The keyboard is
unresponsive and we are forced to reset the system (we've been using the
reset button on the motherboard).  Reading the LT.ERRORCODE register
during the next boot cycle yields: 0x80000000.  According to the
preliminary architecture specification (from August 2007: 31516804.pdf
(is there a newer version available?)) this is a processor-initiated
#LegacyShutdown.  From section 3.1, I gather that something caused a
triple-fault during the execution of SENTER.  Is this the correct
interpretation of a #LegacyShutdown?

We also tried some experiments with hopes of eliciting a richer failure
mode.  In the above experiment, TXTCR_SINIT_BASE is set to 0x7d500000
(we did not modify it; we only read this value), and we write the SINIT
module (BRLK_SINIT_20070910_debug.BIN) to precisely that physical
address.  Here is a summary of our additional experiments (note that
this is our code from within a Linux kernel module; the "TBOOT:"
prefixes are there because we stole shamelessly from TBOOT :):

(1) (precisely what I described above, for consistency)
use TXTCR_SINIT_BASE register as-is (0x7d500000)
set legitimate address of SINIT module (0x7d500000) as the argument of
__getsec_senter

Result: system freeze
TBOOT: LT.ERRORCODE=80000000
TBOOT: processor error 0

Intel Trusted Execution Technology Preliminary Architecture
Specification on page 86, Table 23 says "Legacy shutdown".


In what follows, 0x00c00000 is an alternate physical address where we
position the SINIT module prior to executing SENTER.  0x00cc0000
(*different*) is an invalid address, in that it does _not_ contain an
SINIT module.


(2)
set TXTCR_SINIT_BASE register to invalid value (0x00cc0000)
set invalid address (0x00000000) as the argument of __getsec_senter

Result: system freeze
TBOOT: LT.ERRORCODE=80000005
TBOOT: processor error 5

Intel Trusted Execution Technology Preliminary Architecture
Specification on page 86, Table 23 says "Load memory type error in
Authentication Code Execution Area".


(3)
set TXTCR_SINIT_BASE register to invalid value (0x00cc0000)
set legitimate address (0x7d500000) as the argument of __getsec_senter

Result:system does not freeze, it automatically reboots
TBOOT: LT.ERRORCODE=c0001841
TBOOT: AC module error : acm_type=1, progress=04, error=6
 --> SINIT region not completely contained within DPR


(4)
set TXTCR_SINIT_BASE register as 0x00c00000 (legitimate)
set legitimate address (0x00c00000) as the argument of __getsec_senter

Result: system freeze
TBOOT: LT.ERRORCODE=80000005
TBOOT:   processor error 5


(5)
set TXTCR_SINIT_BASE register as 0x00c00000 (legitimate (yes, SINIT is
in 2 different places in memory))
set legitimate address (0x7d500000) as the argument of __getsec_senter

Result:system does not freeze, automatically reboot
TBOOT: LT.ERRORCODE=c0001841
TBOOT: AC module error : acm_type=1, progress=04, error=6
 --> SINIT region not completely contained within DPR



We also modified TBOOT to induce a failure, just to satisfy our
curiosity. If we intentionally set the page global directory to all 0s,
the error code changes to c0001071:
0100      one of the rules for table address ordering was not met.

I'm not sure what we're doing wrong wrt execution of SENTER.  The
Preliminary Architecture Specification does not provide enough detail to
be certain of every aspect of system configuration required for
successful launch.  For example, we are calling SENTER with CR0.PG=1
(Linux typically executes with paging enabled).  We disable the RLPs
(responding logical processors) using the cpu-hotplug facility in Linux,
which puts them into an acceptable state as far as I can tell.

I'm especially concerned about assumptions the processor and / or SINIT
module make with respect to the GDT before executing SENTER, and with
respect to the page tables pointed-to by MLE PageTableBase.  I think MLE
PageTableBase should be irrelevant until execution of SINIT is
almost-complete or totally completed.

Any suggestions or advice would be greatly appreciated.

Thanks,
-Jon

[tboot-devel] SENTER -> Legacy Shutdown

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

Hello Joseph, tboot-devel (now that I know it exists :-),

I'm hoping for some advice debugging the invocation of GETSEC[SENTER]
after Linux has booted normally (without TBOOT).  We invoke SENTER from
a custom Linux kernel module.

Our system is a D3C6100 Software Development Platform, and we are able
to boot Xen with TBOOT successfully executing GETSEC[SENTER].  I.e., I
believe our hardware works and the relevant BIOS settings are correct.

When we invoke SENTER, the system appears to freeze.  The keyboard is
unresponsive and we are forced to reset the system (we've been using the
reset button on the motherboard).  Reading the LT.ERRORCODE register
during the next boot cycle yields: 0x80000000.  According to the
preliminary architecture specification (from August 2007: 31516804.pdf
(is there a newer version available?)) this is a processor-initiated
#LegacyShutdown.  From section 3.1, I gather that something caused a
triple-fault during the execution of SENTER.  Is this the correct
interpretation of a #LegacyShutdown?

We also tried some experiments with hopes of eliciting a richer failure
mode.  In the above experiment, TXTCR_SINIT_BASE is set to 0x7d500000
(we did not modify it; we only read this value), and we write the SINIT
module (BRLK_SINIT_20070910_debug.BIN) to precisely that physical
address.  Here is a summary of our additional experiments (note that
this is our code from within a Linux kernel module; the "TBOOT:"
prefixes are there because we stole shamelessly from TBOOT :):

(1) (precisely what I described above, for consistency)
use TXTCR_SINIT_BASE register as-is (0x7d500000)
set legitimate address of SINIT module (0x7d500000) as the argument of
__getsec_senter

Result: system freeze
TBOOT: LT.ERRORCODE=80000000
TBOOT: processor error 0

Intel Trusted Execution Technology Preliminary Architecture
Specification on page 86, Table 23 says "Legacy shutdown".


In what follows, 0x00c00000 is an alternate physical address where we
position the SINIT module prior to executing SENTER.  0x00cc0000
(*different*) is an invalid address, in that it does _not_ contain an
SINIT module.


(2)
set TXTCR_SINIT_BASE register to invalid value (0x00cc0000)
set invalid address (0x00000000) as the argument of __getsec_senter

Result: system freeze
TBOOT: LT.ERRORCODE=80000005
TBOOT: processor error 5

Intel Trusted Execution Technology Preliminary Architecture
Specification on page 86, Table 23 says "Load memory type error in
Authentication Code Execution Area".


(3)
set TXTCR_SINIT_BASE register to invalid value (0x00cc0000)
set legitimate address (0x7d500000) as the argument of __getsec_senter

Result:system does not freeze, it automatically reboots
TBOOT: LT.ERRORCODE=c0001841
TBOOT: AC module error : acm_type=1, progress=04, error=6
 --> SINIT region not completely contained within DPR


(4)
set TXTCR_SINIT_BASE register as 0x00c00000 (legitimate)
set legitimate address (0x00c00000) as the argument of __getsec_senter

Result: system freeze
TBOOT: LT.ERRORCODE=80000005
TBOOT:   processor error 5


(5)
set TXTCR_SINIT_BASE register as 0x00c00000 (legitimate (yes, SINIT is
in 2 different places in memory))
set legitimate address (0x7d500000) as the argument of __getsec_senter

Result:system does not freeze, automatically reboot
TBOOT: LT.ERRORCODE=c0001841
TBOOT: AC module error : acm_type=1, progress=04, error=6
 --> SINIT region not completely contained within DPR



We also modified TBOOT to induce a failure, just to satisfy our
curiosity. If we intentionally set the page global directory to all 0s,
the error code changes to c0001071:
0100      one of the rules for table address ordering was not met.

I'm not sure what we're doing wrong wrt execution of SENTER.  The
Preliminary Architecture Specification does not provide enough detail to
be certain of every aspect of system configuration required for
successful launch.  For example, we are calling SENTER with CR0.PG=1
(Linux typically executes with paging enabled).  We disable the RLPs
(responding logical processors) using the cpu-hotplug facility in Linux,
which puts them into an acceptable state as far as I can tell.

I'm especially concerned about assumptions the processor and / or SINIT
module make with respect to the GDT before executing SENTER, and with
respect to the page tables pointed-to by MLE PageTableBase.  I think MLE
PageTableBase should be irrelevant until execution of SINIT is
almost-complete or totally completed.

Any suggestions or advice would be greatly appreciated.

Thanks,
-Jon

Re: [tboot-devel] How to validate the PCR measured by TXT?

[Seiji M. <sei...@gm...>]

2008/4/18, Seiji Munetoh <sei...@gm...>:
>  1st step, I'd like to validate the PCRs by using the TBOOT message.
>  I verified the PCR18 by just extend the mle_hash value. good.
>  But I have not been able to validate the PCR17...

Sorry, my calc was wrong.
Now, I have confirmed both PCR17 and PCR18 values. :-)

Thanks!!!
--
Seiji

Re: [tboot-devel] How to validate the PCR measured by TXT?

[Seiji M. <sei...@gm...>]

Hi Hal, Joe.

Thank you for your advices. That is a big help.

2008/4/18, Hal Finney <hal...@gm...>:
>  Seiji, have you tried reading PCR 17 and PCR 18? What values do you get?

Yes. here is,

# cat /sys/class/misc/tpm0/device/pcrs
<snip>
PCR-16: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
PCR-17: C0 E5 23 76 84 CD 97 4F DF 6E CD 4A 27 17 EA 63 B0 99 B2 82
PCR-18: 55 50 38 7D 03 F1 EE FA 45 49 65 5A 70 27 85 B4 14 4B C5 2E
PCR-19: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
PCR-20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
PCR-21: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
PCR-22: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
PCR-23: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

and boot message is as follows
<snip>
TBOOT: sinit_mle_data (@7d4201a4, 260):
TBOOT:   version=5
TBOOT:   bios_acm_id=
        80 00 00 00 20 07 09 10 ff ff ff ff ff ff ff ff ff ff ff ff
TBOOT:   edx_senter_flags=0
TBOOT:   mseg_valid=0
TBOOT:   sinit_hash=
        b2 12 60 68 7f 26 f0 cd a9 c7 5e 81 ff 78 92 72 1d 50 ed 4d
TBOOT:   mle_hash=
        df 7b ac e3 5f a2 3d 23 d4 fe 1a 4a 25 8b 4e 4e b0 c2 64 a4
TBOOT:   stm_hash=
        00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
TBOOT:   lcp_policy_hash=
        df 7b ac e3 5f a2 3d 23 d4 fe 1a 4a 25 8b 4e 4e b0 c2 64 a4
TBOOT:   lcp_policy_control=0
<snip>

1st step, I'd like to validate the PCRs by using the TBOOT message.
I verified the PCR18 by just extend the mle_hash value. good.
But I have not been able to validate the PCR17...

2nd step, will create hash values in TBOOT massage from SINIT file.
Then we will be able to predict the PCRs extended by the TXT.:-)

Thanks,
--
Seiji

Re: [tboot-devel] How to validate the PCR measured by TXT?

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

Here is the text from the draft of the updated TXT spec (empirically
verified on my system):

1.9	PCR Usage
	As part of the measured launch, Intel TXT will extend
measurements of the elements and configuration values of the dynamic
root of trust into certain TPM PCRs.  The constituent values of these
measurements (indicated below) are provided in the SinitMleData
structure described in Appendix C.4.
	While the MLE may choose to extend additional values into these
PCRs, the values described below are those present immediately after the
MLE receives control following the GETSEC[SENTER] instruction.

1.9.1	PCR 17
	PCR 17 is initialized using the TPM_HASH_START/TPM_HASH_END
sequence.  The HASH_DATA provided in this sequence is the concatenation
of the SHA-1 hash of the SINIT ACM that was used in the launch process
and the 4 byte value of the SENTER parameters (in EDX and also in
SinitMleData.EdxSenterFlags).  As part of this sequence, PCRs 17-23 are
reset to 0.  The hash of SINIT is also stored in the
SinitMleData.SinitHash field.
PCR 17 is then extended with the SHA-1 hash of the following items
concatenated in this order:
	SHA-1 hash of SCLEAN ACM - SinitMleData.BiosAcmID (20 bytes)
	STM opt-in indicator - SinitMleData.MsegValid (8 bytes)
	SHA-1 hash of the STM (or all 0s if opt-out) -
SinitMleData.StmHash (20 bytes)
	LCP Control Field of used policy (PD or PO) -
SinitMleData.PolicyControl (4 bytes) 
	SHA-1 hash of used policy - SinitMleData.LcpPolicyHash (20
bytes)

Thus, PCR 17's final value will be:
	Extend ( SHA-1( SinitMleData.SinitHash |
SinitMleData.EdxSenterFlags ) )
	Extend ( SHA-1 ( SinitMleData.BiosAcm.ID |
SinitMleData.MsegValid |
		SinitMleData.StmHash | SinitMleData.PolicyControl |
		SinitMleData.LcpPolicyHash ) )

Where the Extend() operation is a SHA-1 hash of the previous value in
the PCR concatenated with the value being extended (the previous value
is 20 bytes of 0s in the case of the first extend to a PCR).

1.9.2	PCR 18
	PCR 18 will be extended with the SHA-1 hash of the MLE, as
reported in the SinitMleData.MleHash field.

Thus, PCR 18's final value will be:
	Extend ( SinitMleData.MleHash )

Joe

On Thursday, April 17, 2008 9:46 AM, Hal Finney wrote:
> On Thu, Apr 17, 2008 at 4:31 AM, Seiji Munetoh
<sei...@gm...>
> wrote: 
>> Hi Folks,
>> 
>>  Is there any way to validate the PCR[17] and PCR18] values?
>> 
>>  In case of Static-RTM, we can validate the PCR values by using
>>  the BIOS eventlog stored at ACPI table.
>>  But for Dynamic-RTM we don't have such eventlog.
>> 
>>  I just tried different tpm_extend combinations from digests
>>  in the tboot's console message. but I can't find the right
>>  combination to produce the PCR17,18 values.
> 
> Hi, Seiji - Joseph Cihula shared the information below with me that
> explains what goes into PCR 17 and PCR 18. He says it will go into the
> next edition of the TXT architecture spec:
> 
>>>>>> I wonder if you could report what is in PCR17 after a tboot
launch
>>>>>> using this SINIT module?
>>>>> 
>>>>> I'm planning to update the TXT Prelim Arch Spec with this
information,
>>>>> but in the meantime, the contents are:
>>>>>     TPM_Extend( SHA1( SINIT AC module) )
>>>>>     TPM_Extend( SHA1( SCLEAN hash (20 bytes) | MsrValidBit (8
bytes) |
>>>>> StmDigest (20 bytes) | LCP Control Field (4 bytes) | LCP Hash (20
bytes)
>>>>> ) ) where the second extend is the hash of the concatenation of
the
>>>>> specified values (72 bytes in all).  You can get the listed values
from
>>>>> the SinitMleData structure.
>>>> 
>>>> In looking at the SinitMleData structure in section C.4 of the
>>>> document, some of these fields have slightly different names. No
>>>> SCLEAN hash is listed, rather there is an SinitHash at offset 36.
Is
>>>> this actually an SCLEAN AC module hash? Then, MsrValidBit is called
>>>> MsegValid and relates to the SMM Transfer Module stuff that I don't
>>>> understand yet. StmDigest is StmHash, LCP Control Field is
>>>> PolicyControl, and LCP Hash is LcpPolicyHash. So the main question
>>>> here is the SINIT vs SCLEAN hash.
>>> 
>>> Sorry for the confusion--here is the mapping of terms above to
fields in
>>> SinitMleData: 
>>> 
>>> SCLEAN hash -> BiosAcmID
>>> MsrValidBit -> MsegValid
>>> StmDigest -> StmHash
>>> LCP Control Field -> PolicyControl
>>> LCP Hash -> LcpPolicyHash
>>> 
>>>>>> And then (sorry about so many questions!) how about the
measurement of
>>>>>> the MLE, which gets hashed, I think, into PCR18 (or maybe PCR19)?
Is
>>>>>> there any information about that, what exactly is hashed and what
>>>>>> sequence of extends are done?
>>>>> 
>>>>> The hash of the MLE is extended into PCR 18.
>>>> 
>>>> I see, thanks. I'm a little unclear about what exactly is hashed
>>>> though. It looks like it might be the linear-address region (under
the
>>>> mapping defined by the MLE page tables) starting from the
>>>> FirstValidPage field in the MLE header as described in Table 9, and
>>>> extending for "MLE size" bytes as recorded in the OsSinitData
>>>> structure? Does that sound right?
>>> 
>>> PCR 18 is extended with the hash of the MLE, as described by the MLE
>>> page table.  The hashing starts at the first valid page and
continues
>>> until a non-valid page.  It will hash to the size specified by
>>> OsSinitData.MleSize.
> 
> Seiji, have you tried reading PCR 17 and PCR 18? What values do you
get?
> 
> 
>>  I'm using Fedora8 and Xen-3.2 on DQ35JO board (BIOS v865)  and my
grub.conf
>> is 
>> 
>>  title Fedora (2.6.21.7-2.fc8xen) XEN 3.2 w/ TBOOT
>>         root (hd0,4)
>>         kernel /boot/tboot.gz
>>         module /boot/xen.gz-3.2 vtd=1 com1=115200,8n1
>>         module /boot/vmlinuz-2.6.21.7-2.fc8xen ro root=LABEL=/1
>>         module /boot/initrd-2.6.21.7-2.fc8xen.img
>>         module /boot/BRLK_SINIT_20070910_release.BIN
>> 
>>  Actually, the xen and kernel digest I found in the console massage
>>  were correct (same as the sha1 digest of  gunziped file).
>> 
>>  But, the digest of SINIT code was somehow different.
>> 
>>  TBOOT:   sinit_hash=
>>         b2 12 60 68 7f 26 f0 cd a9 c7 5e 81 ff 78 92 72 1d 50 ed 4d
>> 
>>  # sha1sum /boot/BRLK_SINIT_20070910_release.BIN
>>  46f4e1c199c2983e8a8a115cd90c88353e7b08dc
> 
> The sinit_hash is not the hash of the entire SINIT module, but only of
> certain portions of it. This is described in section A.1.2 of the
> Preliminary Architecture Specification: "The RSA Signature signs an
> area that includes the sum of the module header and all of the USER
> AREA data field,
> which represents the body of the module. Those parts of the module
header not
> included are: the RSA Signature, the public key, and the scratch
> field." This is the data which gets hashed to form sinit_hash.
> 
> Hal Finney
> 
>
------------------------------------------------------------------------
-
> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
> Don't miss this year's exciting event. There's still time to save
$100.
> Use priority code J8TL2D2.
>
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/j
avaone
> _______________________________________________
> tboot-devel mailing list
> tbo...@li...
> https://lists.sourceforge.net/lists/listinfo/tboot-devel