Home Original page

Running SO files

Segher Boessenkool segher@kernel.crashing.org
Sun Jun 1 15:46:00 GMT 2008 
>>> I have noticed that some shared object (.so) files can be executed. 
>>> For
>>> example, I can type:
>>>
>>> $ /lib/libc.so.6
>>>
>>> which prints a message with the version of GNU C library and other
>>> information. How does this work? How is it possible to execute a 
>>> shared
>>> object file?
>>
>> It's a little hack in the Linux kernel.
>
> no it isnt ... it's standard ELF

The ELF standard (v1.2, is it different in newer versions?  Is there
a newer version?) says:

	PT_INTERP
	The array element specifies the location and size of a null-terminated
	path name to invoke as an interpreter. This segment type is meaningful
	only for executable files (though it may occur for shared objects).

so using interp meaningfully in a shared object is "a little hack" in my
opinion.  Feel free to disagree.

It may be possible to create a shared object that is an executable as 
well,
without using interp, but I've never seen this done.

>> and a ".interp" section.
>
> no ... an .interp is only needed if the ELF itself is not capable of 
> direct
> execution.

But can that be done?  Seems hard to me, esp. if you want it to work
on more than one architecture.

> and the kernel doesnt parse the section headers looking
> for ".interp", it parses the dynamic table for DT_INTERP.

Actually, it looks for PT_INTERP in the program headers.

>>> I have also noticed that this is not true
>>> for every SO file. I would appreciate any information on how this
>>> works.
>>
>> You can't "run" a SO if it's not marked +x.  The Linux kernel will
>> happily
>> try to run any SO that is executable, but will segfault it just as
>> happily
>> unless you get all the little bits right.
>
> generally speaking, a SO wouldnt be usable anyways if it werent +x.

Strange, on a debian system only libc.so is +x, other SOs are not (well,
ld.so is).  Dunno, maybe debian is strange.


Segher
More information about the Binutils mailing list