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
>
>