Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1704714
| From | Matthew Garrett <mjg59@google.com> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [PATCH] Enable reset attack mitigation |
| Date | 2017-08-05 23:50 +0200 |
| Message-ID | <ubf7k-1Vj-13@gated-at.bofh.it> (permalink) |
| References | <uaSkq-3Xf-5@gated-at.bofh.it> <ub42d-3iq-1@gated-at.bofh.it> <ubahj-7nG-7@gated-at.bofh.it> <ubbdn-7Zt-1@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
On Sat, Aug 5, 2017 at 10:34 AM, Lukas Wunner <lukas@wunner.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.
Back to linux.kernel | Previous | Next — Previous in thread | Find similar | Unroll thread
[PATCH] Enable reset attack mitigation Matthew Garrett <mjg59@google.com> - 2017-08-04 23:30 +0200
Re: [PATCH] Enable reset attack mitigation Ard Biesheuvel <ard.biesheuvel@linaro.org> - 2017-08-05 12:00 +0200
Re: [PATCH] Enable reset attack mitigation Matthew Garrett <mjg59@google.com> - 2017-08-05 18:40 +0200
Re: [PATCH] Enable reset attack mitigation Lukas Wunner <lukas@wunner.de> - 2017-08-05 19:40 +0200
Re: [PATCH] Enable reset attack mitigation Matthew Garrett <mjg59@google.com> - 2017-08-05 23:50 +0200
csiph-web