From mboxrd@z Thu Jan 1 00:00:00 1970 From: Matthew Garrett Subject: Re: MemoryOverwriteRequestControl Date: Tue, 5 Jul 2016 03:40:23 +0100 Message-ID: <20160705024022.GA9292@srcf.ucam.org> References: <1467667917.2288.23.camel@HansenPartnership.com> <20160704222609.GB5160@srcf.ucam.org> <1467680635.2288.36.camel@HansenPartnership.com> <20160705010622.GA7974@srcf.ucam.org> <1467686108.2288.43.camel@HansenPartnership.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <1467686108.2288.43.camel-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk@public.gmane.org> Sender: linux-efi-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: James Bottomley Cc: Grant Likely , "linux-efi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , Jon Masters , Leif Lindholm , Ard Biesheuvel , Peter Jones List-Id: linux-efi@vger.kernel.org On Mon, Jul 04, 2016 at 07:35:08PM -0700, James Bottomley wrote: > On Tue, 2016-07-05 at 02:06 +0100, Matthew Garrett wrote: > > We want to set it the moment anything secret lands in RAM. Tying it > > to TSS doesn't get us that. > > Well, we do to an approximation: whenever Tspi_Data_Unbind/Unseal are > called secrets are dumped in RAM ... it's not the only time, but it's > one of the biggest. What the TSS doesn't know is when the secret is > safely disposed of again. It's one of the annoying lacuna in the > model: the TSS itself is great at managing stuff, but as soon as it > transmits secrets beyond itself, well, that's someone else's problem. dm-crypt secrets are typically unrelated to the TPM, so I really don't think the TSS is the right layer to be solving this. -- Matthew Garrett | mjg59-1xO5oi07KQx4cg9Nei1l7Q@public.gmane.org