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] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 18 Aug 2017 12:57:32 -0700
From:   Matthew Garrett <mjg59@...gle.com>
To:     Ard Biesheuvel <ard.biesheuvel@...aro.org>
Cc:     "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:29 PM, Ard Biesheuvel
<ard.biesheuvel@...aro.org> wrote:
> On 18 August 2017 at 20:08, Matthew Garrett <mjg59@...gle.com> 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.