New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cmd/link: reserve space for dynamic section for GOOS=nacl #22129

Open
4ad opened this Issue Oct 4, 2017 · 4 comments

Comments

Projects
None yet
3 participants
@4ad
Member

4ad commented Oct 4, 2017

The Native Client sandbox has support for dynamic code generation and patching at runtime. This is done safely using the regular NaCl checks so it preserves the sandbox properties.

Address space for dynamic code is reserved with the NaCl dyncode_create system call. Go currently has access to this system call. The actual address space comes from a dynamic section created at load time by NaCl. This section is placed between the .text and .rodata sections.

Currently the Go linker places the .rodata section right next to the .text section, so the NaCl dynamic loader doesn't have any space to create the dynamic text section. I propose for GOOS=nacl we leave a sizeable gap between .text and .rodata so that the NaCl dynamic loader has enough space to create the dynamic text section. This is trivial to accomplish, it's a one line-patch to go/src/cmd/link/internal/ld/data.go:/address/, I tested it and it works.

One reason to enable this functionality would be to allow creating performant interpreters that use JIT technology.

Another reason would be the fact that NaCl might stop supporting non-dynamic-text-enabled executables in the future. The file native_client/src/trusted/service_runtime/sel_ldr.h has the following comment in it:

  /*
   * may reject nexes that are incompatible w/ dynamic-text in the near future
   */

For people who do not wish to have access to dynamic code generation NaCl provides the NACL_DISABLE_DYNAMIC_LOADING environment variable, which turns off dynamic text section generation.

@4ad 4ad added this to the Proposal milestone Oct 4, 2017

@4ad 4ad self-assigned this Oct 4, 2017

@mdempsky

This comment has been minimized.

Member

mdempsky commented Oct 4, 2017

Are there any downsides to doing this? I'm guessing it just bloats the executable a little bit because of internal padding?

If that's the only issue, this seems fine to me.

@4ad

This comment has been minimized.

Member

4ad commented Oct 4, 2017

It doesn't bloat the executable because this just sets a different virtual load address for the .rodata segment. There is no actual space wasted in the executable.

A downside would be that in the current NaCl implementation a process can't use that memory for anything else, and a process has only 32 (31?) bits of address space. We would probably need to size this gap to be the same as the one set by the C toolchain instead of making it too big.

@mdempsky

This comment has been minimized.

Member

mdempsky commented Oct 4, 2017

I see. Matching the NaCl C toolchain sounds reasonable to me.

@rsc

This comment has been minimized.

Contributor

rsc commented Oct 16, 2017

Yes, go ahead, please do what the C toolchain does. If this causes problems for any of our uses we can back it out, although I doubt we'll need to. Thanks.

@rsc rsc changed the title from proposal: cmd/link: enable space for dynamic section for GOOS=nacl to cmd/link: enable space for dynamic section for GOOS=nacl Oct 16, 2017

@rsc rsc changed the title from cmd/link: enable space for dynamic section for GOOS=nacl to cmd/link: reserve space for dynamic section for GOOS=nacl Oct 16, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment