[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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

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?


Julien Grall

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.