On 07/18/2017 01:58 PM, Patrick Ohly wrote:
On Tue, 2017-07-18 at 13:32 -0700, Cal Sullivan wrote:
On 07/16/2017 11:26 PM, Patrick Ohly wrote:
On Fri, 2017-07-14 at 19:11 -0700, California Sullivan wrote:
I'm not sure why I never tried just signing the kernel and systemd-boot,
but it works. If either one is not signed, it causes gives a security
violation error.
A con of this implementation is that unlike the combo app, we don't
inherently validate the initrd. In the future we could require that
an initrd is not used with secure boot unless the combo app is chosen.
A lot of functionality in refkit (and elsewhere) depends on an an
initramfs, like setting up dm-verity, dm-crypt/LUKS and OSTree. I
consider not supporting an initramfs a deal breaker. It might be good
enough for some systems, but I'm not sure about that.
I misspoke a bit in my message here. The combo app essentially uses an
initramfs built into the kernel rather than an initrd, and such a thing
should still work with this method (via INITRAMFS_IMAGE_BUNDLE and
INITRAMFS_IMAGE variables).
This puts the initramfs into the kernel, right?
That's less flexible than the combo app, because with the combo app one
can define kernel and initramfs separately for each image, whereas
putting the initramfs into the kernel can one be done once per build,
i.e. the same initramfs must be used for the entire build.
Multiconfig might help here, but is probably harder to get right and
manage.
I believe a different initramfs can be defined for each kernel. That's
still very good though, as you'd need a different kernel recipe for each
image target you want a different initramfs on. Conceptually it actually
makes sense since the resulting kernel is different, but it could
quickly get out of hand when we start getting requests for every kernel
+ initramfs combination under the sun.
---
Cal
--
_______________________________________________
meta-intel mailing list
[email protected]
https://lists.yoctoproject.org/listinfo/meta-intel
