Re: [Xen-devel] [PATCH] xen/efi: Avoid EFI stub using absolute symbols

[Julien Grall <julien.grall@xxxxxxxxxx>]

Hi Jan,

On 12/01/18 13:13, Jan Beulich wrote:
> > > > On 09.01.18 at 20:43, <julien.grall@xxxxxxxxxx> wrote:
> > When I compiled the snippet on x86 and Arm, no relocation is available
> > for the pointers to string in the array in the final binary. Yet they
> > are available in the object.
> I can see them there in the binary I look at. I use my own tool
> for dumping, so the output may look unfamiliar to you, but here
> are the relevant pieces:
I am a bit confused. Which binary are you looking at? Is it xen.efi?
I don't seem to find them in xen-syms.

> Section count                               0009 (         9)
> ...
>    Section 0004 (    4): '.init', size 00085578, RVA 00600000, flags E0D00060
>    code data read write exec 4096-byte align
>      00086000 bytes at file offset 00191000
>
> Symbol count                            00001DE2 (      7650)
> ...
>    0000115A: ErrCodeToStr.9795
>      Value 00044340, Section 0004, Type none, Storage static
>
> which makes the array start at RVA 0x644340.
>
>   Fixups for page at 00644000, 00000094 (       148) bytes
> ...
>    DIR64   0318  DIR64   0320  DIR64   0328  DIR64   0368  DIR64   0378
>    DIR64   0388  DIR64   0390  DIR64   0398  DIR64   03A0  DIR64   03A8
>    DIR64   03B0  DIR64   03B8  DIR64   0410  DIR64   0418  DIR64   0448
>
> The numbers here are the offsets into the page named in the
> "title" line, and the last 12 are the ones targeting the array in
> question.
>
> > Indeed the relocation seem to be absolute (e.g R_X86_64_64) and
> > disappeared at linking. Hence why I suggested a compiler bug because the
> > code should be PIE and that would not even work is the binary is
> > randomized on Linux.
> Well, without having seen the binary I don't think I can conclude
> in the direction of compiler bug. Please don't forget that ld itself
> does indeed not (yet) create any relocations in PE executables
> (which an EFI application is). They're being added in a post-
> processing step (hence the need to link the binary twice at
> different base addresses, for the helper tool [mkreloc] to figure
> out where relocations are needed).
If the code compiled is position independent, then you should not need
relocation. Right? So what are you trying to achieve with mkreloc?

Also, it does not explain why the compiler is issuing absolute address 
when building with -fpie.
> > So I am wondering how this work on x86? Note that this code is only used
> > in error path.
> Sure, but an error path is being taken every now and then, and
> I personally have seen errors coming back (mostly after having
> made mistakes elsewhere).
And I guess the binary will never be loaded at the same as virtual 
address as Xen would be meant to run?
Cheers,

--
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel