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

["Jan Beulich" <JBeulich@xxxxxxxx>]

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

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

> 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
will actually turn out to be the easier route.

Jan

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