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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20090624144134.GB1512@ucw.cz>
Date:	Wed, 24 Jun 2009 16:41:34 +0200
From:	Pavel Machek <pavel@....cz>
To:	"Cihula, Joseph" <joseph.cihula@...el.com>
Cc:	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Arjan van de Ven <arjan@...ux.intel.com>,
	Dave Jones <davej@...hat.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"mingo@...e.hu" <mingo@...e.hu>, "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


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