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

[Daniel Kiper <daniel.kiper@xxxxxxxxxx>]

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:
> >> > Build xen.gz with EFI code. We need this to support multiboot2
> >> > protocol on EFI platforms.
> >> >
> >> > If we wish to load not ELF file using multiboot (v1) or multiboot2 then
> >>
> >> DYM "a non-ELF file"?
> >>
> >> > it must contain "linear" (or "flat") representation of code and data.
> >>
> >> Why? Please don't just put out statements, but also reasons (i.e.
> >> at least which component is unable to deal with the current [valid
> >> afaict] PE image we have).
> >
> > This is a requirement of multiboot (v1) or multiboot2 protocol. They both
> > know nothing about PE image format.
>
> And hence how specifically we arrange data inside the image should
> be benign to them, as they won't be able to load the file _anyway_.
>
> >> > 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.
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 hope that helps.

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

Daniel

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