Re: GSOC2011

On Mon, Mar 21, 2011 at 12:55 PM, Andrew Gabriel
<illumos <at> cucumber.demon.co.uk> wrote:
> Cyril Plisko wrote:
>>
>> On Mon, Mar 21, 2011 at 1:54 PM, Andrey Sokolov
>> <keremet <at> solaris.kirov.ru> wrote:
>>>
>>> Hi Deano,
>>>
>>> I would like to write a program that will convert linux binaries to
>>> opensolaris binaries. The program will change dynamic relocation records.
>>> I
>>> did a little experiment: http://forum.os-solaris.ru/index.php?topic=223.0
>>> I
>>> have converted a simple linux binary to opensolaris binary using hex
>>> editor.
>>>
>>
>>
>> Instead of [destructively] change the Linux binary in order to run it
>> under Solaris,
>> wouldn't it be better to do the job on the fly via dynamic linker ?
>> Linux binaries conveniently use /lib/ld-linux.so.1 (as opposed to
>> /lib/ld.so.1 for
>> Solaris). So one would imaging that if you will provide a
>> /lib/ld-linux.so.1 that
>> knows how to fix the relocations that would get you what you need, w/o
>> touch
>> the binaries. Does it make sense ?
>
> Might want to look back at any info which still exists on "lxrun" which
> worked in a not dissimilar way, and also see if there's any info about Sun's
> Solaris 10 Janus project still knocking around (which may be useful even
> though you are not proposing the same route).
>

lxrun still works for older Linux binaries, but it used the rather
ugly method of userspace syscall emulation by trapping SIGSEGV.
Applications receive this signal when they cause a general protection
fault by making an invalid system call using the traditional i386 INT
0x80 (the syscall vectors used by Linux happen to be unused on
Solaris). I'm not sure what happens when applications try to use
SYSENTER instead.

BrandZ just implemented the Linux system calls instead, which works
well, but obviously requires extensive kernel support. While we can
bring it back into illumos fairly easily, it is still incomplete and
also suffers from the fact that Linux has had some changes in the time
it's gone unmaintained.

Modern Linux applications as they do not embed system calls in their
executables [1], so we do not have to perform syscall translation if
we don't want to. They expect a code segment containing functions with
stable interfaces to be mapped when they are run, and use those
functions to perform syscalls. On Linux this segment is actually
provided by the kernel (as a sort of "virtual library" named
"linux-gate.so.1") and this allows the syscall implementations to be
replaced easily [2]. illumos can provide this functionality as a real
library or in the dynamic loader.

If we want Linux executables to load native shared libraries (which
would be really really cool), the dynamic loader would also need to
support redirecting Linux application libc calls to GNU libc or
wrappers around the native libc to handle interface and structure
differences.

Your suggestion to modify Linux executables on disk is an interesting
one (reminds me of a similar but far too ambitious project for Win32
executables) and I'd like to hear more.

I have investigated the options here (actually started some work on a
modified dynamic loader that lives at ld-linux.so.2) and would be
happy assist you. BTW, developer <at> lists.illumos.org is better for
future discussion, and I have CC'ed it.

[1] Some exceptions exist in closed software, often intended to
discourage reverse engineering.
[2] See the description of __kernel_vsyscall here:
http://articles.manugarg.com/systemcallinlinux2_6.html

-Albert