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

["Jan Beulich" <JBeulich@xxxxxxxx>]

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

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

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

Jan

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