binfmt_misc + sel_ldr

[Mike Acton]

Has anyone already done the legwork on Linux to register nexes with binfmt_misc so that they can just be run (without specifying sel_ldr each time)?

Mike.

[Derek Schuff]

Check out https://github.com/krasin/nacl_interp
It's a little bit clunky to set up but it does work.

> --
> You received this message because you are subscribed to the Google Groups
> "Native-Client-Discuss" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/native-client-discuss/-/buoYyvKCqq0J.
> To post to this group, send email to native-cli...@googlegroups.com.
> To unsubscribe from this group, send email to
> native-client-di...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/native-client-discuss?hl=en.

[Mike Acton]

Thanks, Derek. That was helpful to see.

Here's what I ended up doing for others that might be interested:

For reference, I'm on an Ubuntu EC2 image (x86_64 x86_64 x86_64 GNU/Linux)

1. Install binfmt-support:

$ sudo apt-get install binfmt-support

2. Create script to run 32 bit nexe: /usr/local/bin/run_nexe32

#!/bin/sh

/home/ubuntu/nacl_sdk/pepper_19/tools/sel_ldr_x86_32 -a -S -B /home/ubuntu/nacl_sdk/pepper_19/tools/irt_core_x86_32.nexe "$@"

3. Create script to run 64 bit nexe: /usr/local/bin/run_nexe64

#!/bin/sh

/home/ubuntu/nacl_sdk/pepper_19/tools/sel_ldr_x86_64 -a -S -B /home/ubuntu/nacl_sdk/pepper_19/tools/irt_core_x86_64.nexe "$@"

4. Make sure scripts are executable

$ sudo chmod ugo+x /usr/bin/local/run_nexe32 

$ sudo chmod ugo+x /usr/bin/local/run_nexe64 

5. Register the nexe file formats:

$ sudo update-binfmts --install NEXE32 /usr/local/bin/run_nexe32 --magic \\x7fELF\\x01\\x01\\x01\\x7b\\x07\\x00\\x00\\x00\\x00\\x00\\x00

$ sudo update-binfmts --install NEXE64 /usr/local/bin/run_nexe64 --magic \\x7fELF\\x02\\x01\\x01\\x7b\\x07\\x00\\x00\\x00\\x00\\x00\\x00

6. Done!

Now I can just run nexes like so:

$ ./hello_x86_32.nexe 

DEBUG MODE ENABLED (bypass acl)

[7374,4148045536:05:33:00.414748] BYPASSING ALL ACL CHECKS

[7374,4148045536:05:33:00.416947] Native Client module will be loaded at base address 0x00000000b7324000

[7374,4148045536:05:33:00.428396] NaClMakePcrelThunk: got addr 0x185a0000

Hello, World!

and...

$ ./hello_x86_64.nexe 

DEBUG MODE ENABLED (bypass acl)

[7379,4006541152:05:33:36.505945] BYPASSING ALL ACL CHECKS

[7379,4006541152:05:33:36.508066] Native Client module will be loaded at base address 0x00007f1800000000

Hello, World!

Mike.

[Mike Acton]

Check out https://github.com/krasin/nacl_interp
It's a little bit clunky to set up but it does work

Hey Derek,

Your script brought up some questions, if you don't mind:

• You specify  irt_core_${arch}.nexe , but there is also irt_${arch}.nexe in the tools directory - How are they related? Or how are they different?
• You add runnable-ld.so with the --library-path flag. What does this provide? 
• Are there other nifty features of sel_ldr that I might want to be aware of?

Mike.

[Egor Pasko]

On Thu, Apr 26, 2012 at 10:08 AM, Mike Acton <mac...@gmail.com> wrote:

Check out https://github.com/krasin/nacl_interp
It's a little bit clunky to set up but it does work

Hey Derek,

Your script brought up some questions, if you don't mind:

• You specify  irt_core_${arch}.nexe , but there is also irt_${arch}.nexe in the tools directory - How are they related? Or how are they different?

irt_core contains necessary layer for standalone sel_ldr

irt contains parts of pepper that is only relevant when running in the browser 

• You add runnable-ld.so with the --library-path flag. What does this provide? 

