Re: [RFC v5][PATCH 0b/4] intel_txt: Intel(R) Trusted Execution Technology support for Linux - Details

[Pavel Machek <pavel@ucw.cz>]

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

There's additional problem with this: if Intel is bought by Microsoft
(or chinese government) next year, it may create & sign evil blob that
will subvert security of sinit. That's pretty unique/dangerous. (Maybe
FBI can get special signed version?)

While I mostly have to trust Intel from 2007, this expects me to trust
intel from 2021, too. Sounds dangerous. 
								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html