Closed Bug 486537 Opened 11 years ago Closed 11 years ago

Disable execstack in freebl x86_64 builds on Linux


(NSS :: Libraries, defect)

Not set


(Not tracked)



(Reporter: KaiE, Assigned: KaiE)



(Whiteboard: FIPS)


(3 files)

Originally reported here:

The current build flags cause libfreebl3 to get built with the execstack flag, causing trouble for selinux.
Patch proposed by Ulrich
Attachment #370674 - Flags: review?(wtc)
Comment on attachment 370674 [details] [diff] [review]
Patch v1 (checked in)

r+ rrelyea

for 3.12.4
Attachment #370674 - Flags: superreview+
Target Milestone: --- → 3.12.4
Comment on attachment 370674 [details] [diff] [review]
Patch v1 (checked in)

Is this an issue only for x86_64 ?
(In reply to comment #3)
> (From update of attachment 370674 [details] [diff] [review])
> Is this an issue only for x86_64 ?

Yes.  The offending asm file is only on x86 and only Linux performs the stack tests.  So it's even Linux-x86-64 specific.
Attachment #370674 - Flags: review?(wtc) → review+
Comment on attachment 370674 [details] [diff] [review]
Patch v1 (checked in)


In the past, we have been solving this problem by
adding this magic section to the end of every .s file:

  # Magic indicating no need for an executable stack
  .section .note.GNU-stack,"",@progbits

For example, see

So you can also fix this bug by adding this section
to the new .s files added in NSS 3.12.3 (I believe
intel-ase.s is the only one).  I would do that.

If you decide to use the -Wa,--noexecstack solution,
you should do it for all CPU architectures.
In reply to comment 5,
I remember that we had to remove that magic pseudo-op from one of our .s 
files because gas on some platform didn't recognize it.  I prefer solving
it through a command line option instead of a pseudo-op, if possible,
because it's easier to have command lines that vary by platform than to 
have assembler source that varies by platform.
To be future-proof, you may want to use -Wa,--noexecstack
for all processor architectures.
We can also set it in coreconf/, which will take
care of all the NSS and JSS directories.
Comment on attachment 370674 [details] [diff] [review]
Patch v1 (checked in)

Kai, I noticed that you haven't checked in this patch, so I checked it in 
on the NSS trunk (NSS 3.12.4).  I actually prefer passing the -Wa,--noexecstack
flag for all processor architectures (we also have assembly files for
x86), but I checked in this patch because it has received review+.

Checking in Makefile;
/cvsroot/mozilla/security/nss/lib/freebl/Makefile,v  <--  Makefile
new revision: 1.106; previous revision: 1.105
Attachment #370674 - Attachment description: Patch v1 → Patch v1 (checked in)
Assignee: nobody → kaie
Closed: 11 years ago
Resolution: --- → FIXED
Duplicate of this bug: 488959
This bug was originally reported against x86_64 builds on Linux, and was only 
fixed for that platform.  :(

Now it has been reported again for x86_32 builds on Linux in bug 499584.
I propose that we back out the fix committed for this bug, and commit 
wan-Teh's patch in attachment 370782 [details] [diff] [review] instead.  Please follow this issue in 
bug 499584.
Hardware: x86 → x86_64
Summary: disable execstack when building freebl → Disable execstack in freebl x86_64 builds on Linux
Whiteboard: FIPS
Duplicate of this bug: 499584
No. I was mistaken.  Bug 499584 was also about x86_64, and is a duplicate 
of this bug.  However, I do think we should fix it as shown in Wan-Teh's 
patch in attachment 370782 [details] [diff] [review], so that it is fixed for x86_32 also.
Comment on attachment 370782 [details] [diff] [review]
Set it in coreconf/

If you check in this patch, please back out patch v1 (attachment 370674 [details] [diff] [review])
to avoid duplicate -Wa,--noexecstack flags.
Wan-Teh, does the duplicate cause a problem with the compilier?

If not, I would prefer to leave it until the next time we open the FIPS token tree.

Comment on attachment 370782 [details] [diff] [review]
Set it in coreconf/

Then we can wait until then to check in this patch.
I don't think we will add assembly code to any directory
other than lib/freebl.
Version: trunk → 3.12.3
Is this something that should be backported to 3.12.3 for those users still using that branch?
Reed, to what branch(es) are you referring?
Naturally, we'd prefer that any products using 3.12.3 simply update to 
3.12.4 now that it has been released.
Linux distros typically use "system NSS" and can easily upgrade to 3.12.4 or even apply this patch to their own 3.12.3 version if they prefer. Firefox will be upgrading to 3.12.4 and any effort should go into making that happen rather than putting this patch on 3.12.3
Duplicate of this bug: 522462
You need to log in before you can comment on or make changes to this bug.