Enable stack protector on mingw-clang builds
Categories
(Core :: Security, enhancement)
Tracking
()
People
(Reporter: gcp, Assigned: tjr)
References
(Blocks 4 open bugs)
Details
Attachments
(2 files)
47 bytes,
text/x-phabricator-request
|
Details | Review | |
1.85 KB,
patch
|
RyanVM
:
approval-mozilla-esr68+
|
Details | Diff | Splinter Review |
Assignee | ||
Updated•6 years ago
|
Comment 1•5 years ago
|
||
Quoting from bug 1503589:
Here is how llvm-mingw toolchain builds it:
https://github.com/mstorsjo/llvm-mingw/blob/master/build-libssp.sh
We could do the same in our toolchain build script (we don't need .dll version, just static library, so it's a bit simpler than tat) or even use llvm-mingw script for that.
So, I tried a bunch of things (including building the libssp libs as llvm-mingw does it). But in all cases it turns out that a) we need the .dll version as all the binaries seem to get linked against it. And b) the resulting bundles crash both on 64bit and 32bit Windows systems.
On the Firefox side I only removed the mingw-w64-clang exclusion for stack protection support.
I won't have time to look at it closer before we switch to ESR 68 at the end of October.
Comment 2•5 years ago
|
||
So, I tried a bunch of things (including building the libssp libs as llvm-mingw does it). But in all cases it turns out that a) we need the .dll version as all the binaries seem to get linked against it.
If you keep both libssp.dll.a and libssp.a from the build, you'll probably get it linked dynamically. But just get rid of libssp.dll.a and it should end up linking it statically instead. (Or just don't build it - this commit shows what I changed when I made it available as a DLL: https://github.com/mstorsjo/llvm-mingw/commit/d3ec443f9248a83cfbdd4bef311a7191d6acc311#diff-61ff93e7b0a019a6b2791677ea7c6770)
And b) the resulting bundles crash both on 64bit and 32bit Windows systems.
Now that's surprising though. (VLC builds with stack protector enabled via -fstack-protector-strong
, with these libs, and runs fine in my tests.)
Comment 3•5 years ago
|
||
(In reply to Martin Storsjö from comment #2)
So, I tried a bunch of things (including building the libssp libs as llvm-mingw does it). But in all cases it turns out that a) we need the .dll version as all the binaries seem to get linked against it.
If you keep both libssp.dll.a and libssp.a from the build, you'll probably get it linked dynamically. But just get rid of libssp.dll.a and it should end up linking it statically instead. (Or just don't build it - this commit shows what I changed when I made it available as a DLL: https://github.com/mstorsjo/llvm-mingw/commit/d3ec443f9248a83cfbdd4bef311a7191d6acc311#diff-61ff93e7b0a019a6b2791677ea7c6770)
And b) the resulting bundles crash both on 64bit and 32bit Windows systems.
Now that's surprising though. (VLC builds with stack protector enabled via
-fstack-protector-strong
, with these libs, and runs fine in my tests.)
Both a) and b) go away by just copying libssp.a and libssp_nonshared.a, leaving the .dll.a out, thanks! So, we are good for now to test this in our next Tor Browser alpha release I think. (I just copied the libs over from mingw-w64/gcc which we need to build anyway for other parts for Tor Browser).
Assignee | ||
Comment 4•5 years ago
|
||
Assignee | ||
Comment 5•5 years ago
|
||
Updated•5 years ago
|
Comment 7•5 years ago
|
||
bugherder |
Assignee | ||
Comment 8•5 years ago
|
||
[Approval Request Comment]
If this is not a sec:{high,crit} bug, please state case for ESR consideration:
Build improvements to the mingw-clang build to reach parity with Tor Browser's current build
User impact if declined: The mingw-clang build on esr68 won't match Tor's. (They use stack protector)
Fix Landed on Version: Nightly 12/10
Risk to taking this patch (and alternatives if risky): The mingw-clang build might break.
Note: Land Bug 1601701 in esr68 before this one.
Comment 9•5 years ago
|
||
Comment 10•5 years ago
|
||
bugherder uplift |
Updated•5 years ago
|
Description
•