Closed Coekjan closed 2 months ago
Well, as you have see in the code, INIT_ARRAY should be handled properly.
Currently, the value of the array are just translated by the "delta" (difference between loaded memory and physical elf file offset). and this value is called yes.
Regarding your crash, I'm unclear what box64 should do there? delta+ainit_array[i]
is not correct? What should it be then?
The problem comes from https://github.com/ptitSeb/box64/blob/f9b74642a24afc78b9acb41ec8440cd98421849e/src/elfs/elfloader.c#L1116
The address of .init_array
is correctly relocated, but the entries inside it seems not.
I debugged box64 and saw that:
addr[i]
was correct enough: the program was loaded to 0x0000000100000000
and the addr[i]
here was 0x0000000100001150
.addr[i]
was definitely wrong: the shared object was loaded to 0x0000003f01000000
but the addr[i]
here was too low (0x000000000004d100
).I found that:
.rela.dyn
section contains some R_X86_64_RELATIVE
about .init_array
, so the entries in .init_array
are relocated correctly./usr/lib/libcrypto.so.3
, .rela.dyn
section does not contain any R_X86_64_RELATIVE
, so the entries in .init_array
are not relocated.2. in my `/usr/lib/libcrypto.so.3`, `.rela.dyn` section does not contain any `R_X86_64_RELATIVE`, so the entries in `.init_array` are not relocated.
This alone does not really help. Is there any section containing a relocation for the .init_array
entries? If so, in which section is it, and what type of relocation is it? (You can probably find some of this using objdump -rR
.)
Also, from the USAGE.md:
https://github.com/ptitSeb/box64/blob/aeeb9b719ac586c9b741bb2167bda27960bd002b/docs/USAGE.md#L11-L16
Since this is an ELF loader issue, you should use BOX64_LOG=3
or BOX64_LOG=DUMP
(these two are functionally equivalent), not just 2
(or DEBUG
).
There is also an undocumented BOX64_DUMP=1
which only enables the dumping of loader informations (with which you can keep the log level at whatever you want). BOX64_LOG=3
is in fact equivalent to BOX64_LOG=2 BOX64_DUMP=1
.
As a side note, on my (x86_64) machine, your test file runs with no issue with my libcrypto
. After analyzing, I found out that my version of the library contains no .init_array
section, only a .init
(which is correctly relocated and executed).
If you want more help for debugging, providing at least which version of the library you have would be useful (along with where/how you downloaded the library, ie. which package manager or url). As it is, I cannot help more with the informations you have given.
Happy to tell you that I have fixed this issue!
I finally found that it was because box64 did not handle .relr.dyn
section, and I tried to handle it (referring to glibc ld.so implementation).
I will send a PR soon.
Description
These days, I tried to run my simple x64 applications with box64 on rv64gc platform. Box64 did run my simple hello-world program with all used libraries wrapped (e.g. libc), but failed to run my hash program with some libraries emulated (e.g. libcrypto). Here is my hash program:
I compiled this program with
gcc test.c -o test -lssl -lcrypto
, and runBOX64_PREFER_EMULATED=1 ./box64 ./test
. It emited the log:the log
the log (with `BOX64_LOG=2`)
Investigation
I investigated the code via gdb, and found that the function
RunElfInit
insrc/elfs/elfloader.c
calledRunFunctionWithEmu
for.init
and functions in.init_array
:https://github.com/ptitSeb/box64/blob/f9b74642a24afc78b9acb41ec8440cd98421849e/src/elfs/elfloader.c#L1108-L1118
When this issue happened, the pointer
p
is0x0000003f0104c000
andaddr[i]
is0x4d100
(SEEMS TOO LOW???)I read
/proc/(( the pid ))/maps
and sawHere is the problem. The pointer
p
was ok because0x3f0104c000 - 0x3f01000000
is0x4c000
andobjdump -alDS /usr/libcrypto.so.3
told me:However,
addr[i]
(value =0x4d100
) seemed too low!objdump -alDS /usr/libcrypto.so.3
told me:Here was why
addr[i]
is0x4d100
(actually a 4 bytes value:0x0004d100
).Possible Fixes
I think box64 should handle
.init_array
properly, for example, relocating the entries in.init_array
.By the way, I can help to fix it if this is ok.
It is my first time to fix something for box64, so I would appreciate it if you tell me the proper way to fix this bug and guide me how to contribute for box64. Thanks!