Disable registration of Breakpad's signal handler for Native Client

Disable registration of Breakpad's signal handler for Native Client

This partially undoes r71459.

This fixes a security vulnerability that occurs when the NaCl revision
is updated to r4598 or later.  That revision changes NaCl's
sel_main_chrome.c so that it no longer registers a signal handler, but
instead leaves Breakpad's signal handler (registered by Chrome) in
place.

The vulnerability would allow NaCl untrusted code to escape NaCl's
inner sandbox on x86-32 Linux.

This is because although NaCl's signal handler knows how to safely
handle faults from NaCl x86-32 sandboxed code, Breakpad's signal
handler does not.  Breakpad's signal handler does not restore %gs.

BUG=http://code.google.com/p/nativeclient/issues/detail?id=1607
TEST=assertion to be added on the NaCl side (http://codereview.chromium.org/6798008/)

Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=80581

[Cliff L. Biffle, 2011-04-05 21:20:50]

There's still a call to InitCrashReporter over in nacl_main.cc -- make sure it's
safe.

[bsy, 2011-04-05 21:24:20]

d flag is now an issue.  please reopen that since afaik the nacl signal
handler does not cld on entry.

-bsy

On Tue, Apr 5, 2011 at 2:20 PM, <cbiffle@google.com> wrote:

> There's still a call to InitCrashReporter over in nacl_main.cc -- make sure
> it's
> safe.
>
>
> http://codereview.chromium.org/6677168/
>



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

[cstefansen, 2011-04-05 21:45:27]

LGTM (with the proviso that we find a way to re-enable Breakpad before
launching).

On 2011/04/05 21:24:20, bsy wrote:
> d flag is now an issue.  please reopen that since afaik the nacl signal
> handler does not cld on entry.
> 
> -bsy
> 
> On Tue, Apr 5, 2011 at 2:20 PM, <mailto:cbiffle@google.com> wrote:
> 
> > There's still a call to InitCrashReporter over in nacl_main.cc -- make sure
> > it's
> > safe.
> >
> >
> > http://codereview.chromium.org/6677168/
> >
> 
> 
> 
> -- 
> bennet s yee
> i usually don't capitalize due to mild tendonitis

[Cliff L. Biffle, 2011-04-05 21:47:14]

On Tue, Apr 5, 2011 at 2:24 PM, Bennet Yee (余仕斌) <bsy@google.com> wrote:

> d flag is now an issue.  please reopen that since afaik the nacl signal
> handler does not cld on entry.


Is this relevant to this change?  I don't really follow.

-- 
Cliff L. Biffle
NaCl Team, Google, Inc.

[Mark Seaborn, 2011-04-05 21:53:07]

On 5 April 2011 14:20, <cbiffle@google.com> wrote:

> There's still a call to InitCrashReporter over in nacl_main.cc -- make sure
> it's
> safe.
>

Christian's earlier Chrome-side change (
http://src.chromium.org/viewvc/chrome?view=rev&revision=71459) changed
NaClMain() in chrome/nacl/nacl_main.cc to call InitCrashReporter() (which is
Linux-specific).

It appears that this code was since refactored so that InitCrashReporter()
gets called in a centralised place.  (This happened in
http://src.chromium.org/viewvc/chrome?view=rev&revision=77834)  But that is
fine:  with my change, InitCrashReporter() should become safe so that it
does not enable the Breakpad signal handler in Chrome's sel_ldr process.

I intend to make a NaCl-side change to assert that no signal handlers are
registered, so that Chrome-side changes cannot introduce this problem again.

Mark

[bsy, 2011-04-05 21:57:00]

sorry, am working from a cafe due to child care, so somewhat succinct.

the d flag thing is needed for some signal handling.  this CL disables breakpad,
which is fine.  for the issue & CL that eventually re-enables breakpad, we need
to essentially provide at least a thin wrapper -- a version of nacl signal
handling that does cld prior to dispatching to the breakpad signal handler.

so, the comment is not relevant to the CL per se, but for a future CL....

[noelallen_use_chromium, 2011-04-05 23:39:09]

LGTM