Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752520AbdHRUTv (ORCPT ); Fri, 18 Aug 2017 16:19:51 -0400 Received: from mail-io0-f174.google.com ([209.85.223.174]:37608 "EHLO mail-io0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751852AbdHRUTt (ORCPT ); Fri, 18 Aug 2017 16:19:49 -0400 MIME-Version: 1.0 In-Reply-To: References: <20170804212010.15064-1-mjg59@google.com> From: Ard Biesheuvel Date: Fri, 18 Aug 2017 21:19:48 +0100 Message-ID: Subject: Re: [PATCH] Enable reset attack mitigation To: Matthew Garrett 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: 1585 Lines: 33 On 18 August 2017 at 20:57, Matthew Garrett wrote: > 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. > 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.