Adventures with Binfmt_misc...

[knc1]

Originally Posted by twobob

That doesn't explain why I get no complaint on FAT though (I don't think)

FAT does not support the same permission system that inode file systems do.
Yeah, I know that is obvious, but this morning it seems we keep getting bit by the obvious.

Doing the "insmod" should have created the directory.
It did not, so assume == code missing from the /proc filesystem to do that.

The way you found to make it work, is the way it has to be done in this special case of the configuration having CONFIG_BINFMT == not set.

insmod
mkdir
mount

The last two are a replacement for the /proc system code that got conditionalized away.
The 'net write-ups all presume that CONFIG_BINFMT == M was set in the kernel build.

[twobob]

Okay that appears to be a symbolic link - when it exists ?
Would that be when the kernel does include support for binfmt_misc?

ta.

EDIT: Ah yeah! Thanks for that. I'm not going mad.

maybe I can get us a mount.binfmt_misc if I hunt around in the medium term, but that would still *possibly* mean affecting the /sbin directory directly and that is a no IMHO.

okay well happy day! I'll get back on with the implementation bit : )

[knc1]

Originally Posted by twobob

Patch thing
Patch -p1 < binfmtc_0.15-1.diff.gz

That seems to be patching the Debian/Ubuntu automation.

You can do the same with a standard tcc and without patching the automation:
http://hg.minimodding.com/repos/aufs...v/6c33d1113b9c

[twobob]

Just for giggles.

root@kindle:root> echo ":luajit:M::\x1b\x4c\x4a::/usr/bin/luajit:" > /mnt/us/proc/sys/fs/binfmt_misc/register

root@kindle:root> cat /mnt/us/proc/sys/fs/binfmt_misc/register
:luajit:M::\x1b\x4c\x4a::/usr/bin/luajit:

So it's not broken being on FAT it would seem... onward.

EDIT: There IS NO LUAJIT there, I'm just testing writing a single record...

[twobob]

Originally Posted by knc1

That seems to be patching the Debian/Ubuntu automation.

You can do the same with a standard tcc and without patching the automation:
http://hg.minimodding.com/repos/aufs...v/6c33d1113b9c

Okay. you want I do another build?

[knc1]

apt-get install tcc
should be all you need for your dev system to have "C" scripting.

The Debian/Ubuntu helper stuff for setting up binfmt_misc on your dev system is in the text of the repository file linked to above.

Hmm...
Now I am getting lost -
Where you automating "C" scripting on the K3?
Naw...
He wasn't doing that, we both know the K3 doesn't have Debian/Ubuntu automation.

Will return when my mind clears up a bit from these meds.

[knc1]

Originally Posted by twobob

Just for giggles.

root@kindle:root> echo ":luajit:M::\x1b\x4c\x4a::/usr/bin/luajit:" > /mnt/us/proc/sys/fs/binfmt_misc/register

root@kindle:root> cat /mnt/us/proc/sys/fs/binfmt_misc/register
:luajit:M::\x1b\x4c\x4a::/usr/bin/luajit:

So it's not broken being on FAT it would seem... onward.

EDIT: There IS NO LUAJIT there, I'm just testing writing a single record...

Write a hello world program, mark it executable, execute it.
That will tell you if the system is working.

Example of that testing (for lua):
http://hg.minimodding.com/repos/aufs...v/0d73a71ae86f

[knc1]

Originally Posted by knc1

Write a hello world program, mark it executable, execute it.
That will tell you if the system is working.

Example of that testing (for lua):
http://hg.minimodding.com/repos/aufs...v/0d73a71ae86f

And for the Kindles, they already have lua5.1 install, all you have to do is find the path to it (magic to use shown in above link).

[twobob]

hmm. call me stupid but I cant find the path the the lua thingy...

root@kindle:/> find / -name jit*
root@kindle:/> find / -name *jit
root@kindle:/> find / -name *5.1*
root@kindle:/> find / -name *lua* or *lua or lua*

all are not helpful as were not my gurgle searches - ho hum - moving on

