On 18 August 2017 at 20:57, Matthew Garrett <mjg59@xxxxxxxxxx> wrote: > 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. > OK, fair enough. >> 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. OK. I will get it queued. No need to resend, I can apply the fixes locally. -- 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
