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