Bug 178973

Caillon, whats the status of this ? 

Issue in NSPR based on my reading of Uli's link.  I think this is different from
bug 180726, but not sure.

/nsprpub/lib/msgc/src/unixgc.c, line 93 -- addr = mmap(lastaddr, size,
PROT_READ|PROT_WRITE|PROT_EXEC,
/nsprpub/lib/msgc/src/unixgc.c, line 123 -- addr = mmap(base + oldSize,
allocSize, PROT_READ|PROT_WRITE|PROT_EXEC,
/nsprpub/pr/src/md/unix/nextstep.c, line 146 -- case PROT_EXEC: mach_prot =
VM_PROT_EXECUTE; break;
/nsprpub/pr/src/md/unix/unix.c, line 2945 -- prot |= PROT_EXEC;

The /nsprpub/pr/src/md/unix/unix.c case is:

    /*
     * On Alpha Linux, the user-level thread stack needs
     * to be made executable because longjmp/signal seem
     * to put machine instructions on the stack.
     */
#if defined(LINUX) && defined(__alpha)
    prot |= PROT_EXEC;
#endif

No problem for us.  If somebody cares about Alpha they could look at it.

/nsprpub/pr/src/md/unix/nextstep.c is also irrelevant, who cares aobut NextStep?

The first case in /nsprpub/lib/msgc/src/unixgc.c is a real issue.  It simply
shouldn't be necessary to have execution permission.  If somebody needs it this
should be explicitly requested.  The second case is commented out.

Wan-Teh, it seems heap memory allocation in NSPR requests executable memory,
which is undesirable by selinux.

(In reply to comment #2)
> /nsprpub/lib/msgc/src/unixgc.c, line 93 -- addr = mmap(lastaddr, size,
> PROT_READ|PROT_WRITE|PROT_EXEC,
> /nsprpub/lib/msgc/src/unixgc.c, line 123 -- addr = mmap(base + oldSize,
> allocSize, PROT_READ|PROT_WRITE|PROT_EXEC,

It doesn't look like anything actually builds this file; there are no references
to the msgc directory from outside of it.

The four uses of PROT_EXEC that caillon listed in
comment 2 are all in dead code.

Dan, the Hardware field of this bug report is set to All.
what hardware have you reproduced this bug on?  If you
only saw this bug with a 64-bit Firefox build for x86_64,
this bug could be a duplicate of bug 180726.  Can you
still reproduce this bug?

I have not been able to reproduce, so the bug very well could be coming from X86_64.

With the information we have, and the fact that this
bug has been fixed, I'm marking this bug a duplicate of
bug 180726.

*** This bug has been marked as a duplicate of 180726 ***

execstack and execmem are two different things.  I don't think they are the same
bug.

Good point, caillon.  Should we resolve this bug WORKSFORME
then?

Just to make sure I've done my due diligence, I searched for
PROT_EXEC in the Firefox 1.5 source tree:

http://lxr.mozilla.org/mozilla1.8.0/search?string=PROT_EXEC

I got the following hits:

/calendar/libical/src/libical/vsnprintf.c, line 99 --
PROT_READ|PROT_WRITE|PROT_EXEC) == -1)
/gc/boehm/os_dep.c, line 139 -- # define OPT_PROT_EXEC PROT_EXEC
/gc/boehm/os_dep.c, line 141 -- # define OPT_PROT_EXEC 0
/gc/boehm/os_dep.c, line 1067 -- result = mmap(last_addr, bytes, PROT_READ |
PROT_WRITE | OPT_PROT_EXEC,
/gc/boehm/os_dep.c, line 1410 -- PROT_READ | OPT_PROT_EXEC) < 0) { \
/gc/boehm/os_dep.c, line 1415 -- PROT_WRITE | PROT_READ | OPT_PROT_EXEC ) < 0) { \
/nsprpub/lib/msgc/src/unixgc.c, line 93 -- addr = mmap(lastaddr, size,
PROT_READ|PROT_WRITE|PROT_EXEC,
/nsprpub/lib/msgc/src/unixgc.c, line 123 -- addr = mmap(base + oldSize,
allocSize, PROT_READ|PROT_WRITE|PROT_EXEC,
/nsprpub/pr/src/md/unix/nextstep.c, line 146 -- case PROT_EXEC: mach_prot =
VM_PROT_EXECUTE; break;
/nsprpub/pr/src/md/unix/unix.c, line 2945 -- prot |= PROT_EXEC;

I believe the first file is not used by Firefox.
The second file (five hits) seems to be an optional,
memory-leak debugging feature.
The last four hits in NSPR are what caillon reported
in comment 2; they are all in dead code (not compiled).

> execstack and execmem are two different things.  
> I don't think they are the same bug.

I just made a final test.
On my rawhide x86_64 system, I reinstalled the older NSS package that does not
have the fix.

Then I ran firefox.

We know that we had an "execstack" problem. However, the log messages I get
mention "execmem". I think that's another indication that what has been reported
here is the same bug.

Could very well be then.

Kai, thank you for verifying that the executable stack
in NSS caused an "execmem" log message.

*** This bug has been marked as a duplicate of 180726 ***