Hi Tom,
Continuing the discussions we had on securing the boot flow and OS as much as possible, we came up with the following idea.
We are currently sorting out what's needed to add UEFI Secure Boot in U-Boot. This will cover the next payload (shim/grub2/shim depending on board needs).
In order to provide better overall security for the OS we'll need to at least verify DTB (if provided externally), initramfs and kernel modules.
- For the kernel modules we can use kernel module signing facilities [1]
- In case someone wants to provide an external DTB, we can use FIT images
to secure that. The FIT images will contain the DTB(s) we need. Those will only be used if the authentication process succeeds. This will allow us to verify DTBs without introducing any new functionality to U-Boot. 3. We need to verify initramfs as well. This can be accomplished in various ways. Packing kernel + initramfs or using dm-verity are the two obvious ones but we are open to suggestions.
For #3, making use of FIT images should be investigated seriously that already allows for what you're asking about.
Sure, thanks for the heads up. I had a sentence saying '#3 can deploy similar methods to #2" on my initial e-mail, but removed it right before sending. It makes a lot of sense to me to keep similar functionality, as long as we can keep the stored keys (to verify signatures) in small numbers.
Sure. One thing I want to make sure people understand is that U-Boot already supports a verified boot scheme including reaching out to ROM where applicable and has for a number of years.
I think we are exaclty on the same page here!
The tl;dr purpose of my e-mail was 'Is implementing UEFI Secure Boot for the EFI playloads and use *existing* tools for the rest doable?'. I think the answer is yes. If it is i don't think it makes any sense at all to implement something new
Thanks /Ilias
Ilias,
On Mon, May 27, 2019 at 12:09:26PM +0300, Ilias Apalodimas wrote:
Hi Tom,
Continuing the discussions we had on securing the boot flow and OS as much as possible, we came up with the following idea.
We are currently sorting out what's needed to add UEFI Secure Boot in U-Boot. This will cover the next payload (shim/grub2/shim depending on board needs).
In order to provide better overall security for the OS we'll need to at least verify DTB (if provided externally), initramfs and kernel modules.
- For the kernel modules we can use kernel module signing facilities [1]
- In case someone wants to provide an external DTB, we can use FIT images
to secure that. The FIT images will contain the DTB(s) we need. Those will only be used if the authentication process succeeds. This will allow us to verify DTBs without introducing any new functionality to U-Boot. 3. We need to verify initramfs as well. This can be accomplished in various ways. Packing kernel + initramfs or using dm-verity are the two obvious ones but we are open to suggestions.
For #3, making use of FIT images should be investigated seriously that already allows for what you're asking about.
Sure, thanks for the heads up. I had a sentence saying '#3 can deploy similar methods to #2" on my initial e-mail, but removed it right before sending. It makes a lot of sense to me to keep similar functionality, as long as we can keep the stored keys (to verify signatures) in small numbers.
Sure. One thing I want to make sure people understand is that U-Boot already supports a verified boot scheme including reaching out to ROM where applicable and has for a number of years.
I think we are exaclty on the same page here!
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.
-Takahiro Akashi
and use *existing* tools for the rest doable?'. I think the answer is yes. If it is i don't think it makes any sense at all to implement something new
Thanks /Ilias _______________________________________________ boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture
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
Thanks /Ilias
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) ...
boot-architecture@lists.linaro.org
-
AKASHI Takahiro -
Ilias Apalodimas -
Steve McIntyre