Message-ID: <4F65016F6CB04E49BFFA15D4F7B798D9A2AAD63B@orsmsx506.amr.corp.intel.com>
Date:	Thu, 25 Jun 2009 12:25:33 -0700
From:	"Cihula, Joseph" <joseph.cihula@...el.com>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Arjan van de Ven <arjan@...ux.intel.com>
CC:	Dave Jones <davej@...hat.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"mingo@...e.hu" <mingo@...e.hu>,
	"arjan@...ux.intel.com" <arjan@...ux.intel.com>,
	"hpa@...or.com" <hpa@...or.com>,
	"andi@...stfloor.org" <andi@...stfloor.org>,
	"chrisw@...s-sol.org" <chrisw@...s-sol.org>,
	"jmorris@...ei.org" <jmorris@...ei.org>,
	"jbeulich@...ell.com" <jbeulich@...ell.com>,
	"peterm@...hat.com" <peterm@...hat.com>,
	"Wei, Gang" <gang.wei@...el.com>,
	"Wang, Shane" <shane.wang@...el.com>
Subject: RE: [RFC v5][PATCH 0b/4] intel_txt: Intel(R) Trusted Execution
 Technology support for Linux - Details

Let me try to unify and respond to the couple of branches of this thread:

> From: Alan Cox [mailto:alan@...rguk.ukuu.org.uk]
> Sent: Wednesday, June 24, 2009 3:50 PM
>
> > > "trust us, it's signed by intel" doesn't make me feel more secure.
> >
> > how's that different from your normal bios ?
>
> I've yet to see grub load my bios 8)

and

> From: Dave Jones [mailto:davej@...hat.com]
> Sent: Wednesday, June 24, 2009 1:51 PM
>
> On Wed, Jun 24, 2009 at 01:37:49PM -0700, Arjan van de Ven wrote:
>  > Dave Jones wrote:
>  > > On Mon, Jun 22, 2009 at 05:41:26PM -0700, Joseph Cihula wrote:
>  > >
>  > >  > The Q35_SINIT_17.BIN file is what Intel TXT refers to as an
>  > >  > Authenticated Code Module.  It is specific to the chipset in the system
>  > >  > and can also be found on the Trusted Boot site.  It is a firmware module
>  > >  > digitally signed by Intel that is used as part of the DRTM process to
>  > >  > verify and configure the system.
>  > >
>  > > This seems a little disingenious.  Firmware isn't typically loaded by grub
>  > > into main memory and executed by the host processor.
>  > >
>  > > so, is this all worthless without the binary blob ?
>  > >
>  > > "trust us, it's signed by intel" doesn't make me feel more secure.
>  >
>  > how's that different from your normal bios ?
>
> well..
>
> AFAICS, this code exists solely to enable a binary blob. We don't do that
> for the BIOS.  Even for blobs like ACPI, we at least have documentation on
> the opcodes/data structures.
>
> Also, if they're the same as you claim, why isn't the blob just included as
> part of the BIOS ?

I would actually liken the SINIT AC module more to microcode than to BIOS.  If you look at the Intel(R) TXT measured launch flow (e.g. see http://www.xen.org/files/summit_3/Xen_support_for_LaGrande_Technology.pdf), SINIT is executed by the SENTER microcode and the software that executed the SENTER instruction doesn't get control again until after SINIT finishes executing (and SINIT is executing in a special CPU mode that only microcode can create).

Microcode patches, while not loaded by a bootloader, *are* contained in most OSes (as well as the BIOS).  And the TXT architecture allows for an OEM to include SINIT in the BIOS flash (or a special HDD partition, etc.), but desktop BIOS flash space is usually very constrained and none of the OEMs have chosen to do this.  But even if they had, just like most BIOSes include a microcode patch, there is still value in system software being able to provide an updated version so that users don't have to re-flash their BIOS just to get the new module.

Joe
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists