linux-kernel - RE: [RFC][PATCH 0a/3] TXT: Intel(R) Trusted ExecutionTechnologysupport 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]

Date:	Thu, 9 Oct 2008 14:16:14 -0700
From:	"Cihula, Joseph" <joseph.cihula@...el.com>
To:	"Pavel Machek" <pavel@...e.cz>
Cc:	"Chris Wright" <chrisw@...s-sol.org>,
	<linux-kernel@...r.kernel.org>,
	"Wang, Shane" <shane.wang@...el.com>,
	"Wei, Gang" <gang.wei@...el.com>,
	"Van De Ven, Arjan" <arjan.van.de.ven@...el.com>,
	"Mallick, Asit K" <asit.k.mallick@...el.com>,
	"Nakajima, Jun" <jun.nakajima@...el.com>,
	"Chris Wright" <chrisw@...hat.com>,
	"Jan Beulich" <jbeulich@...ell.com>, <mingo@...e.hu>,
	<tytso@....edu>
Subject: RE: [RFC][PATCH 0a/3] TXT: Intel(R) Trusted ExecutionTechnologysupport for Linux - Overview

> From: Pavel Machek [mailto:pavel@...e.cz]
> Sent: Thursday, October 09, 2008 11:46 AM
> 
> > > > > You exit/reenter the trusted mode accross sleep... so any
guarantees
> > > > > "trusted" mode does are void, right?
> > > >
> > > > You exit from kernel to tboot on any shutdown, which handles the
proper
> > > > teardown of the measured env (meaning you also come back on via
tboot).
> > > > So things like saving tpm state, scrubbing secrets from memory,
etc.
> > >
> > > Aha, so instead sleep mode is useless because I'll have to remount
all
> > > the crypto filesystems and restart all the apps...
> >
> > Sleep mode works the same as it does today (caveat S4 issue which we
> > will fix), it just goes through the tboot code before putting the
> > platform HW into the appropriate state.  What this process is adding
is
> > that on resume, tboot will get control from BIOS instead of the
kernel.
> > Then tboot will re-launch the TXT environment before going back to
the
> > kernel at the kernel's expected S3 resume vector.  The
re-establishing
> > of the protected environment won't disrupt the subsequent kernel
resume
> > process.
> 
> No, I don't get it. So presumably useful thing to do is to seal my
> crypto partition so that only known-good kernel can access it?
> 
> But then, the crypto keys will be in ram during suspend/resume
> (because I have the filesystem mounted) => I loose any guarantees?

This goes to the threat model for S3.  The current code assumes that the
S3 resume process is trusted.  That is, the memory image will not be
compromised between the time tboot turns off TXT in order to put the
platform into S3 and the time TXT is re-launched.  For this model, the
purpose of re-launching is to re-establish the original PCR values and
the reset protection.

If stronger protection is desired, the apps that manage keys would need
to seal the keys to the current DRTM PCRs and then clear the plaintext
copies, before the system enters S3.  The tboot and Linux code would
also need to put a (U)MAC over all of the image (the kernel could UMAC
userspace and tboot would UMAC the kernel).  The UMAC that tboot
calculates would get sealed before entry into S3 and then unsealed and
validated upon resume.  OF course this adds time to both entry and
resume.

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/