From mboxrd@z Thu Jan 1 00:00:00 1970 From: Matthew Garrett Subject: Re: MemoryOverwriteRequestControl Date: Tue, 5 Jul 2016 02:06:23 +0100 Message-ID: <20160705010622.GA7974@srcf.ucam.org> References: <1467667917.2288.23.camel@HansenPartnership.com> <20160704222609.GB5160@srcf.ucam.org> <1467680635.2288.36.camel@HansenPartnership.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <1467680635.2288.36.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 06:03:55PM -0700, James Bottomley wrote: > It's perhaps arguable that for parity we should set it when an > encrypted filesystem is mounted and unset it when they're all unmounted > (that implementation could be an entirely in-os thing for us ... > probably implemented as some type of "secrets held" reference count). > However, the point I was making is that anything that wants access to > a sealed or bound secret would likely also like to control this, so it > should be a property of the TSS (or at least the TSS should be a > participant in the implementation). We want to set it the moment anything secret lands in RAM. Tying it to TSS doesn't get us that. -- Matthew Garrett | mjg59-1xO5oi07KQx4cg9Nei1l7Q@public.gmane.org