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:   Sat, 5 Aug 2017 09:35:22 -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 Sat, Aug 5, 2017 at 2:50 AM, Ard Biesheuvel
<ard.biesheuvel@...aro.org> wrote:
> On 4 August 2017 at 22:20, Matthew Garrett <mjg59@...gle.com> wrote:
>> If a machine is reset while secrets are present in RAM, it may be
>> possible for code executed after the reboot to extract those secrets
>> from untouched memory. The Trusted Computing Group specified a mechanism
>> for requesting that the firmware clear all RAM on reset before booting
>> another OS. This is done by setting the MemoryOverwriteRequestControl
>> variable at startup. If userspace can ensure that all secrets are
>> removed as part of a controlled shutdown, it can reset this variable to
>> 0 before triggering a hardware reboot.
>>
>
> Shouldn't it be up to the kernel to decide whether this flag should be
> cleared after userspace has indicated to it that it thinks it has
> wiped all secrets from memory? The kernel itself may keep secrets as
> well, and we may still crash in the time window between userspace
> invoking shutdown and the kernel actually calling ResetSystem() in the
> firmware.

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.