From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1ghVd1-0002a4-94 for mharc-grub-devel@gnu.org; Thu, 10 Jan 2019 03:23:51 -0500 Received: from eggs.gnu.org ([209.51.188.92]:49288) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ghVcx-0002WL-SC for grub-devel@gnu.org; Thu, 10 Jan 2019 03:23:50 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ghVRt-000361-Hm for grub-devel@gnu.org; Thu, 10 Jan 2019 03:12:24 -0500 Received: from smtp2.provo.novell.com ([137.65.250.81]:33262) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1ghVRt-00035B-7h for grub-devel@gnu.org; Thu, 10 Jan 2019 03:12:21 -0500 Received: from mazu (prv-ext-foundry1int.gns.novell.com [137.65.251.240]) by smtp2.provo.novell.com with ESMTP (TLS encrypted); Thu, 10 Jan 2019 01:12:13 -0700 Date: Thu, 10 Jan 2019 16:12:08 +0800 From: Michael Chang To: grub-devel@gnu.org Cc: Alexander Graf , Ard Biesheuvel , Leif Lindholm , Peter Jones , Matthew Garrett , Benjamin Brunner Subject: Discuss support for the linux kernel's EFI Handover Protocol on x86 and ARM Message-ID: <20190110081208.GA5021@mazu> Mail-Followup-To: grub-devel@gnu.org, Alexander Graf , Ard Biesheuvel , Leif Lindholm , Peter Jones , Matthew Garrett , Benjamin Brunner MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.10.1 (2018-07-13) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 137.65.250.81 X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jan 2019 08:23:50 -0000 Hi, With the advent of new verifier framework and shim lock protocol support to the grub's community, we are driving to the world of UEFI Secure Boot, well, almost .. There is a missing piece in the puzzle remaining, that is booting linux kernel via it's own EFI Handover Protocol's entry. Strictly speaking, the interface is not part of the UEFI Secure Boot, but we have to use it to avoid problem of using UEFI LoadImage Protocol, which will not work with shim and it's Machine Owner Key (MOK) as they are not part of firmware's KEK and db. In other words, with the current state of implementation, ARM is still not able to support Secure Boot and will end up with security violation as long as LoadImage is performed to boot the kernel as firmware's blob. The shim-lock support turns out to be useless, unless we could change it to use some sort of kernel's own interface, like UEFI handover, is a good candidate for me (sorry I'm aware of any other choice for ARM). The x86 might be working with shim, since 32-bit entry is used. But IIUC linux kernel recommends efi handover entry than 32-bit for efi booting since it is less tied to bootloader and thus makes booting problem more easy and obvious to fix by the kernel itself. For that reason the support will be needed in the long run regardless secure boot since it provides better prospect than 32-bit entry. I think it is about time to discuss and figure out a common way to bring UEFI handover support to the x86 and ARM architectures both having UEFI running. Many downstream distributions have already been carrying diverged linuxefi patch for a long time and I think our ARM friends may not want to repeat the same story. :) Any idea and suggestion for the topic is welcome. Thanks, Michael