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 for Android: free password hash cracker in your pocket

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

Message-ID: <CAKv+Gu-DpEfAXjtkeYCe8pL9Un6yBvanJsYVSXtRQZmRa++Arw@mail.gmail.com>
Date:   Fri, 18 Aug 2017 21:19:48 +0100
From:   Ard Biesheuvel <ard.biesheuvel@...aro.org>
To:     Matthew Garrett <mjg59@...gle.com>
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 18 August 2017 at 20:57, Matthew Garrett <mjg59@...gle.com> wrote:
> 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.
>

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.