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 20:29:51 +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:08, Matthew Garrett <mjg59@...gle.com> wrote:
> On Fri, Aug 18, 2017 at 11:52 AM, Ard Biesheuvel
> <ard.biesheuvel@...aro.org> wrote:
>> On 4 August 2017 at 22:20, Matthew Garrett <mjg59@...gle.com> wrote:
>>> + * Enable reboot attack mitigation. This requests that the firmware clear the
>>> + * RAM on next reboot before proceeding with boot, ensuring that any secrets
>>> + * are cleared. If userland has ensured that all secrets have bene removed
>>
>> s/bene/been/
>
> Thanks.
>
>>> +       set_efi_var(efi_MemoryOverWriteRequest_name, &var_guid,
>>> +                   EFI_VARIABLE_NON_VOLATILE |
>>> +                   EFI_VARIABLE_BOOTSERVICE_ACCESS |
>>> +                   EFI_VARIABLE_RUNTIME_ACCESS, sizeof(val), val);
>>
>> Shouldn't this be &val?
>
> Ooh, good catch - not sure how that got eaten.
>
>>> What's the threat model? If there's no way for userland to ask the
>>> kernel to drop any secrets it still holds, that seems like a problem
>>> in any case. If the concern is that someone may be able to clear the
>>> flag and then reboot in order to deliberately attempt to obtain kernel
>>> secrets then there's no hugely easy way around this without special
>>> casing the variable and preventing userland from being able to modify
>>> it. There's a MemoryOverwriteRequestLock spec from Microsoft that
>>> provides a mechanism for this (the firmware and the OS configure a
>>> shared secret that controls access to MemoryOverwriteRequestControl,
>>> so we'd keep that in the kernel and clear it on reboot), but that's
>>> not implemented everywhere and we'd still want to base on top of this.
>>
>> 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?

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).

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?