On 5/31/19 5:33 PM, Alexander Graf wrote: > > >> Am 31.05.2019 um 17:18 schrieb Ilias Apalodimas >> <[email protected]>: >> >> Hi Tom, >>> On Fri, May 31, 2019 at 11:05:20AM -0400, Tom Rini wrote: >>>> On Fri, May 31, 2019 at 02:40:32PM +0100, Steve McIntyre wrote: >>>> On Tue, May 28, 2019 at 02:04:23PM +0300, Ilias Apalodimas wrote: >>>>>>> >>>>>>> The tl;dr purpose of my e-mail was 'Is implementing UEFI Secure Boot >>>>>>> for the >>>>>>> EFI playloads >>>>>> >>>>>> I think that you'd better explain why you stick to *UEFI* secure boot. >>>>> >>>>> The main reason is distro support. Since distros use a number of >>>>> different ways >>>>> of booting up on arm boards, using UEFI is the obvious way to unify that >>>>> (and >>>>> alrady supported on some) regardless of the bootloader. UEFI secure boot >>>>> provides a common approach to security instead of 'per bootloader' >>>>> solutions >>>> >>>> Yup, absolutely (says the Debian EFI team lead) ... >>> >>> The other things we need to keep in mind is that (based on my own >>> experience implementing UEFI secure boot on an x8664 platform), we are >>> not looking at a case of "make an existing solution function on other >>> architectures" but rather "there's some good concepts here and an >>> implementation waiting to be figured out". >> >> We agree here. From Grant's proposal's #1 and #2, i'd prefer seeing something >> similar to #2 implemented. >> I'd prefer having the option to authenticate DTB/initramfs from the 'main >> bootloader', than delegating that to some EFI payload, mostly for >> fragmentation >> reasons > > Why can't a distro generate .efi files from dtb/initrd that just store the > updated versions into a table? Overriding / loading either would then be a > matter of executing a normal uefi binary - with all the security benefits > that brings. > > The only big concern I have with this (and similar approaches) is that we > would allow arbitrary combinations of DTB/kernel/initrd, which may allow an > attacker to load say a newer kernel with an inconsistent dtb, opening a > security hole. > > So maybe the real answer is a Linux make step that creates a self-contained > bundle consisting of all 3 or at least kernel&initrd? Distros / distributors > would then ship a full bundle. With the obvious sizing downsides.
"Linux make step" sounds strange to me. Do you refer to `update-initramfs`? The initramfs cannot be shipped neither with the kernel nor with the distribution as it contains user selected modules, fstab and other configuration files (e.g. for iSCSI). Regards Heinrich _______________________________________________ boot-architecture mailing list [email protected] https://lists.linaro.org/mailman/listinfo/boot-architecture
