On Fri, Aug 18, 2017 at 12:08:34PM -0700, Matthew Garrett wrote: > On Fri, Aug 18, 2017 at 11:52 AM, Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx> wrote: > > So how would that work with, e.g., the keys for your encrypted file > > system? Surely, you can't expect the kernel to drop that secret when > > userland asks it to, so there will always be a window where userland > > has set the variable but the kernel is not ready to drop its secrets > > yet. > > If the kernel doesn't synchronously zero the key when dm-crypt is torn > down, that feels like a bug? In the case of a root filesystem layered atop dm-crypt, tearing down dm-crypt depends on userland, more specifically the init system. With systemd + dracut it's possible to pivot back into an initrd on shutdown and this allows for proper teardown of dm-crypt and subsequent wiping of the key material from memory. With initramfs-tools this is not possible and to the best of my knowledge the key material is still resident in memory on shutdown: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=778849 Another case where key material may still be resident are IPsec tunnels. Granted, user space could tear these down as well on shutdown but what if it doesn't? The patch itself seems to be of value, perhaps it can be moved forward if the commit message is rephrased to leave open the contentious issue if and when memory wiping by the firmware is disabled, to be discussed separately. I'd vote for a machanism whereby user space signals to the kernel that it no longer has secrets, and the kernel can then signal to the firmware that memory need not be cleared if it also no longer holds secrets. Just my 2 cents anyway. Thanks! Lukas -- 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
