On Fri, Aug 18, 2017 at 12:29 PM, Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx> wrote: > On 18 August 2017 at 20:08, Matthew Garrett <mjg59@xxxxxxxxxx> wrote: >> If the kernel doesn't synchronously zero the key when dm-crypt is torn >> down, that feels like a bug? > > Of course it should. But that is not the point. The point is that > userland is in no position to decide whether or not memory has been > sufficiently cleaned so that the firmware can omit wiping all of it > (in case you care enough about your secrets to enable that feature in > the first place). The kernel is in no position to decide whether or not userland has disposed of secrets either - at some point you need to trust a component, and I have more faith that the kernel will do the right thing. The only other option here seems to be a double opt-in (ie, have userland assert that it's cleaned up, have the kernel set the flag at reset time) but we're still assuming that the kernel is behaving correctly, and if we assume that the kernel is behaving correctly then we can just let userland set the flag anyway. > Given that the string 'MemoryOverWriteRequest' does not appear in > today's EDK2, I don't suppose there is any urgency wrt getting this > queued for v4.14? It's not implemented in EDK2, but it's in pretty much every vendor implementation. All the machines I have here support this already. -- 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
