Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752038AbdHRUh3 (ORCPT ); Fri, 18 Aug 2017 16:37:29 -0400 Received: from mailout3.hostsharing.net ([176.9.242.54]:45475 "EHLO mailout3.hostsharing.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751126AbdHRUh2 (ORCPT ); Fri, 18 Aug 2017 16:37:28 -0400 Date: Fri, 18 Aug 2017 22:37:26 +0200 From: Lukas Wunner To: Matthew Garrett Cc: Ard Biesheuvel , "linux-kernel@vger.kernel.org" , "linux-efi@vger.kernel.org" , Matt Fleming Subject: Re: [PATCH] Enable reset attack mitigation Message-ID: <20170818203726.GA10696@wunner.de> References: <20170804212010.15064-1-mjg59@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1704 Lines: 37 On Fri, Aug 18, 2017 at 12:08:34PM -0700, Matthew Garrett wrote: > On Fri, Aug 18, 2017 at 11:52 AM, Ard Biesheuvel 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