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