Compiling the hello_world nexe on my own and running it with sel_ldr

[David Alves]

Hi All

   I'm trying to come up with some incantation to get a nexe that I can run but I'm failing, any help would be greatly appreciated.

   I'm just trying to compile the hello_world.c example on my own and with just the nacl_sdk (I've compiled it successfully after checking out native_client, with the built-in scons builder).

   Here's what I'm doing:

   Compiling with: ../thirdparty/nacl_sdk/pepper_44/toolchain/linux_x86_glibc/bin/x86_64-nacl-gcc hello_world/hello_world.c -I../thirdparty/nacl_sdk/pepper_44/include -L../thirdparty/nacl_sdk/pepper_44/lib/glibc_x86_64/Release -o hello_world_x86_64.nexe -m64

   Running with: ../thirdparty/nacl_sdk/pepper_44/tools/sel_ldr_x86_64 -B ../thirdparty/nacl_sdk/pepper_44/tools/irt_core_x86_64.nexe -- ./hello_world_x86_64.nexe

   Compiling works, but when I try to run I get:

ELF executable text/rodata segment has wrong starting address

Using the wrong type of nexe (nacl-x86-32 on an x86-64 or vice versa)

or a corrupt nexe file may be responsible for this error.

[30493,1430243136:18:32:27.715993] NaClAppStartModule: error loading module 

The sel_ldr command works with the nexe that I got from native_client but not with the nexe I've compiled.

Also I've tried linking it statically to no avail.

I'm running linux x64.

Thanks

David

[David Alves]

Hum, apparently changing to the newlib toolchain sorted the issue.

Any ideas as to why?

I've read the drawbacks in other threads regarding licensing and whatnot, but (in the near future) I'd like to use some simple libs that use glibc, so any ideas as to why Its failing would be greatly appreciated.

Best

David

[Victor Khimenko]

On Wed, Jul 29, 2015 at 4:36 AM, David Alves <david...@gmail.com> wrote:

Hi All

   I'm trying to come up with some incantation to get a nexe that I can run but I'm failing, any help would be greatly appreciated.

   I'm just trying to compile the hello_world.c example on my own and with just the nacl_sdk (I've compiled it successfully after checking out native_client, with the built-in scons builder).

   Here's what I'm doing:

   Compiling with: ../thirdparty/nacl_sdk/pepper_44/toolchain/linux_x86_glibc/bin/x86_64-nacl-gcc hello_world/hello_world.c -I../thirdparty/nacl_sdk/pepper_44/include -L../thirdparty/nacl_sdk/pepper_44/lib/glibc_x86_64/Release -o hello_world_x86_64.nexe -m64

   Running with: ../thirdparty/nacl_sdk/pepper_44/tools/sel_ldr_x86_64 -B ../thirdparty/nacl_sdk/pepper_44/tools/irt_core_x86_64.nexe -- ./hello_world_x86_64.nexe

NaCl does not support usual shebang Linux trick which means that you must run dynamic loader directly. You could grab command line from the bot and change it to suit your needs:

  scons-out/opt-linux-x86-64/staging/nacl_helper_bootstrap scons-out/opt-linux-x86-64/staging/sel_ldr --r_debug=0xXXXXXXXXXXXXXXXX --reserved_at_zero=0xXXXXXXXXXXXXXXXX -a -B scons-out/nacl_irt-x86-64/staging/irt_core.nexe -- /mnt/data/b/build/slave/nacl-toolchain/build/native_client/toolchain/linux_x86/nacl_x86_glibc_raw/x86_64-nacl/lib/runnable-ld.so --library-path scons-out/nacl-x86-64-glibc/lib:/mnt/data/b/build/slave/nacl-toolchain/build/native_client/toolchain/linux_x86/nacl_x86_glibc_raw/x86_64-nacl/lib scons-out/nacl_irt_test-x86-64-glibc/obj/tests/benchmark/benchmark_test.nexe x86-64_with_irt_nnacl_glibc_dynamic

sel_ldr.py handles dance with picking proper version of sel_ldr and nacl_helper_bootstrap, but you still need to run runnable-ld.so and specify --library-path ...

 

   Compiling works, but when I try to run I get:

ELF executable text/rodata segment has wrong starting address

Using the wrong type of nexe (nacl-x86-32 on an x86-64 or vice versa)

or a corrupt nexe file may be responsible for this error.

[30493,1430243136:18:32:27.715993] NaClAppStartModule: error loading module 

The sel_ldr command works with the nexe that I got from native_client but not with the nexe I've compiled.

Also I've tried linking it statically to no avail.

I'm running linux x64.

Thanks

David

