|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH] xen/efi: Avoid EFI stub using absolute symbols
>>> 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:
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).
> 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).
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |