runtime_loader GetSymbolCache has invalid implicit assumption

[cdurrett]

Bug because code assumes ELF being loaded was made with GCC. A yasm ELF file now fails with a segment/memory exception.

Line 61 (in current github source) in file elf_symbol_lookup.h reads:

fTableSize(image->symhash[1]),

If it is changed to read:

fTableSize(image->symhash ? image->symhash[1] | 0),

the bug goes away.

[waddlesplash]

Would you care to contribute a git-patch for this? That way you get credit for the change in Git.

[cdurrett]

Replying to waddlesplash:

Would you care to contribute a git-patch for this? That way you get credit for the change in Git.

I prefer cash to credit. :-)

[bonefish]

Apparently your shared object file doesn't have a dynamic section. The specs say:

"If an object file participates in dynamic linking, its program header table will have an element of type PT_DYNAMIC."

So, TBH, I'm not sure why we allow loading shared objects without a dynamic section at all. What is your shared object and what does it do?

[cdurrett]

Ascend with me to flight level 300. :-)

The simplest program should work. This program for example.

; s.a section .text

global _start

_start: ret

If in the terminal I

yasm -f elf s.a ld -s -o s s.o ./s

Program 's' should do nothing - except to get loaded and executed by runtime_loader.

In all the effort done to support and optimize "shared object programs" with "dynamic sections", this simplest case looks like it was inadvertently overlooked sometime after December 2008.

I've made the less-than-one-line change mentioned in the ticket and restored the handling of the simplest case. The change also protects runtime_loader from abending in an allocation routine and thus becoming an attack vector to the rest of the OS.

Charles

[simonsouth]

Don't assume executable has dynamic segment

[simonsouth]

I've attached a patch that implements Charles' solution (it looks correct to me), tweaked to match the ​coding guidelines.

What yasm is producing in his example is a non-position-independent, (effectively) statically linked executable, so the patch for #12427 should be applied as well to ensure the program is positioned correctly in memory on load.

With both these patches applied the example assembles and runs correctly for me on hrev49717.

[pulkomandy]

Applied in hrev49728. Thanks!