It is for dynamically linked binaries built with the glibc toolchain, runnable-ld.so is the dynamic linker ported from linux, and the --library-path instructs where to find dynamic libraries (*.so files). You probably only tried to run binaries built with the newlib toolchain.

--
Egor Pasko

[Mike Acton]

Also -E is a useful flag for sel_ldr. (Set environment variables.) I can forward envars from the starting process. That caught me up for a minute when I was making the nexe-based CGI script.

e.g. here's my run_nexe32

#!/bin/sh

/home/ubuntu/nacl_sdk/pepper_19/tools/sel_ldr_x86_32 -a -S -B /home/ubuntu/nacl_sdk/pepper_19/tools/irt_core_x86_32.nexe -l /dev/null -ECONTENT_LENGTH=${CONTENT_LENGTH} -EHTTP_HOST=${HTTP_HOST} "$@"  2> /dev/null

Note that I'm throwing away stderr. Is there a way of silencing/logging the sel_ldr output that goes to stderr? (-l only seems to apply to the stdout output.)

Mike. 

[Roland McGrath]

On Fri, Apr 27, 2012 at 12:22 PM, Mike Acton <mac...@gmail.com> wrote:
> Note that I'm throwing away stderr. Is there a way of silencing/logging the
> sel_ldr output that goes to stderr? (-l only seems to apply to the stdout
> output.)

You can set the environment variable NACL_EXE_STDERR (in sel_ldr's
environment, not with -E). (Similarly for NACL_EXE_{STDIN,STDOUT}.)
The value can be a file name to log to a file, or you can use
/dev/fd/N along with shell redirections of descriptor N to do
something fancier.


Thanks,
Roland

[Mike Acton]

You can set the environment variable NACL_EXE_STDERR (in sel_ldr's environment, not with -E).  (Similarly for NACL_EXE_{STDIN,STDOUT}.) 

That seems to redirect the output of the nexe. I'd like to redirect the output of sel_ldr. It's spitting stuff out into stdout and stderr and really all I want is the output from the nexe. 

[Bennet Yee (余仕斌)]

the NACLLOG environment variable specifies where logging output goes.  that's stderr by default.  not sure where anything would be sent to stdout.  however, without disabling the outer sandbox, there's no place to send the output to.  in what context are you running things?  since you are using the -E flag, it sounds like you're running sel_ldr directly and not using the linked-in implementation in chrome, in which case you're not running inside an outer sandbox anyway -- in that case, set NACLLOG to /dev/null ought to get rid of all logging output.  there shouldn't be that much logging output at the default verbosity level anyway -- basically, the base address of the NaCl module address space is printed, and (if it's an older build of sel_ldr) some info messages about being able to access descriptors that are not constructible/normally available in NaCl (inherited descriptors to pseudo-terminals).

-bsy

On Fri, Apr 27, 2012 at 10:12 PM, Mike Acton <mac...@gmail.com> wrote:

