[meta-intel] [PATCH RFC 0/4] Super simple secure boot implementation not requiring combo app

[Patrick Ohly]

On Tue, 2017-07-18 at 15:06 -0700, Cal Sullivan wrote:
> 
> 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.

Yes, but typically a build only has one kernel. Due to the separation
between distro and BSP, the distro (which defines the image and
initramfs for it) might not even know which kernel was chosen by the
developer. So effectively a distro would have to set INITRAMFS_IMAGE
globally for all kernels in the distro config.

For the record, in practice refkit currently only has one initramfs and
parametrizes it via per-image boot parameters. But that's just because
we took some shortcuts. Defining different initramfs versions with just
the content that they need for each image would result in smaller and
faster images.

Speaking of boot parameters, where does systemd-boot get them in this
simple secure boot implementation, and are they protected against
modifications by an attacker?

>  That's 
> still very good though,

"not" very good, right? ;-}

>  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.

Exactly.

-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.