11

Could self-modifying code be used to speed up function calling in dynamically linked libraries?

As far as I understand it, ELF shared libraries use a kind of indirect jump table (the procedure linkage table, or PLT) to enable lazy binding of library functions. The purpose seems to be to avoid having to modify the table in the code segment while still enabling lazy resolution of function positions at the first call.

Wouldn't it be faster to dynamically create the code for that table at load time, or possibly even at the first function call?

Is it to enable sharing of the code segment between processes as much as possible (a dynamic table would be private to a process)? Is it for security reasons (writable code shouldn't be executable - but JITs do that all the time, and the write permission could be added and removed by the loader before actually starting the program)?

Or is it a combination of those, and the small performance gain per function call just wouldn't be worth the effort?

Improve this question
0
8

I suppose we're talking about x86 architecture.

You cannot have Self-Modifying Code in protected mode, which is used by most UNIX-based operating systems (and not only) that I'm aware of, because the code segments are always read-only. A loader does not control that -it is something that is being handled by the memory management subsystem of the kernel.

But even if you could "create the code for that table at load time" as you say, it would defy the whole purpose of shared libraries. This way, each process would have a "private" copy of the library's functions in its address space, effectively increasing its memory footprint -one of the reasons that shared libraries were created, was to address this issue.

The whole process you that you describe is quite complex, and it would cost more processing cycles than the PLT method that is used nowadays, and probably would introduce more, new & interesting security issues.

Improve this answer
3
  • 2
    You can use the mprotect(2) system call to make .text segment pages writeable and executable. – Bruce Ediger Nov 15 '12 at 22:30
  • 1
    That is correct, sir. Probably it would work decently on the average UNIX-based system, but the whole linking process would break as soon as someone tried to harden the system with e.g PaX, which enforces restrictions on mprotect(2). – dkaragasidis Nov 16 '12 at 11:36
  • (It seems that I missed to mention @BruceEdiger in my previous comment) – dkaragasidis Nov 16 '12 at 11:56
1

ELF DSOs may use a flag (DF_TEXREL) to announce that they require rellocations by modification of their text section (which is normally read-only). The jump table approach along with PIE position independent code should be more optimal, though.

(Found that in http://www.akkadia.org/drepper/dsohowto.pdf, but other resources mention this too).

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.