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 -- To unsubscribe from this list: send the line "unsubscribe linux-efi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
