linux-kernel - RE: [GIT PULL] x86/txt for v2.6.32

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 for Android: free password hash cracker in your pocket

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

Message-ID: <4F65016F6CB04E49BFFA15D4F7B798D9AC1C49D6@orsmsx506.amr.corp.intel.com>
Date:	Wed, 7 Oct 2009 09:47:10 -0700
From:	"Cihula, Joseph" <joseph.cihula@...el.com>
To:	Pavel Machek <pavel@....cz>, Roland Dreier <rdreier@...co.com>
CC:	Henrique de Moraes Holschuh <hmh@....eng.br>,
	"Wang, Shane" <shane.wang@...el.com>,
	Arjan van de Ven <arjan@...radead.org>,
	"H. Peter Anvin" <hpa@...or.com>,
	"Rafael J. Wysocki" <rjw@...k.pl>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Ingo Molnar <mingo@...e.hu>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: RE: [GIT PULL] x86/txt for v2.6.32

> From: Pavel Machek [mailto:pavel@....cz]
> Sent: Tuesday, October 06, 2009 1:13 AM
>
> On Sat 2009-10-03 13:44:22, Roland Dreier wrote:
> >
> >  > > > So I modify the RAM content so that BIOS does not think measured
> >  > > > environment existed before suspend?
> >
> >  > And it is ridiculously easy to pull off, too:
> >  > http://www.engadget.com/2008/02/21/cold-boot-disk-encryption-attack-is-shockingly-
> effective/
> >  >
> >  > Shows the attack being used to read sensitive keys, but you can use it also
> >  > to *modify* system running state (it will be more difficult, as you need to
> >  > remove and replace the RAM while on S3 instead of S5, but it should be
> >  > doable by someone who knows what he is doing).
> >
> > I believe the whole point of this TXT / S3 handling is that the resume
> > from S3 will then be able to detect that the contents of RAM have been
> > modified while the system was asleep.
>
> ...and you are able to read out any keys, etc. Maybe that's expected &
> ok, but Doc*/intel_txt.txt does not actually tell me what it protects
> against and is pretty much useless... making patches impossible to
> review.
>
> So... what does txt protect?

>From Documentation/intel_txt.txt:
        Intel TXT in Brief:
        o  Provides dynamic root of trust for measurement (DRTM)
        o  Data protection in case of improper shutdown
        o  Measurement and verification of launched environment

Intel TXT doesn't protect anything itself--it provides a foundation for software to provide protections and security.  tboot and the associated Linux patches do this.  The section of intel_txt.txt titled "Value Proposition for Linux or "Why should you care?"" tries to describe what is provided.

> Data integrity only?

Data integrity, yes, but not only.  The code also provides for DRTM-based measurements, data protection in case of improper shutdown, etc.

> Data privacy, too?

No.

> Who is it designed to protect against?
>
> Remote attacker?

Yes.

> Local user trying to subvert it?

No.

> ...and has soldering iron he's willing to use?
>
> ...and has soldering iron, osciloscope and PCI analyzer he's willing to use?

No and no.

> > TXT simply produces a reasonably trustworthy measurement of system
> > state.  If you modify RAM while the system is asleep, then you will not
> > be able to produce a measurement showing an unmodified system state.
>
> Well, actually I see some auditing to be done in proposed patches.

All comments are welcome.

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/