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.
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
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
From: Hal Finney [mailto:firstname.lastname@example.org]
Sent: Sunday, May 25, 2008 3:34 PM
To: Jun Koi
Cc: Cihula, Joseph; email@example.com
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 <firstname.lastname@example.org> 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
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.
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
tboot-devel mailing list