linux-kernel - Re: [PATCH] Enable reset attack mitigation

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Fri, 18 Aug 2017 22:37:26 +0200
From:   Lukas Wunner <lukas@...ner.de>
To:     Matthew Garrett <mjg59@...gle.com>
Cc:     Ard Biesheuvel <ard.biesheuvel@...aro.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-efi@...r.kernel.org" <linux-efi@...r.kernel.org>,
        Matt Fleming <matt@...eblueprint.co.uk>
Subject: Re: [PATCH] Enable reset attack mitigation

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@...aro.org> 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