--
You received this message because you are subscribed to the Google Groups "Native-Client-Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to native-client-di...@googlegroups.com.
To post to this group, send email to native-cli...@googlegroups.com.
Visit this group at http://groups.google.com/group/native-client-discuss.
For more options, visit https://groups.google.com/d/optout.

[David Alves]

Ah, interesting. Good to know, thanks.

Using a version of the command you suggest I got my nexe dynamically linked against glibc to run.

New question:

That "-a" argument is worrying as it makes the loader allow some syscalls it wouldn't (and shouldn't) otherwise right? (e.g. I get "BYPASSING ALL ACL CHECKS" in the output).

This is, of course worrysome, but if I don't pass the "-a" argument I get "Permission denied"

What's causing this?

Best

David

--
You received this message because you are subscribed to a topic in the Google Groups "Native-Client-Discuss" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/native-client-discuss/Q3xZ5qF9JCI/unsubscribe.
To unsubscribe from this group and all its topics, send an email to native-client-di...@googlegroups.com.

[Victor Khimenko]

On Wed, Jul 29, 2015 at 10:08 AM, David Alves <david...@gmail.com> wrote:

Ah, interesting. Good to know, thanks.

Using a version of the command you suggest I got my nexe dynamically linked against glibc to run.

New question:

That "-a" argument is worrying as it makes the loader allow some syscalls it wouldn't (and shouldn't) otherwise right? (e.g. I get "BYPASSING ALL ACL CHECKS" in the output).

This is, of course worrysome, but if I don't pass the "-a" argument I get "Permission denied"

What's causing this?

sel_ldr only have two modes:

  1) open(2) is not allowed (default)

  2) open(2) is allowed (-a)

When you run unnable-ld.so it, naturlly, needs to find and load your actual program (and all the required shared libraries). If open(2) is not allowed it couldn't do that (and you see "Permission denied" message then), if open(2) is allowed then it works but in that mode NaCl program have access to all the files on your system.

Browser solves this problem by offereing PPAPI and restricted filesystem ( https://developer.chrome.com/apps/fileSystem ), but nothing like this exist in stand-alone sel_ldr.

[David Alves]

Hum. I did know that open() was restricted and would actually like it for actual sandboxed programs, but being unable to run without opening the permissions is concerning.

Is this connected with dynamic linking? I.e does this happen becuase glibc is dynamically linked at runtime.

What would be the way to avoid having to pass -a? static linking against newlib?

Thanks for your insights

Best

David

[Victor Khimenko]

On Wed, Jul 29, 2015 at 9:53 PM, David Alves <david...@gmail.com> wrote:

Hum. I did know that open() was restricted and would actually like it for actual sandboxed programs, but being unable to run without opening the permissions is concerning.

Is this connected with dynamic linking? I.e does this happen becuase glibc is dynamically linked at runtime.

Yup. When you use dynamic linking you have many pieces which must be loaded: loader, main .nexe, libc, libstdc++ and so on. They are loaded by dynamic linker via op2n(2).

 

What would be the way to avoid having to pass -a? static linking against newlib?

Yup. Not necessarily newlib, you could do that with glibc, too:

  http://src.chromium.org/viewvc/native_client/trunk/src/native_client/tests/glibc_static_test/nacl.scons?revision=8664

Of course even statically linked glibc program could try to load stuff from the filesystem (functions like gettext(3) or inconv(3) tend do that).

[David Alves]

Nice, managed to make some progress by statically linking glibc. Thanks

Regarding IO, is the sandboxed code allowed to read any file descriptors passed in the command line, or do they have to be socket descriptors?

That is could I, for instance, vmsplice a shared memory region into a named pipe and pass it to the sandbox somehow?

If not, are comm speeds still unix socket like (i.e. like 2x slower than shared mem with rpc)?

Regarding the pepper IO API how does it work regarding IO, does it receive/send everything through sockets to the browser?

Again, any insights are greatly appreciated.

Best

David

To unsubscribe from this group and stop receiving emails from it, send an email to native-client-discuss+unsub...@googlegroups.com.

To post to this group, send email to native-cli...@googlegroups.com.
Visit this group at http://groups.google.com/group/native-client-discuss.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to a topic in the Google Groups "Native-Client-Discuss" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/native-client-discuss/Q3xZ5qF9JCI/unsubscribe.

To unsubscribe from this group and all its topics, send an email to native-client-discuss+unsub...@googlegroups.com.

To post to this group, send email to native-cli...@googlegroups.com.
Visit this group at http://groups.google.com/group/native-client-discuss.
For more options, visit https://groups.google.com/d/optout.

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

To unsubscribe from this group and stop receiving emails from it, send an email to native-client-discuss+unsub...@googlegroups.com.