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

[Daniel Kiper <daniel.kiper@xxxxxxxxxx>]

On Tue, Aug 25, 2015 at 06:09:09AM -0600, Jan Beulich wrote:
> >>> On 24.08.15 at 22:54, <daniel.kiper@xxxxxxxxxx> wrote:
> > On Mon, Aug 24, 2015 at 05:35:21AM -0600, Jan Beulich wrote:
> >> >>> On 22.08.15 at 15:59, <daniel.kiper@xxxxxxxxxx> wrote:
> >> > On Thu, Aug 20, 2015 at 09:39:39AM -0600, Jan Beulich wrote:
> >> >> >>> On 20.07.15 at 16:29, <daniel.kiper@xxxxxxxxxx> wrote:
> >> >> > Currently, PE file contains many sections which are not "linear" (one
> >> >> > after another without any holes) or even do not have representation
> >> >> > in a file (e.g. BSS). In theory there is a chance that we could build
> >> >> > proper PE file using current build system. However, it means that
> >> >>
> >> >> What is "improper" about the currently built PE file? And if there is
> >> >> anything improper, did you inform the binutils maintainers of the
> >> >> problem?
> >> >
> >> > From PE loader point of view everything is OK. However, current Xen PE
> >> > image (at least build on my machines) is not usable by multiboot (v1)
> >> > or multiboot2 protocol compatible loader because it is not linear (one
> >> > section does not live immediately after another without any voids).
> >>
> >> Again - either I'm missing something (and then your explanation is
> >> not good enough) or this is (as said above) a pointless adjustment.
> >
> > Let's focus on multiboot2 protocol (multiboot (v1) is similar to multiboot2
> > in discussed case). In general multiboot2 is able to load any file which
> > has:
> >   1. proper multiboot2 header in first 32 KiB of a given file,
> >   2. "the text and data segments must be consecutive in the OS image"
> >      (The Multiboot Specification version 1.6).
> >
> > This implies that we can e.g. build valid ELF file which is also multiboot2
> > protocol compatible image. And we does. However, we can go further.
> > Potentially we can build valid PE image which is also valid multiboot2
> > protocol image. Although current build method does not satisfy requirement
> > number 2 because, e.g.:
> >
> > Sections:
> > Idx Name          Size      VMA               LMA               File off
> > Algn
> >   0 .text         001513d0  ffff82d080200000  ffff82d080200000  00001000
> > 2**12
> >                                       ^^^^^^                    ^^^^^^^^
> >                   CONTENTS, ALLOC, LOAD, CODE
> >   1 .rodata       0004de12  ffff82d0803513e0  ffff82d0803513e0  00153000
> > 2**5
> >                                       ^^^^^^                    ^^^^^^^^
> >                   CONTENTS, ALLOC, LOAD, READONLY, DATA
> >
> > Hence, we must use special method to build PE image (I discussed that in
> > my earlier email in that topic) to do it compatible with multiboot2
> > protocol.
>
> And you realize that we use a "special method" for building the
> current "flat" ELF image too?

Yes, I know about that.

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

> >> >> > --- a/xen/arch/x86/efi/Makefile
> >> >> > +++ b/xen/arch/x86/efi/Makefile
> >> >> > @@ -1,14 +1,16 @@
> >> >> >  CFLAGS += -fshort-wchar
> >> >> >
> >> >> > -obj-y += stub.o
> >> >> > -
> >> >> > -create = test -e $(1) || touch -t 199901010000 $(1)
> >> >> > -
> >> >> >  efi := $(filter y,$(x86_64)$(shell rm -f disabled))
> >> >> >  efi := $(if $(efi),$(shell $(CC) $(filter-out $(CFLAGS-y) 
> >> >> > .%.d,$(CFLAGS)) -c check.c 2>disabled && echo y))
> >> >> >  efi := $(if $(efi),$(shell $(LD) -mi386pep --subsystem=10 -o 
> >> >> > check.efi heck.o >disabled && echo y))
> >> >> > -efi := $(if $(efi),$(shell rm disabled)y,$(shell $(call 
> >> >> > create,boot.init.o); $(call create,runtime.o)))
> >> >> > +efi := $(if $(efi),$(shell rm disabled)y)
> >> >> >
> >> >> > -extra-$(efi) += boot.init.o relocs-dummy.o runtime.o compat.o
> >> >> > +extra-y += relocs-dummy.o
> >> >>
> >> >> Why is this no longer extra-$(efi)?
> >> >
> >> > Because we need proper EFI code in xen.gz to support boot
> >> > via multiboot2 on EFI platforms.
> >>
> >> What would we need that for when not building an EFI-capable
> >> binary anyway?
> >
> > xen/arch/x86/efi/stub.c
>
> This is still too unspecific: I can't see any reference from that file
> to any of the symbols relocs-dummy.S provides.

Ahh... You are right, we do not need relocs-dummy.S to build
Xen image without EFI support. I will fix it.

Daniel

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