You can set the environment variable NACL_EXE_STDERR (in sel_ldr's environment, not with -E).  (Similarly for NACL_EXE_{STDIN,STDOUT}.) 

That seems to redirect the output of the nexe. I'd like to redirect the output of sel_ldr. It's spitting stuff out into stdout and stderr and really all I want is the output from the nexe. 

--

You received this message because you are subscribed to the Google Groups "Native-Client-Discuss" group.

To view this discussion on the web visit https://groups.google.com/d/msg/native-client-discuss/-/lPXAO08ocnIJ.

To post to this group, send email to native-cli...@googlegroups.com.
To unsubscribe from this group, send email to native-client-di...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/native-client-discuss?hl=en.

--
bennet s yee
i usually don't capitalize due to mild tendonitis

[Mike Acton]

the NACLLOG environment variable specifies where logging output goes 

Perfect. That worked.

in what context are you running things? 

Running nexe on the server as CGI "script." 

Mike.

[Braxton McKee]

I built/installed this and it seems to start OK:

DEBUG MODE ENABLED (bypass acl)

[29259,3220895584:16:17:43.434576] BYPASSING ALL ACL CHECKS

However, it sits there for about 15 seconds and then spits out

PpapiPluginStart: PPAPI hooks not found

any ideas?

Also, what functions will it call in my .nexe under such a scenario? main is already defined by pepper

--
-------------------------------------------------------------------------------------------
Braxton McKee                          Broad Street Analytics
www.twitter.com/braxtonmckee   www.broadstreetanalytics.com

[Mike Acton]

You can't use the Pepper SDK in this scenario. You provide main() normally. There are very few OS hooks - file i/o though, so that's a big one. Would be nice if sockets were there though - that'd make it a total win for me. 

[Derek Schuff]

When you run stuff in sel_ldr you don't have pepper. Instead the
environment is more like a conventional command-line environment (and
hence sel_ldr will call main)

On Wed, May 16, 2012 at 1:22 PM, Braxton McKee <braxto...@gmail.com> wrote:

[Braxton McKee]

I see. So I need a different build than my browser plugin that doesn't have pepper and that has it's own main?

[Mike Acton]

I see. So I need a different build than my browser plugin that doesn't have pepper and that has it's own main? 

Yeah. I pulled out the pre-main stuff into a separate lib for the browser-build (and call the application main in a separate thread) so that they both could use the same source and same libs. But yes, I'm making separate nexes. 

[Victor Khimenko]

On Thu, May 17, 2012 at 1:13 AM, Braxton McKee <braxto...@gmail.com> wrote:

I see. So I need a different build than my browser plugin that doesn't have pepper and that has it's own main?

This may be simplest way, but you can call __nacl_irt_query to see if PPAPI is available or not. If it's not available then programs can work as console program, if it's available then it'll work as PPAPI module.

Similarly to how emacs works in console mode or in X window depending on if it can find the X server.

[Braxton McKee]

That sounds more appealing.  But from where would I call __nacl_irt_query?  In my main .nexe, the first code of mine that's run is the pepper module instantiation. I need an entrypoint where I can make the decision.

[Mike Acton]

 In my main .nexe, the first code of mine that's run is the pepper module instantiation 

You can apparently call PpapiPluginMain() yourself. See the thread "Woot! Hello world." https://groups.google.com/d/msg/native-client-discuss/lT5bsW1ZlKQ/ZNHD12vtsp0J

I haven't done that though. So I'm assuming you'd provide main, call  __nacl_irt_query, and if available call PpapiPluginMain(), if not, just call your application main entry point.

Mike.

[Victor Khimenko]

On Thu, May 17, 2012 at 1:24 AM, Braxton McKee <braxto...@gmail.com> wrote:

That sounds more appealing.  But from where would I call __nacl_irt_query?  In my main .nexe, the first code of mine that's run is the pepper module instantiation. I need an entrypoint where I can make the decision.

No. In your main .nexe as in any normal program the first code to run is main(). PPAPI library provides it's own main, but it can be overriden. You'll need to call __nacl_irt_query to see if you can find PPAPI hooks and then you can call ppapi_start if it exists or continue as console application if it does not.

Here is how it all is hooked together. The whole things starts here:

https://src.chromium.org/viewvc/native_client/trunk/src/native_client/src/untrusted/irt_stub/plugin_main_irt.c?view=markup

Then it goes to here:

https://src.chromium.org/viewvc/native_client/trunk/src/native_client/src/untrusted/irt_stub/ppapi_plugin_main.c?view=markup

and finally this things starts everything:

https://src.chromium.org/viewvc/native_client/trunk/src/native_client/src/untrusted/irt_stub/ppapi_plugin_start.c?view=markup

Ignore the hoopla with environ and auxv: if you are using glibc then you can just call __nacl_irt_query directly (just include irt_syscalls.h). The only problem here is that various structures you need to access and use may not be exposed in public headers. You probably only need to borrow a bit of irt.h:

https://src.chromium.org/viewvc/native_client/trunk/src/native_client/src/untrusted/irt/irt.h?view=markup

[Mike Acton]

Hey Victor,

I appreciate that you linked the relevant code in your response. That was very helpful. I'm don't know if all of Braxton's questions are answered, but it certainly cleared a couple of things up for me.

Mike.

[Mike Acton]

There are very few OS hooks - file i/o though, so that's a big one. 

File i/o doesn't seem to include much working beyond open/read/write/close functions though it seems (at least on newlib.) Which I just discovered when I ported libarchive. I was able to make a working tarfilter.nexe though at least. Good enough for now.