I will try Perl then

[twobob]

Let's try to figure out how to do one for ourselves...

Always a good exercise

root@kindle:/> readelf -h /mnt/us/usr/bin/perl

ELF Header:
Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
Class: ELF32
Data: 2's complement, little endian
Version: 1 (current)
OS/ABI: UNIX - System V
ABI Version: 0
Type: EXEC (Executable file)
Machine: ARM
Version: 0x1
Entry point address: 0x9748
Start of program headers: 52 (bytes into file)
Start of section headers: 1666100 (bytes into file)
Flags: 0x4000002, has entry point, Version4 EABI
Size of this header: 52 (bytes)
Size of program headers: 32 (bytes)
Number of program headers: 8
Size of section headers: 40 (bytes)
Number of section headers: 30
Section header string table index: 27

root@kindle:/> perl -V

Spoiler:

Summary of my perl5 (revision undef undef) configuration:

Platform:
osname=linux, osvers=unknown, archname=arm-unknown-linux-gnueabi
uname='unknown'
config_args='undef'
hint=undef, useposix=true, d_sigaction=undef
useithreads=undef, usemultiplicity=undef
useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef
use64bitint=undef, use64bitall=undef, uselongdouble=undef
usemymalloc=n, bincompat5005=undef
Compiler:
cc='/home/you/BLDS/buildroot/host/usr/bin/arm-none-linux-gnueabi-gcc', ccflags =' -pipe -O0 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64',
optimize=' -pipe -O0 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64',
cppflags='undef'
ccversion='undef', gccversion='undef', gccosandvers='undef'
intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234
d_longlong=undef, longlongsize=8, d_longdbl=undef, longdblsize=8
ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='undef', lseeksize=4
alignbytes=4, prototype=undef
Linker and Libraries:
ld='undef', ldflags ='undef'
libpth=undef
libs=undef
perllibs=undef
libc=undef, so=undef, useshrplib=false, libperl=undef
gnulibc_version='undef'
Dynamic Linking:
dlsrc=undef, dlext=undef, d_dlsymun=undef, ccdlflags='undef'
cccdlflags='undef', lddlflags='undef'


Characteristics of this binary (from libperl):
Compile-time options: PERL_DONT_CREATE_GVSV PERL_USES_PL_PIDSTATUS
PERL_USE_SAFE_PUTENV USE_LARGE_FILES USE_PERLIO
USE_PERL_ATOF
Built under linux
Compiled at Aug 21 2012 00:16:18
@INC:
/mnt/us/usr/lib/perl5/5.12.4/arm-unknown-linux-gnueabi
/mnt/us/usr/lib/perl5/5.12.4
/usr/lib
/lib
/mnt/us/usr/lib
/mnt/us/lib
/mnt/us/usr/lib/perl5/5.12.4/arm-unknown-linux-gnueabi
/usr/lib/perl5/5.12.4
/usr/lib/perl5/5.12.4/arm-unknown-linux-gnueabi
/usr/lib/perl5/5.12.4
.

so given that information and the reference from kernel org:

To actually register a new binary type, you have to set up a string looking like
:name:type:offset:magic:mask:interpreter:flags (where you can choose the ':' upon
your needs) and echo it to [/mnt/us]/proc/sys/fs/binfmt_misc/register.
Here is what the fields mean:
 - 'name' is an identifier string. A new /proc file will be created with this
   name below /proc/sys/fs/binfmt_misc
 - 'type' is the type of recognition. Give 'M' for magic and 'E' for extension.
 - 'offset' is the offset of the magic/mask in the file, counted in bytes. This
   defaults to 0 if you omit it (i.e. you write ':name:type::magic...')
 - 'magic' is the byte sequence binfmt_misc is matching for. The magic string
   may contain hex-encoded characters like \x0a or \xA4. In a shell environment
   you will have to write \\x0a to prevent the shell from eating your \.
   If you chose filename extension matching, this is the extension to be
   recognised (without the '.', the \x0a specials are not allowed). Extension
   matching is case sensitive!
 - 'mask' is an (optional, defaults to all 0xff) mask. You can mask out some
   bits from matching by supplying a string like magic and as long as magic.
   The mask is anded with the byte sequence of the file.
 - 'interpreter' is the program that should be invoked with the binary as first
   argument (specify the full path)
 - 'flags' is an optional field that controls several aspects of the invocation
   of the interpreter.

