Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752158AbdHEQfZ (ORCPT ); Sat, 5 Aug 2017 12:35:25 -0400 Received: from mail-io0-f174.google.com ([209.85.223.174]:37845 "EHLO mail-io0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751514AbdHEQfX (ORCPT ); Sat, 5 Aug 2017 12:35:23 -0400 MIME-Version: 1.0 In-Reply-To: References: <20170804212010.15064-1-mjg59@google.com> From: Matthew Garrett Date: Sat, 5 Aug 2017 09:35:22 -0700 Message-ID: Subject: Re: [PATCH] Enable reset attack mitigation To: Ard Biesheuvel Cc: "linux-kernel@vger.kernel.org" , "linux-efi@vger.kernel.org" , Matt Fleming Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1829 Lines: 31 On Sat, Aug 5, 2017 at 2:50 AM, Ard Biesheuvel wrote: > On 4 August 2017 at 22:20, Matthew Garrett 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.