[OE-core] [PATCH 6/9] ovmf_git.bb: enable Secure Boot

Patrick Ohly patrick.ohly at intel.com
Wed Jan 4 10:10:28 UTC 2017


On Wed, 2016-12-28 at 14:54 -0800, Ricardo Neri wrote:
> On Wed, 2016-12-21 at 14:11 +0100, Patrick Ohly wrote:
> > The recipe now compiles OVMF twice, once without Secure Boot, once
> > with. This is the same approach as in
> > https://src.fedoraproject.org/cgit/rpms/edk2.git/tree/edk2.spec
> 
> Besides the fact that Fedora does it, is there a particular reason to
> build twice?

The ${build_dir}/FV/OVMF.fd file changes depending on the configuration.
There's only one such file after a build.

>  On my side, I am able to build with secure boot with a
> single build. Also, the Ubuntu documentation does not mention that two
> builds are needed [1].

Can you build with and without secure boot in a single build? I wasn't
sure how to achieve that, so I just copied what Fedora does.

> Also, I think it would be nice if we could choose between to not have
> secure boot at all for OVMF. Maybe this could be achieved by having a
> common ovmf.inc and two ovmf_git.bb and ovmf_sb_git.bb with the
> different the specific things to support secure boot or not. Maybe all
> that is needed in the secure boot recipe are the extra variables for
> OpenSSL and a prepend to do_compile_class-target with the OpenSSL
> patching. Something to ponder.

I think I would prefer to have a single recipe with a PACKAGECONFIG for
secure boot. Having different recipes doesn't scale when adding more
such options. If you agree, then I'll add that.

> > +    ( cd ${S}/CryptoPkg/Library/OpensslLib/ && ./Install.sh )
> > +    ${S}/OvmfPkg/build.sh $PARALLEL_JOBS -a $OVMF_ARCH -b RELEASE -t ${FIXED_GCCVER} ${OVMF_SECURE_BOOT_FLAGS}
> > +    ln ${build_dir}/FV/OVMF.fd ${WORKDIR}/ovmf/OVMF.secboot.fd
> 
> At this point both ${WORKDIR}/ovmf/OVMF.secboot.fd and
> ${WORKDIR}/ovmf/OVMF.fd will be linked to the same OVMF.fd with secure
> boot support. Maybe this could be fixed by copying the files rather than
> creating a symbolic link.

This is intentionally a hardlink, not a symbolic link, exactly because
of the problem you mentioned ;-)

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






More information about the Openembedded-core mailing list