so we want to:

echo ':perl:M::\x7fELF\x45\x4c\x46\x01\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00::/mnt/us/usr/bin/perl:' > /mnt/us/proc/sys/fs/binfmt_misc/register

(or echo ':perl:E::pl::/mnt/us/usr/bin/perl:'>blah)

root@kindle:script> nano -w hello.pl

#!/mnt/us/usr/bin/perl
print "Hello world!\n";


save it.

root@kindle:script> ./hello.pl
Hello world!

Seems to be a worker?

great.


Next step... getting this to help us load our 300 odd applications from Buildroot without having to write a script for each.

TBC

[twobob]

So Anyways...

To the thrust of this lot:

Originally Posted by knc1

Aside from the connected use of "cd ..." and "$PWD" -
You almost have it down to a one-liner:

 #!/lib/ld-linux.so.3 --library-path $PWD/lib:/usr/lib:/lib --inhibit-rpath libfftw3.so.3 ./fftw-wisdom

For the purposes of conversation here, let us say that the above code implements the requirements of your chosen distribution policy (it does/will).
Whatever the final version of that "policy implementor" becomes, the above demonstrates the overall behavior.

(Sorry if this reads like I am preaching/teaching or something else, no insult intended to anyone, not even if the above meets the GM whitespace standard.)

Next (rhetorical) question:
How to avoid writing (or having the build system write) one of those above for each and every new application?
In answer, start by reading what is written above in the prototype launcher glue.

What does the first two characters, the Splat-Bang, in a *nix script do?
It causes the loading mechanism used to start an executable to search for a program (other than the elf loader) to interpret the rest of the file.

Now, ask yourself, what mechanism does binfmt_misc provide?
It is a loading mechanism that selects a program to interpret the rest of the file based on either extension or magic number.
The "program" may be any executable, including a script "wrapper".

Ah, so, as the light begins to dawn ....
Now we can see why that crazy old fool was asking for mod binfmt_misc.

Suppose that the above single line glue code began with a six character magic number:

 #!ld.3 --library-path $PWD/lib:/usr/lib:/lib --inhibit-rpath libfftw3.so.3 ./fftw-wisdom

Now all you need is one "wrapper" that binfmt_misc can call when it detects a new executable that needs: "launcher glue".
That wrapper can be used to determine the variables of the "glue code" launcher.

For a more advanced usage, to get a Kindle to "swallow" anything we add-in, see the following reference.

When reading the reference: http://www.kernel.org/doc/Documentation/binfmt_misc.txt

You will find examples of how binfmt_misc can read the elf header of the file to be run.
One of the first things in the elf header is the interpreter to be used and some other flag bits.

I.E: Not only can we "glue in" applications using a mis-matched glibc, we can "glue in" applications that aren't even built against glibc of any version.
(the uClibc loader has a different name, only I need to re-build the uClibc used in the emulator because the current one was built without a required option).

So to this end I will put together a custom script like KNC1 says - look at the magic (I think) - and then implement the loader.

TBC...

[knc1]

Originally Posted by twobob

Let's try to figure out how to do one for ourselves...

Always a good exercise

root@kindle:/> readelf -h /mnt/us/usr/bin/perl


root@kindle:/> perl -V



so given that information and the reference from kernel org:

