Re: MemoryOverwriteRequestControl

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

On Tue, 2016-07-05 at 04:03 +0100, Matthew Garrett wrote:
> On Mon, Jul 04, 2016 at 07:58:51PM -0700, James Bottomley wrote:
> > On Tue, 2016-07-05 at 03:40 +0100, Matthew Garrett wrote:
> > > 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.
> 
> I think we may be miscommunicating slightly. If MOR is intended to 
> protect arbitrary secrets then it needs to protect secrets that are 
> unrelated to the TPM - that means that TSS integration isn't
> sufficient. 

I agree: necessary but not sufficient.

> Unless we can guarantee that every piece of userspace is behaving 
> correctly, that probably means setting MOR in kernel init and letting
> userspace turn it off if it's been audited to handle things 
> appropriately (and having the kernel ignore that request if it has 
> its own secrets it needs to protect)

Well, no, I was thinking, as I said before, of a kernel secrets
counter.  MOR Control doesn't need to be set in init; merely when the
first secret is exposed.  It can be reset when the last one is
shredded.  We need a user space per process interface to this so that
processes can also declare secret exposure and shredding.  For dmcrypt,
first exposure is the dm device setup and shredding the teardown, so
it's fairly long lived.

However, there's still the problem of secrets and suspend/resume.  The
best I can come up with there is to have memory regions declared as
protected (in the kernel and per process) and encrypt them all on
suspend.  The problem, on resume, is getting enough up that we can ask
for the password, but not so much that it requires an encrypted
resource.  This is the problem windows couldn't solve, but I think
we're a bit better placed.

James