Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752697AbdHEVlY (ORCPT ); Sat, 5 Aug 2017 17:41:24 -0400 Received: from mail-io0-f182.google.com ([209.85.223.182]:36446 "EHLO mail-io0-f182.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751834AbdHEVlW (ORCPT ); Sat, 5 Aug 2017 17:41:22 -0400 MIME-Version: 1.0 In-Reply-To: <20170805173410.GB8872@wunner.de> References: <20170804212010.15064-1-mjg59@google.com> <20170805173410.GB8872@wunner.de> From: Matthew Garrett Date: Sat, 5 Aug 2017 14:41:21 -0700 Message-ID: Subject: Re: [PATCH] Enable reset attack mitigation To: Lukas Wunner Cc: Ard Biesheuvel , "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: 810 Lines: 16 On Sat, Aug 5, 2017 at 10:34 AM, Lukas Wunner wrote: > Just an innocent question from a bystander, what's the downside of > unconditionally requesting that memory be overwritten? Does it > prolong reboot noticeably? Yes, it's just to avoid stalling reboot for as long as it takes to clear RAM. > I've also wondered why you've chosen to put this in a separate file > rather than the existing secureboot.c, my naive understanding is that > TPM and SecureBoot is related but I'm not an expert on this. It would > allow you to reuse the existing get_efi_var() macro. It's not related to Secure Boot (systems can have TPMs but not Secure Boot, and vice versa), the spec is managed by a different body (TCG rather than UEFI), and there'll be more TPM-related code for the boot stub in future.