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 14:41:21 -0700
From:   Matthew Garrett <mjg59@...gle.com>
To:     Lukas Wunner <lukas@...ner.de>
Cc:     Ard Biesheuvel <ard.biesheuvel@...aro.org>,
        "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 10:34 AM, Lukas Wunner <lukas@...ner.de> 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.