Re: [Xen-devel] [PATCH v2 10/23] efi: build xen.gz with EFI code

[Daniel Kiper <daniel.kiper@xxxxxxxxxx>]

On Wed, Aug 26, 2015 at 12:46:22AM -0600, Jan Beulich wrote:
> >>> On 25.08.15 at 18:31, <daniel.kiper@xxxxxxxxxx> wrote:
> > On Tue, Aug 25, 2015 at 06:09:09AM -0600, Jan Beulich wrote:
> >> >>> On 24.08.15 at 22:54, <daniel.kiper@xxxxxxxxxx> wrote:

[...]

> >> And you realize that we use a "special method" for building the
> >> current "flat" ELF image too?
> >
> > Yes, I know about that.
>
> And with that I wonder ...
>
> >> > This way one file could be loaded by native PE loader, mulitboot (v1)
> >> > protocol
> >> > (it requires relevant header but it does not interfere with PE and
> >> > multiboot2
> >> > protocol stuff) and mutliboot2 protocol compatible loaders. Additionally,
> >> > if it is signed with Secure Boot signature then potentially signature 
> >> > could
> >> > be verified by UEFI itself and e.g. GRUB2. However, as I said earlier 
> >> > this
> >> > requires more work and this is next step which I am going to do after
> >> > applying
> >> > this series. Currently I am going to embed EFI support into ELF file 
> >> > because
> >> > it is easy (less changes; currently used ELF file has required properties
> >> > because multiboot (v1) which we use has similar requirements like 
> >> > multiboot2
> >> > protocol) to make it compatible with multiboot2 protocol.
> >>
> >> I think whether what you do now makes sense depends on the
> >> ultimate goal: If we want a single binary usable for all three cases,
> >> then while yes, having EFI code available in the ELF image makes
> >> sense, using an ELF Image won't work. And we can't have an
> >> image being both ELF and PE. Hence the goal ought to be to have
> >> a single PE image, and with that the direction you move seems
> >> wrong.
> >
> > It depends how we want to generate proper PE file. There are two options.
> >
> > We can put manually proper PE header into xen/arch/x86/boot/head.S (maybe
> > with some additional needed stuff). Then after build we will have ELF file
> > which is loadable by multiboot protocols and has extra PE header. Of course
> > it is unusable directly by EFI loader. However, using simple objcopy we can
> > extract all interesting stuff from ELF file. This way we get proper PE file
> > which is usable by three different boot protocols. Going that way we can
> > also remove strict dependency on exact version of binutils which must have
> > enabled i386pep support if we wish to build PE image.
> >
> > Potentially we can choose second way and build proper PE image using ld and
> > objcopy/objdump tools with proper options. However, this require more work
> > (maybe we will be forced to build something similar to mkelf32) and we bind
> > Xen build machinery more tightly with exact version of binutils which is
> > not nice.
> >
> > So, I decided to choose option #1.
>
> ... why there's no option #3 here: Build a suitable PE image using a
> tool similar to mkelf32 _without_ involving ld/objcopy (i.e. straight
> from the full ELF binary that mkelf32 today uses as its input).

This is variant of #1 and make sense too. However, this way we do not get
extra PE header in ELF file which is also good.

> > It looks simpler because we have a lot of
> > needed stuff in place (e.g. Xen ELF image is currently in format usable by
> > multiboot protocols). However, I think that in first step we should add EFI
> > code to xen.gz because we want to load Xen using GRUB2 on EFI platforms
> > ASAP.
> > This patch allows us to do that. Later after getting this feature into
> > upstream
> > we can focus on building proper PE image with multiboot protocols support
> > embedded in it.
>
> But for whatever we do now we should keep in mind what the end
> goal is, and at least avoid making it more cumbersome to reach that
> end goal. And in the end I'm not sure not going the full way at once

#1 and #3 need EFI code in xen.gz. So, I do not think that we do anything
wrong adding this functionality here because we need it for GRUB2 support
on EFI platforms too. Hence, both things benefit from that change but one
does not depend on another.

> will actually turn out to be the easier route.

Do you suggest that I should put this functionality (PE with multiboot
headers) on top of this patch series? Well, it is possible but this
series is big and I would like to avoid to make it bigger. I prefer to
get current patches into Xen tree and then work on new features (it
should not take so long because as I can see we almost agreed most
of stuff in that case). Or if at least half patches of current series
will be accepted (as I can see there is a chance to do that with v3)
then I can work on this functionality and put it on top of second not
applied part. Does it make sense?

Daniel

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel