Re: MemoryOverwriteRequestControl

[James Bottomley <James.Bottomley-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk@public.gmane.org>]

On Tue, 2016-07-05 at 03:40 +0100, Matthew Garrett wrote:
> 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.

Not in theory: the MOR protocol is supposed to protect arbitrary
unprotected secrets in memory.  I accept that in practice, it was
designed to protect a single secret: the bitlocker encryption key.

If all we're after in Linux is matching the windows use case, then
protecting disc encryption keys (not just dm-crypt, we'd need ecryptfs
as well and possibly the new ext4 ecryptfs integration) will do. 
 However, being Linux, I was just wondering if we couldn't actually do
more what the spirit of MOR was designed for (i.e. protecting arbitrary
secrets in memory).

James