[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 5 May 2020 10:29:05 -0700
From: Matthew Garrett <mjg59@...gle.com>
To: Daniel Kiper <daniel.kiper@...cle.com>
Cc: The development of GNU GRUB <grub-devel@....org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
trenchboot-devel@...glegroups.com,
"the arch/x86 maintainers" <x86@...nel.org>,
alexander.burmashev@...cle.com,
Andrew Cooper <andrew.cooper3@...rix.com>,
Ard Biesheuvel <ard.biesheuvel@...aro.org>,
"Daniel P. Smith" <dpsmith@...rtussolutions.com>,
eric.snowberg@...cle.com,
Javier Martinez Canillas <javierm@...hat.com>,
kanth.ghatraju@...cle.com, konrad.wilk@...cle.com,
krystian.hebel@...eb.com, lukasz.hawrylko@...ux.intel.com,
michal.zygowski@...eb.com,
"Vladimir 'phcoder' Serbinenko" <phcoder@...il.com>,
pirot.krol@...eb.com, Peter Jones <pjones@...hat.com>,
Ross Philipson <ross.philipson@...cle.com>
Subject: Re: [GRUB PATCH RFC 12/18] i386/efi: Report UEFI Secure Boot status
to the Linux kernel
On Mon, May 4, 2020 at 4:25 PM Daniel Kiper <daniel.kiper@...cle.com> wrote:
>
> Otherwise the kernel does not know its state and cannot enable various
> security features depending on UEFI Secure Boot.
I think this needs more context. If the kernel is loaded via the EFI
boot stub, the kernel is aware of the UEFI secure boot state. Why
duplicate this functionality in order to avoid the EFI stub?
Powered by blists - more mailing lists