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
Thanks /Ilias
Am 31.05.2019 um 17:18 schrieb Ilias Apalodimas ilias.apalodimas@linaro.org:
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.
Alex
On 5/31/19 5:33 PM, Alexander Graf wrote:
Am 31.05.2019 um 17:18 schrieb Ilias Apalodimas ilias.apalodimas@linaro.org:
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@lists.linaro.org
-
Alexander Graf -
Heinrich Schuchardt -
Ilias Apalodimas