Arbitrary size limit for code segment ?

106 views
Skip to first unread message

AlainC

unread,
Apr 16, 2014, 9:23:50 AM4/16/14
to native-cli...@googlegroups.com
Hi all,

When building with NaCl SDK - pepper_34, we get the following error at translation time in the browser with some of our pexes on Chrome 34:
  • NativeClient: ELF executable's code segment is larger than the arbitrary size limit imposed to mitigate spraying attacks (index):1
  • NativeClient: [10104,2708:11:54:20.185000] NaClAppLoadFileAslr: Code segment size (33910080 bytes) exceeds limit (33554432 bytes) util.js:19
  • NativeClient: [10104,2708:11:54:20.186000] NaClAppStartModule: error loading module util.js:19
  • NativeClient: [10104,2708:11:54:20.186000] reap logs util.js:19
I didn't find any clue except some obscure code change on Chromium code...

Any suggestion is welcome for bypassing this limitation...

Thanks

AlainC

unread,
Apr 16, 2014, 9:43:37 AM4/16/14
to native-cli...@googlegroups.com
I forgot to mention an important point : we use --pnacl-exceptions=sjlj to enable exception, which double the pexe code size (~13 Mb instead of 7) when used...
The pexe produced without JSLJ is compiled to nexe with no trouble.

JF Bastien

unread,
Apr 16, 2014, 1:30:13 PM4/16/14
to native-cli...@googlegroups.com
Hi Alain,

How big is the nexe when you translate pexe->nexe offline?

We could increase the limit, it's indeed arbitrary and was seen as a decent security benefit by our security team. I'll reach out to them.

JF


On Wed, Apr 16, 2014 at 6:43 AM, AlainC <acor...@tftlabs.com> wrote:
I forgot to mention an important point : we use --pnacl-exceptions=sjlj to enable exception, which double the pexe code size (~13 Mb instead of 7) when used...
The pexe produced without JSLJ is compiled to nexe with no trouble.

--
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.

JF Bastien

unread,
Apr 16, 2014, 2:09:12 PM4/16/14
to native-cli...@googlegroups.com
I sent a CL to double the limit:

AlainC

unread,
Apr 17, 2014, 5:41:59 AM4/17/14
to native-cli...@googlegroups.com
Ok, thanks.

For a pexe of 13 Mb, translated with options -O0 -arch x86-64, we get a nexe of 43 Mb !!!

The "normal" pexe produced with pepper_32 without --pnacl-exceptions=sjlj was 7 Mb and produce a nexe of 18 Mb.
The size of the nexe produced directly with pepper_32 (no PNaCl involved) is 17 Mb.

Meanwhile, do we have a way to bypass the arbitrary limitation or are we stuck until Chrome update occurs ?

JF Bastien

unread,
Apr 17, 2014, 10:13:29 AM4/17/14
to native-cli...@googlegroups.com

You can test locally with Chrome canary (once it picks up the change), but it will indeed only be available in Chrome 35 stable.

--

AlainC

unread,
Apr 23, 2014, 2:24:06 AM4/23/14
to native-cli...@googlegroups.com

On Thursday, April 17, 2014 4:13:29 PM UTC+2, JF Bastien wrote:

You can test locally with Chrome canary (once it picks up the change), but it will indeed only be available in Chrome 35 stable.


It is Ok with Canary 36.0.1950.0.

By the way, have you any clue why the size of our pexe built with with --pnacl-exceptions=sjlj option is around twice the size of the "normal" pexe.
As far as I understood, sjlj implies try... catch... being replaced by setjmp... longjmp..., so the size should not vary too much...

Victor Khimenko

unread,
Apr 23, 2014, 4:09:46 AM4/23/14
to Native Client Discuss
Not just try... catch, but also every function without try... catch if it allocates objects with destructors on stack.

JF Bastien

unread,
Apr 23, 2014, 9:34:40 AM4/23/14
to native-cli...@googlegroups.com

We'll try to make his overhead more acceptable, as well as implement zero-cost exception handling in PNaCl. It's a pretty big ABI though, so it's not a simple thing.

Eric Sherouse

unread,
Oct 3, 2016, 6:21:37 PM10/3/16
to Native-Client-Discuss
Hello,

I'm going to resurrect this thread because I think it is the best place for my post.

I'd like to ask if we can increase the code section size again. Currently the limit appears to be 67108864 bytes, and the PNaCl application I am developing has a code section size of 93519872 bytes when compiled with exception handling. When I compile without exception handling, my app loads perfectly, however when an exception is thrown, my app crashes. I can detect a crash in javascript and reload the app from a particular state, but obviously if my app crashes too frequently, it is throttled. My app is built around a 3rd party library that heavily uses exceptions, and so the user experience of my app suffers even under normal use. I understand the security reasons for having an upper limit. I suppose the question is: are you willing to increase the limit any further, and if so, how high are you willing to go?

I've been testing this application for about 9 months during a 'beta' period, and the most frequent complaint I've received is about the poor user experience as a result of crashing too often (because the 3rd party app throws exceptions). In an attempt to decrease the code section size of my app, I've scrapped certain features and re-implemented others so that I don't have to include various sub modules of the 3rd party library I am using. I have also tried various compiler optimizations to reduce the size. 93519872 bytes is as low as I can get it with the resources that I have. It would be extremely helpful to me if this upper limit was increased to something that would accommodate the application I am working on. 

I look forward to hearing your thoughts.

Best Regards,
Eric

Eric Sherouse

unread,
Oct 21, 2016, 9:47:15 AM10/21/16
to Native-Client-Discuss
Hi,

Curious if anyone has any thoughts on this?

Thanks for considering.

Eric
Reply all
Reply to author
Forward
0 new messages