MemoryOverwriteRequestControl

MemoryOverwriteRequestControl

[Grant Likely]

Random question: Does anybody (kernel or distros) do anything with the
MemoryOverwriteRequestControl EFI variable? I was asked by a platform
engineer for input on what Linux needs, and I didn't have an answer
for him.

Reference: section 5 of
https://www.trustedcomputinggroup.org/wp-content/uploads/Platform-Reset-Attack-Mitigation-Specification.pdf

g.

Re: MemoryOverwriteRequestControl

[James Bottomley]

On Mon, 2016-07-04 at 20:37 +0100, Grant Likely wrote:
> Random question: Does anybody (kernel or distros) do anything with 
> the MemoryOverwriteRequestControl EFI variable? I was asked by a 
> platform engineer for input on what Linux needs, and I didn't have an 
> answer for him.

The usual answer for these cases is to do what Tianocore does.

Currently, the kernel does nothing with this, but you'd more expect
something in userspace to do something with it, probably a component of
the TSS.

> Reference: section 5 of
> https://www.trustedcomputinggroup.org/wp-content/uploads/Platform-Res
> et-Attack-Mitigation-Specification.pdf

That's a bit of an old Spec.  Microsoft has been busy updating this
stuff:

https://msdn.microsoft.com/en-us/windows/hardware/drivers/bringup/device-guard-requirements

Tianocore head seems to do all of this.

James

Re: MemoryOverwriteRequestControl

[Matthew Garrett]

On Mon, Jul 04, 2016 at 02:31:57PM -0700, James Bottomley wrote:

> Currently, the kernel does nothing with this, but you'd more expect
> something in userspace to do something with it, probably a component of
> the TSS.

The OS loader is expected to set MOR to 1, so given the boot stub 
there's need for kernel support. A "correct" implementation would also 
involve the kernel clearing all its secrets before reboot and then 
setting it back to 0, so I don't think we can just punt responsibility 
to userspace.

-- 
Matthew Garrett | mjg59-1xO5oi07KQx4cg9Nei1l7Q@public.gmane.org

Re: MemoryOverwriteRequestControl

[James Bottomley]

On Mon, 2016-07-04 at 23:26 +0100, Matthew Garrett wrote:
> On Mon, Jul 04, 2016 at 02:31:57PM -0700, James Bottomley wrote:
> 
> > Currently, the kernel does nothing with this, but you'd more expect
> > something in userspace to do something with it, probably a
> > component of
> > the TSS.
> 
> The OS loader is expected to set MOR to 1, so given the boot stub 
> there's need for kernel support. A "correct" implementation would 
> also involve the kernel clearing all its secrets before reboot and 
> then setting it back to 0, so I don't think we can just punt
> responsibility to userspace.

Yes, but the whole thing is a bit of a windows ism.  In windows,
bitlocker is invoked from the loader, which is when the secret they're
worried about is unbound.  Windows has to operate like this because of
the drive letter problem.

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).

To be honest, this is all a bit smoke and mirrors security until we've
got a way to protect secrets across suspend/resume because that's the
biggest vulnerability window for theft and the MOR protocols do nothing
to protect this.

James

Re: MemoryOverwriteRequestControl

[Matthew Garrett]

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

Re: MemoryOverwriteRequestControl

[James Bottomley]

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

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.

James

Re: MemoryOverwriteRequestControl

[Matthew Garrett]

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

Re: MemoryOverwriteRequestControl

[James Bottomley]

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

Re: MemoryOverwriteRequestControl

[Matthew Garrett]

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. 
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)

-- 
Matthew Garrett | mjg59-1xO5oi07KQx4cg9Nei1l7Q@public.gmane.org

Re: MemoryOverwriteRequestControl

[James Bottomley]

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

Re: MemoryOverwriteRequestControl

[Matthew Garrett]

On Mon, Jul 04, 2016 at 08:37:16PM +0100, Grant Likely wrote:
> Random question: Does anybody (kernel or distros) do anything with the
> MemoryOverwriteRequestControl EFI variable? I was asked by a platform
> engineer for input on what Linux needs, and I didn't have an answer
> for him.

I'm not aware of any Linux use of this at present.

-- 
Matthew Garrett | mjg59-1xO5oi07KQx4cg9Nei1l7Q@public.gmane.org