All of lore.kernel.org
 help / color / mirror / Atom feed
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.





  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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.