To actually register a new binary type, you have to set up a string looking like
:name:type:offset:magic:mask:interpreter:flags (where you can choose the ':' upon
your needs) and echo it to [/mnt/us]/proc/sys/fs/binfmt_misc/register.
Here is what the fields mean:
 - 'name' is an identifier string. A new /proc file will be created with this
   name below /proc/sys/fs/binfmt_misc
 - 'type' is the type of recognition. Give 'M' for magic and 'E' for extension.
 - 'offset' is the offset of the magic/mask in the file, counted in bytes. This
   defaults to 0 if you omit it (i.e. you write ':name:type::magic...')
 - 'magic' is the byte sequence binfmt_misc is matching for. The magic string
   may contain hex-encoded characters like \x0a or \xA4. In a shell environment
   you will have to write \\x0a to prevent the shell from eating your \.
   If you chose filename extension matching, this is the extension to be
   recognised (without the '.', the \x0a specials are not allowed). Extension
   matching is case sensitive!
 - 'mask' is an (optional, defaults to all 0xff) mask. You can mask out some
   bits from matching by supplying a string like magic and as long as magic.
   The mask is anded with the byte sequence of the file.
 - 'interpreter' is the program that should be invoked with the binary as first
   argument (specify the full path)
 - 'flags' is an optional field that controls several aspects of the invocation
   of the interpreter.

so we want to:

echo ':perl:M::\x7fELF\x45\x4c\x46\x01\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00::/mnt/us/usr/bin/perl:' > /mnt/us/proc/sys/fs/binfmt_misc/register

(or echo ':perl:E::pl::/mnt/us/usr/bin/perl:'>blah)

root@kindle:script> nano -w hello.pl

#!/mnt/us/usr/bin/perl
print "Hello world!\n";


save it.

root@kindle:script> ./hello.pl
Hello world!

Seems to be a worker?

great.


Next step... getting this to help us load our 300 odd applications from Buildroot without having to write a script for each.

TBC

Sign, in blood, the attached NDA.

You can't be sure that it is working with that perl script.

Remove the first line (the #!/....), it binfmt_misc fails, the normal loader search will find and use that line.

Does (or can) Perl produce "compiled" executables?
in that case, you want to do "magic" matching against whatever identifier the Perl compiler puts in its output files.
**not** the magic identifier of perl itself.

If Perl can not produce "pre-compiled" scripts - then you need to do one of two things:
Either "extension" matching, such as you have done above
OR
Put a byte string (printable characters are ok) somewhere in the source where you can test for it with the "magic" matching.
(Like the earlier tcc example required the magic string "BINFMTTC" at the start of the first line.

It is just a fixed identifier, with right combination of offset, string, and mask it could be: "lab126 sucks" starting at byte 255 of the source.

- - - -

Hindsight:
We (of I) got onto this over the problem that the current emulator (and the current tcc built for the Kindle in our threads) expect to have the uClibc system loader and system libraries but the Kindles are glibc systems.

So the idea was to put the "interpreter" string (ld-uclibc.so or whatever it is - readelf will report it) as the "magic" to be tested for and use a "supporting script" to use the manual invocation of the loader (like you did with the ld-linux.so loader).

Only speed bump - our uClibc build wasn't configured so that the loader could be called manually.
The reasons that I need to provide new or re-built emulator images is getting too long to even remember.

Now another problem that we might be able to "fix" with this - - -
executables built against glibc of a version not supported on the Kindle.
**IF** we can identify them by some constant sequence of bytes in their header (or write our own ID bytes in the headers with objcopy).

Sorry that I can't be of more specific help - It will be at least a week before the Dr. lets me have the use of my mind back.

[twobob]

erm. so I know I'm slow but do you mean?

23:21:6c:64:2e:33

which is #!ld.3 in hex?

[knc1]

I just tossed that out as a "place holder example" -
But yeah, we should be looking for something different about executibles built for the old glibc and ones built for the new glibc.

If readelf does not give enough information, objdump will.

If no usable differences can be found in the elf header of old vs. new -
Then we will have to "mark" them ourselves (find an un-used bit/byte and set to a value that equals == Kindle Hack).

Sorry I can't be of more help, I am months behind in catching up with your work.

[twobob]

meh be right. I get it now. the final magic not the called exe.

understood. well I'll have to think how that applies then and get back on this. either way it works.