From: Patrick Ohly <patrick.ohly@intel.com>
To: Ricardo Neri <ricardo.neri-calderon@linux.intel.com>
Cc: openembedded-core@lists.openembedded.org
Subject: Re: [PATCH 6/9] ovmf_git.bb: enable Secure Boot
Date: Wed, 04 Jan 2017 11:10:28 +0100 [thread overview]
Message-ID: <1483524628.28169.41.camel@intel.com> (raw)
In-Reply-To: <1482965680.106950.67.camel@ranerica-desktop>
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.
next prev parent reply other threads:[~2017-01-04 10:10 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-12-21 13:11 [PATCH 0/9] UEFI + Secure Boot + qemu Patrick Ohly
2016-12-21 13:11 ` [PATCH 1/9] ovmf: move from meta-luv to OE-core Patrick Ohly
2016-12-28 2:58 ` Ricardo Neri
2016-12-21 13:11 ` [PATCH 2/9] iasl: " Patrick Ohly
2016-12-21 14:11 ` Fathi Boudra
2016-12-21 15:38 ` Patrick Ohly
2016-12-21 18:17 ` Fathi Boudra
2016-12-28 3:08 ` Ricardo Neri
2016-12-21 13:11 ` [PATCH 3/9] ovmf: explicitly depend on nasm-native Patrick Ohly
[not found] ` <1482893989.106950.45.camel@ranerica-desktop>
2017-01-04 12:56 ` Patrick Ohly
2016-12-21 13:11 ` [PATCH 4/9] ovmf: deploy firmware in image directory Patrick Ohly
2016-12-28 3:12 ` Ricardo Neri
2016-12-28 21:38 ` Ricardo Neri
2016-12-28 23:25 ` Ricardo Neri
2017-01-04 10:01 ` Patrick Ohly
2017-01-10 3:50 ` Ricardo Neri
2017-01-10 7:32 ` Patrick Ohly
2016-12-21 13:11 ` [PATCH 5/9] ovmf_git.bb: enable parallel compilation Patrick Ohly
2016-12-28 3:17 ` Ricardo Neri
2016-12-21 13:11 ` [PATCH 6/9] ovmf_git.bb: enable Secure Boot Patrick Ohly
2016-12-28 22:54 ` Ricardo Neri
2017-01-04 10:10 ` Patrick Ohly [this message]
2017-01-10 3:51 ` Ricardo Neri
2016-12-21 13:11 ` [PATCH 7/9] runqemu: let command line parameters override defaults Patrick Ohly
2016-12-21 13:11 ` [PATCH 8/9] runqemu: support UEFI with OVMF firmware Patrick Ohly
2016-12-28 23:33 ` Ricardo Neri
2017-01-04 9:43 ` Patrick Ohly
2017-01-10 3:50 ` Ricardo Neri
2017-01-10 7:29 ` Patrick Ohly
2016-12-21 13:11 ` [PATCH 9/9] ovmf: build image which enrolls standard keys Patrick Ohly
2016-12-21 14:19 ` [PATCH 0/9] UEFI + Secure Boot + qemu Fathi Boudra
2016-12-28 2:56 ` Ricardo Neri
2016-12-28 19:27 ` Patrick Ohly
2016-12-28 23:26 ` Ricardo Neri
2016-12-28 2:55 ` Ricardo Neri
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1483524628.28169.41.camel@intel.com \
--to=patrick.ohly@intel.com \
--cc=openembedded-core@lists.openembedded.org \
--cc=ricardo.neri-calderon@linux.intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox