Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752722AbdHRT5g (ORCPT ); Fri, 18 Aug 2017 15:57:36 -0400 Received: from mail-io0-f171.google.com ([209.85.223.171]:33309 "EHLO mail-io0-f171.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751586AbdHRT5d (ORCPT ); Fri, 18 Aug 2017 15:57:33 -0400 MIME-Version: 1.0 In-Reply-To: References: <20170804212010.15064-1-mjg59@google.com> From: Matthew Garrett Date: Fri, 18 Aug 2017 12:57:32 -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: 1380 Lines: 27 On Fri, Aug 18, 2017 at 12:29 PM, Ard Biesheuvel wrote: > On 18 August 2017 at 20:08, Matthew Garrett 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.