Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Loading…

enable full GCC Stack-smashing protection for all OSes #1674

Merged
merged 2 commits into from

8 participants

P. Kaufmann BitcoinPullTester Wladimir J. van der Laan Gregory Maxwell Pieter Wuille Matt Corallo Jeff Garzik Gavin Andresen
P. Kaufmann
  • change our hardening options to use -fstack-protector-all even for Windows builds, as we recently switched to a newer compiler suite
  • also removes an obsolete workaround for GCC 4.5 (https://bugs.launchpad.net/ubuntu/+source/gcc-4.5/+bug/691722), which required to first set -fno-stack-protector, before -fstack-protector-all
BitcoinPullTester

Automatic sanity-testing: PASSED, see http://jenkins.bluematt.me/pull-tester/162d57776f40fe05d3df512ca021bc0c3865c970 for binaries and test log.

P. Kaufmann

I tried the version from @BitcoinPullTester and it starts just fine, no crashes related to stack-protector on Win7 x64 here.

Wladimir J. van der Laan
Owner

Have you tried some actual stack-smashing fun yet?

P. Kaufmann

@laanwj No I did not investigate further, until now I just enabled it. Have you got some links for stack-smashing fun :)? Forget my question, I'm going to test it now :).

Wladimir J. van der Laan
Owner

Well the idea is to make a buffer on the stack and write more into it and than the size of the buffer (ie, char buffer[1024]; buffer[1025]=0xff; .. and so on the values don't really matter )

Add a button that does that , click the button, and see if it gets detected (make sure you don't write too far outside the buffer, maybe make sure there is a variable after it, otherwise you'll always trigger a crash).

We'll also have to investigate the performance impact. I'm not sure how this protection really works, but if it continuously checks every buffer on the stack I can see it become lots slower.

P. Kaufmann
    char buffer[1024];
    buffer[1025]=0xff;

    printf("%s", buffer);

The above code seems to trigger SSP detection, see this where libssp-0.dll is mentioned. Well now I need to check if the application is halted and aborted or executes further ... before crashing.

 Problemereignisname:   APPCRASH
  Anwendungsname:   bitcoin-qt.exe
  Anwendungsversion:    0.6.99.0
  Anwendungszeitstempel:    502cb87a
  Fehlermodulname:  libssp-0.dll
P. Kaufmann

I tried the same code without SPP enabled and the applications simply continues, which is what malicious code should do, right ;)?

Wladimir J. van der Laan
Owner

Yes, that's expected

Gregory Maxwell
Owner

Having SSP in windows is great news! Should also make sure bitcoind gets built with it.

Can you time a blockchain sync with and without (perhaps on testnet?) to make sure it's not slaying it?

Wladimir J. van der Laan
Owner

What was the command line again? Something like:

  • remove blkindex.dat
  • bitcoin-qt -loadblock=blk0001.dat
Gregory Maxwell
Owner

Move the databases out of the way then bitcoin-qt -loadblock=notblk0001.dat (needs to be a separate file)

Wladimir J. van der Laan
Owner

In that case I guess it it easiest to pass -datadir= a new, empty directory, then -loadblock= your current blk0001.dat into it.

Then time how long the AppInit2() call takes (or even better, change the debug log line in LoadExternalBlockFile to state how long it took).

P. Kaufmann

@laanwj You want me to use -loadblock= as benchmark if I understand you correctly?

Pieter Wuille
Owner

@Diapolo that's correct

P. Kaufmann

I'm currently benchmarking ... one thing, Bitcoin-Qt shows just "Loading Wallet..." message, which I think is missleading when doing a block-file import, no?

Wladimir J. van der Laan
Owner
P. Kaufmann

@laanwj Where is that part located in the code?

1st result without this patch:
08/17/12 09:59:28 Loaded 188524 blocks from external file in 5399340ms

2nd result with this patch:
08/17/12 11:49:21 Loaded 188524 blocks from external file in 5398498ms
08/17/12 13:44:26 Loaded 188524 blocks from external file in 5425789ms (verification run)

To me this looks like SSP is no bottleneck, when importing block-files.

Pieter Wuille
Owner

Looks good to me.

P. Kaufmann

This currently seems to be not working with Gitian or @BitcoinPullTester builds, as the RELEASE=1 scope seems to be not taken into account (see #1673).

P. Kaufmann

Alright, #1673 is working now, as we enabled the flags there for both RELEASE and DEBUG builds now, but what about the stack protector? We have 2 options, do the same here or ensure RELEASE=1 get's passed to qmake to ensure the block where the SPP flags reside is processed, comments?

Wladimir J. van der Laan
Owner

Just enable it always. It's nice to find stack overwrite bugs while debugging.

P. Kaufmann

Updated to be enabled for RELEASE and DEBUG builds.

Wladimir J. van der Laan
Owner

Ok, now the upcoming executable created by bitcoin pulltester needs to be carefully tested, to see if it doesn't crash. After all, previous experiments with the cross-compiled executable are probably invalid as the flags weren't really passed.

P. Kaufmann

What about 2 flags for the UI client -test-dep and -test-ssp, which would use our small test codes for verifiying the feature is working. We should perhaps not extend the help message, but it would help testing the official client without the need to do an own build?

Wladimir J. van der Laan
Owner

NACK putting those in the official client.

That's what the autotesters are for. Though testing these might turn out to be tricky, as you want to reproduce crash behavior and somehow find out what caused the crash.

Also, mind that BlueMatt's pulltester was never meant to enable testing "without the need to do your own build". It is just a final acceptance test. Not a way to get your stuff built for free.

P. Kaufmann

I can do own builds, which are not comparable with official release builds. I just thought about a possibility to verify such features in official client versions :).

P. Kaufmann

Is anyone able to comment, why the latest build fails (http://jenkins.bluematt.me/pull-tester/9ad1341d46851020b2342670fb73004b909fc80b/test.log)?

These are the errors I can see, but I'm not sure if or how thay relate to SSP:

ERROR: mempool transaction missing input
ERROR: ConnectInputs() : 39393b8fd0 P2SH VerifySignature failed

and

+ ./release/bitcoin-qt_test.exe
wine: Unhandled page fault on write access to 0x00000014 at address 0x530b17 (thread 0009), starting debugger...
Application tried to create a window, but no driver could be loaded.
Make sure that your X server is running and that $DISPLAY is set correctly.
err:systray:initialize_systray Could not create tray window
Application tried to create a window, but no driver could be loaded.
Make sure that your X server is running and that $DISPLAY is set correctly.
Unhandled exception: page fault on write access to 0x00000014 in 32-bit code (0x00530b17).

Edit: Could be a problem of the cross-compile or the tests in Wine?

Edit 2: Found this one:

wine (0.9.19 uploaded to edgy) does not work with stack-protection. Compiling with -fno-stack-protected solved this problem temporarily. (see: https://launchpad.net/distros/ubuntu/+source/wine/+bug/56965) 

Edit 3: Some Wine bugs related to stack protection: http://bugs.winehq.org/buglist.cgi?quicksearch=stack+protector

Wladimir J. van der Laan
Owner

I somehow think this is not a wine problem, but the same bug that got us to disable stack-protector on windows before. Looks like corruption.

Have you tested the resulting executables in windows?

P. Kaufmann

@laanwj I would have tested the executable, but @BitcoinPullTester did not generate any bitcoin-qt.exe.

Wladimir J. van der Laan
Owner

Hmm, even the autotester executable is not downloadable. I guess it doesn't give you those if the test fails.

Pieter Wuille
Owner

The mempool error is expected; some of the code in the testcases intentionally causes errors, and checks whether they do occur.

Regarding the Edit2 above: seems to only way to get this accepted by pulltester is to disable SSP specially in the pulltester builds...

P. Kaufmann

Would it be possible to compile a bitcoin-qt.exe before doing any tests? It would be nice to know if just the automatic sanity tests fail or if the exe-file is really not running under Windows (which I can only check if it get's compiled). I'm willing to do some further testing and investigation here...

Matt Corallo

I dont see why the bugs linked above would be the cause here, they effected wine version 0.9.N, the version running on jenkins is 1.2.2. All files which were built before a failure are on the site (including test_bitcoin.exe, which is in src), and if that's failing, there is no reason bitcoind.exe would work, so that would need fixed first anyway

Edit: sorry, didn't catch that its actually bitcoin-qt_test.exe which is failing, that should be there as well, see release/, and, again, if bitcoin-qt_test.exe is failing, there is no reason bitcoin-qt.exe would work.

P. Kaufmann

@TheBlueMatt I'll try one more rebase with --fstack-protector (instead of -fstack-protector-all) and if that fails the problem with SSP on Windows is still there (IMHO caused by the cross-compilation somehow as my own build runs just fine).

Current bitcoin-qt_test.exe crashes for me too.

Gregory Maxwell
Owner

I'm really super doubtful that cross-compilation would be the issue, though different GCC versions might be. The crash thats being reported— a dereference of a near-null pointer sounds like a bug to me; one that may go unnoticed on windows because page 0 is mapped on windows.

P. Kaufmann

Now that is interesting with just -fstack-protector as flag, the @BitcoinPullTester build passes the sanity-testing, BUT when testing it with testnet it leads to missbehaviour (blkindex.dat could not be loaded or with a clean datadir it shows wallet.dat corrupted / damaged).

@gmaxwell Any idea how to track down your idea further, that this could be a bug? I think it's rather strange that -fstack-protector leads at least to a valid executable...

Jeff Garzik
Owner

@gmaxwell might be on to something. mingw builds against binary libs whose ABI occasionally changes due to C++ ABI changes etc.

Wladimir J. van der Laan
Owner

Could well be. What are the gcc versions involved? What gcc version do you use Diapolo? And which one for Bitcoin Pull tester by @TheBlueMatt? I suspect TheBlueMatt uses the version included in ubuntu lucid (4.4.x), Diapolo is using a more recent one included with mingw (4.6.x?).

Matt Corallo

ii mingw32 4.2.1.dfsg-2ubuntu1 Minimalist GNU win32 (cross) compiler
ii gcc 4:4.5.2-1ubuntu3 The GNU C compiler

P. Kaufmann

I'm currently using g++ (GCC) 4.7.0, but I used -fstack-protector-all with the stock minGW version (which is 4.4), that ships with the Qt Windows SDK and SSP was working and not causing any issues.

What more can I do to further assist here?

All dependency libs used by Bitcoin-Qt are compiled with gcc 4:4.5.2-1ubuntu3 The GNU C compiler before building our Windows executable?

Wladimir J. van der Laan
Owner

@diapolo: I suppose mingw32 4.2.1 is actually using gcc 4.2.1 for the cross compile, not 4.5.2.

P. Kaufmann

Well IMHO gcc 4.2.1 is old as the hills ... any chance to upgrade the used compiler?

Matt Corallo

The pull tester should be running the same version as gitian. If you want to use a newer version, test gitian (or run its build script in an Ubuntu VM if you don't feel like doing a physical install for gitian itself) and get that upgraded.

P. Kaufmann

@TheBlueMatt You are right, that @BitcoinPullTester and Gitian should use the same compiler versions. I was just asking, if someone is able to test-compile with a more current minGW version (at least 4.4) in Gitian or your setup. It drives me mad, that such a security mitigation is not working for Windows, as I'm sure Windows users are far more at risk to encounter an attack in comparison to other OSes.

Wladimir J. van der Laan
Owner

Even on Ubuntu Precise (12.04) the mingw g++ version is still i586-mingw32msvc-g++ (GCC) 4.2.1-sjlj (mingw32-2). To use a newer cross-compiler we'd have to build it ourselves.

Looks like ioerror (tor dev) got stack-protector-all to work with mingw cross compile by adding -lssp, though I'm not sure for what version:
https://twitter.com/ioerror/status/238197005946593280?uid=272871165&iid=am-212786989413456255665797433&nid=27+234

P. Kaufmann

Is -lssp a library we need to add? If you find some documentation about it please link that here, I didn't yet manage to find out anything about that flag.

Edit: I asked ioerror directly via Twitter, let's see...

Matt Corallo

@laanwj precise has two sets of mingw packages - the regular mingw is the same old version, but there is now a mingw-w64 (the 64-bit part is optional) which is gcc 4.6.3.

Matt Corallo

@Diapolo I'll look into compiling it myself later today if I get a chanace.

P. Kaufmann

@TheBlueMatt I greatly appreciate your efforts here :) (that goes to all others, who participate here).

Wladimir J. van der Laan
Owner

I've set up a cross-compile environment with i686-w64-mingw32 (gcc version 4.6.3), outside of gitian, eventually I managed to build a static bitcoin-qt.exe that works well. With -fstack-protector-all enabled.

  • I did have to add windows:LIBS += -Wl,-Bstatic -static-libgcc to bitcoin-qt.pro to succesfully build a static bitcoin-qt.exe
  • I had to upgrade boost to 1.51.0 to be compatible (otherwise I'd get the error reported here: https://svn.boost.org/trac/boost/ticket/4258 )
    • also needed to add LIBS += ... -lboost_chrono$$BOOST_LIB_SUFFIX, as boost::thread uses boost::chrono::system_clock::now()
  • I did have to comment out the ipcThread; for some reason I get a Expression: &get_map_unlocked() ==m assertion in windows_intermodule_singleton.hpp line 145 at startup. This does not seem to be related to the stack protector but to the new boost version. I have no idea what this code is doing, not in the least: http://www.boost.org/doc/libs/1_51_0_beta1/boost/interprocess/detail/windows_intermodule_singleton.hpp .
    • The new boost version is no longer using the monkey patch. This could be the problem?

With this mingw version, test_bitcoin.exe and bitcoin-qt_test.exe also check out fine with -fstack-protector-all --param ssp-buffer-size=1.

P. Kaufmann

@laanwj Great work and I have some comments to make to your findings.

  1. I'm asking myself, how Gitian creates a static bitcoin-qt.exe as I was never able to achieve this with my local setup. The current project file has windows:LIBS += -Wl,-Bstatic -static-libgcc not included, so where is the magic here?
  2. I'm currently using Boost 1.50 and in comparison to 1.49 no monkey patch was needed or active, as the Boost devs changed the parts of the interprocess code.
  3. Yes, Boost > 1.49 needs the compiled Chrono lib included, which is what I also observed.
  4. I didn't need to change any IPC code, but needed to remove typedef HANDLE pthread_t; from util.h and change pthread_t into HANDLE in CreateThread(), perhaps that is also of help for your build.
  5. I'll compile the Boost 1.51 libs and see if I encounter additional errors.

Can you upload your compiled version, I'm gona give it a run on a native Win7 x64 to verify it's working.

In the end I'm not sure what your findings are worth in terms of getting SSP to work with our official client builds, but a big thank you for your effort and time to investigate :).

Edit: The switch to Boost 1.51 caused no further compilation errors here.

Wladimir J. van der Laan
Owner
  1. I don't know. As long as things work, we don't ask questions :-) As I'm not building in gitian, it might be that my setup is slightly different, making this necessary. You do need to build Qt yourself to make a static executable, the pre-packaged Qt will not do this.

  2. I don't currently have time to dive deep into boost::ipc, It's a strange place full of magic to make objects behave as normal in shared memory, which seems overkill for something like sending URLs :/

  3. OK

  4. Didn't need to do that. I compiles with latest master with the changes I mentioned.

  5. Thanks

You can download the produced executable here (with commented out ipcInit, otherwise it's a pretty useless file :):
https://download.visucore.com/bitcoin/bitcoin-qt-20120823.zip

I also still intend to update the Qt version to 4.8.1. And integrate my findings back in gitian again. But not in time for 0.7rc1.

P. Kaufmann

@laanwj I tried your version and it's working, no crash and no strange errors after startup, looks good.

P. Kaufmann

Last failure is expected, as I reverted to -fstack-protector-all.

Pieter Wuille
Owner

Any reason why merging this would be a problem?

Wladimir J. van der Laan
Owner

We can merge this pull after MingGW version used for Windows cross-compile is at least 4.4, preferably 4.6. The currently used version is 4.2 which has corruption problems if this is enabled!

Of course, if diaplo updates this to only affect non-windows it can be merged.

P. Kaufmann

I would be rather sad if I update this to be mergeable, as I think it loses attention for Windows then.
I can for sure create a new pull, which does this for all OSes expect Windows and leave this as is, to keep the discussion present.

P. Kaufmann

@laanwj Any idea, why we need this (https://github.com/bitcoin/bitcoin/blob/master/bitcoin-qt.pro#L37) in the pro-file, but such a linker flag is not needed in makefile.unix (https://github.com/bitcoin/bitcoin/blob/master/src/makefile.unix#L71) for SSP?

I tried to remove the linker flag for bitcoin-qt, as I was somehow sure it is no linker flag, but that creates a ton of errors (doesn't work and needs to be in place).

Wladimir J. van der Laan
Owner

@diapolo The security options need to be passed to the linker as well as compiler. Note that at the bottom of makefile.unix we pass xCXXFLAGS as well as xLDFLAGS to the linker, at different positions in the argument list.

P. Kaufmann

I also found out that this option is needed for both (linker and compiler), as you said ;). But this just fails, because of the old GCC version or did I miss something new?

Edit: I closed this by mistake, clicked too fast :-D.

P. Kaufmann Diapolo closed this
P. Kaufmann Diapolo reopened this
Pieter Wuille
Owner

@laanwj So, ACK on this after #2106?

P. Kaufmann

@sipa That GCC version should be safe to use, but to be sure I asked you, if you could do a little test build with this pull included :).

P. Kaufmann

@sipa Works just fine, startup, IBD, create a TX... all things that couldn't even be tested with the old compiler suite :).

P. Kaufmann

Added a -static switch (after @gmaxwell suggested that), which works for my local build. Perhaps @sipa could integrate that into the leveldb17 test builds to see if the libssp-0.dll dependency is gone.

Edit: @laanwj What about adding CONFIG += static to the project file? Seems also right :).

P. Kaufmann

Too bad @BitcoinPullTester didn't yet build a binary...

P. Kaufmann

@TheBlueMatt

/usr/bin/ld: cannot find -lQtTest
collect2: ld returned 1 exit status
make: *** [bitcoin-qt_test] Error 1

I'm not sure if this is related to my pull, any idea?

P. Kaufmann

I need a little help over here :D, my own build is not working like expected with this pull included, I have to say I'm not using a static Qt, as I never managed to set that up for Windows. The dependency for libssp-0.dll is gone, when using QMAKE_LFLAGS *= -static, which was intended.

The observed problem is happening with the RPC console, let's say I just input foo, it crashes with am MSVC++ exception / APPCRASH, before printing out Method not found. I was able to debug this down to CRPCTable::execute() function and the crash is happening right after throw JSONRPCError(RPC_METHOD_NOT_FOUND, "Method not found");. Any ideas for this?

Also doing an QMAKE_LFLAGS -= -static after the stack-protector flag does not seem to change that.

P. Kaufmann

@sipa Your linked build does not contain the described error. I wonder how we can now check, that the stack-smashing protection is really still working.

I had code to trigger it, which caused a crash with a clear reference to libssp-0.dll on Windows. I wonder what it would look like with the recent static-change...

char SPP_buffer[1024];
SPP_buffer[1025]=0xff;

printf("%s", SPP_buffer);
BitcoinPullTester

@Diapolo it appears to be an issue with this pull, it appears to be making the default -static instead of it being dynamic as it used to be.

bitcoin-qt.pro
@@ -33,13 +33,11 @@ contains(RELEASE, 1) {
}
}
-!win32 {
+# use static linking
+QMAKE_LFLAGS *= -static
Pieter Wuille Owner
sipa added a note

Can you please make this -static windows-only?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Pieter Wuille
Owner

Also: can you make this change also for the daemon builds?

P. Kaufmann

@sipa Yes, I'll make that Windows only and add a commit, which also enabled this for bitcoind.

Still the open question, how can we verify what happens on Windows, when a SSP problem is caught and the app get's terminated with -static beeing active.

P. Kaufmann

@BitcoinPullTester Is the pull tester still using that ancient compiler suite or are you now using the same as @sipa in the leveldb17 pull?

I updated the pull to use -static only for Windows and extened the Windows makefiles for bitcoind to be equal feature-wise.

Matt Corallo

@Diapolo The issue is on the linux side, not the MinGW side, I dont believe the leveldb17 pull changes that?

Pieter Wuille
Owner

@Diapolo I included these changes in the leveldb17 branch (#2106), as it conflicted with other changes there.

P. Kaufmann

@sipa Can you do a testbuild for me with that code in init.cpp, to see what happens with -static keyword? It will crash, but I would like to know if there is a chance to see the process got terminated by GCCs stack protector.

I think we need to ensure we don't break it...

char SPP_buffer[1024];
SPP_buffer[1025]=0xff;

printf("%s", SPP_buffer);
Pieter Wuille
Owner

@Diapolo create a branch with the code you want to test, and point me to a commit id.

P. Kaufmann

Thanks, will do this tomorrow :). Hope we get that sorted out, would be nice to have leveldb17 branch + stack protector in and working, so we can look at other things.

Jeff Garzik
Owner

@Diapolo ping?

P. Kaufmann

@jgarzik As we are still using the same ancient GCC version I can't do anything here :-/.

P. Kaufmann

Is there any current progress in switching to a newer compiler version for our Gitian builds?

Wladimir J. van der Laan
Owner

Can be done after merging #3029.
Although the patch has to be completely reworked for the new build system.

P. Kaufmann

This should finally be possible now thanks to our new build system :).

P. Kaufmann

Where do I find the resulting Windows binaries within http://jenkins.bluematt.me/pull-tester/807ec70b377086ac8b19cc2629b967b02c0263e4?

Gavin Andresen

I'm working on having the pull-tester compile mingw/windows this afternoon. The pull-tester environment uses:

i586-mingw32msvc-g++ (GCC) 4.2.1-sjlj (mingw32-2)

P. Kaufmann

@gavinandresen I didn't know we haven't yet upgraded pull-tester environment. This patch should at least result in working Windows executables for official Gitian builds.

Gavin Andresen

I re-ran the pull-tester with windows builds enabled; the qt .exe is in win32-build/src/qt/

Oddly, the pull-tester passed it, although the Qt unit tests fail to run. I guess it crashes in a way that looks like the unit tests succeeded?

P. Kaufmann

@gavinandresen As long as we use this ancient i586-mingw32msvc-g++ (GCC) 4.2.1-sjlj (mingw32-2) compiler with pull-tester, we can't rely on it for creating or testing this pull I guess. Will download the qt exe and try it, it should crash or misbehave, as that was what happened before with pull-tester builds.

P. Kaufmann

Gavin, the resulting executables are crazy in size bitcoin-qt.exe has over 120MB and bitcoin.exe over 60MB.

P. Kaufmann

Also the bitcoin-qt.exe doesn't show an icon + it doesn't contain any meta-data (from bitcoin-qt-res.rc), wherars bitcoind.exe DOES contain that meta-data (from bitcoind-res.rc).

Gavin Andresen

@Diapolo : re executable size: they are not stripped (contain debugging symbols). I assume they crash because pull-tester is using an ancient mingw?

Wladimir J. van der Laan
Owner

@gavinandresen Yes, they crash because of the ancient mingw version, so this is still pending on a pulltester mingw update.

P. Kaufmann

@laanwj Should this now be possible to work :)?

Wladimir J. van der Laan
Owner
Wladimir J. van der Laan
Owner
Philip Kaufmann enable full GCC Stack-smashing protection for all OSes
- change our hardening options to use -fstack-protector-all even for
  Windows builds, as we recently switched to a newer compiler suite
- also removes an obsolete workaround for GCC 4.5
  (https://bugs.launchpad.net/ubuntu/+source/gcc-4.5/+bug/691722), which
  required to first set -fno-stack-protector, before -fstack-protector-all
4e57e23
Wladimir J. van der Laan
Owner

When I build 32/64 bit executables using gitian, I still get the libssp error:

err:module:import_dll Library libssp-0.dll (which is needed by L"Z:\\home\\orion\\projects\\bitcoin\\gitian-builder\\build\\out\\32\\bitcoin-qt.exe") not found
err:module:LdrInitializeThunk Main exe initialization for L"Z:\\home\\orion\\projects\\bitcoin\\gitian-builder\\build\\out\\32\\bitcoin-qt.exe" failed, status c0000135

I've tried manually passing -lssp_nonshared, but this didn't solve it.

Making the entire build -static would be possible, will try that now, currently we only -static-libgcc -static-libstdc++ on windows.

Wladimir J. van der Laan
Owner

Correction:

Works with -static. Can you cherry-pick this commit into this branch, to see if the pull tester doesn't bark on it?
laanwj@8ac43c1

Wladimir J. van der Laan laanwj build: Add -static for mingw builds
This avoids a dependency on libssp-0.dll when built with
-fstack-protector-all.
6ac0b3b
P. Kaufmann

Cherry-picked your commit...

BitcoinPullTester

Automatic sanity-testing: PASSED, see http://jenkins.bluematt.me/pull-tester/6ac0b3be2d5c5277805c16b56ee5b2e59ba9e84c for binaries and test log.
This test script verifies pulls every time they are updated. It, however, dies sometimes and fails to test properly. If you are waiting on a test, please check timestamps to verify that the test.log is moving at http://jenkins.bluematt.me/pull-tester/current/
Contact BlueMatt on freenode if something looks broken.

Wladimir J. van der Laan laanwj merged commit 6ac0b3b into from
P. Kaufmann Diapolo deleted the branch
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Commits on Jan 22, 2014
  1. enable full GCC Stack-smashing protection for all OSes

    Philip Kaufmann authored
    - change our hardening options to use -fstack-protector-all even for
      Windows builds, as we recently switched to a newer compiler suite
    - also removes an obsolete workaround for GCC 4.5
      (https://bugs.launchpad.net/ubuntu/+source/gcc-4.5/+bug/691722), which
      required to first set -fno-stack-protector, before -fstack-protector-all
  2. Wladimir J. van der Laan

    build: Add -static for mingw builds

    laanwj authored Philip Kaufmann committed
    This avoids a dependency on libssp-0.dll when built with
    -fstack-protector-all.
This page is out of date. Refresh to see the latest.
Showing with 2 additions and 4 deletions.
  1. +2 −4 configure.ac
6 configure.ac
View
@@ -175,6 +175,7 @@ case $host in
AC_CHECK_LIB([iphlpapi], [main],, AC_MSG_ERROR(lib missing))
AC_CHECK_LIB([crypt32], [main],, AC_MSG_ERROR(lib missing))
+ AX_CHECK_LINK_FLAG([[-static]],[LDFLAGS="$LDFLAGS -static"])
AX_CHECK_LINK_FLAG([[-static-libgcc]],[LDFLAGS="$LDFLAGS -static-libgcc"])
AX_CHECK_LINK_FLAG([[-static-libstdc++]],[LDFLAGS="$LDFLAGS -static-libstdc++"])
@@ -284,6 +285,7 @@ AX_CHECK_LINK_FLAG([[-Wl,--large-address-aware]], [LDFLAGS="$LDFLAGS -Wl,--large
if test x$use_hardening != xno; then
AX_CHECK_COMPILE_FLAG([-Wstack-protector],[HARDENED_CXXFLAGS="$HARDENED_CXXFLAGS -Wstack-protector"])
+ AX_CHECK_COMPILE_FLAG([-fstack-protector-all],[HARDENED_CXXFLAGS="$HARDENED_CXXFLAGS -fstack-protector-all"])
AX_CHECK_COMPILE_FLAG([-fPIE],[HARDENED_CXXFLAGS="$HARDENED_CXXFLAGS -fPIE"])
AX_CHECK_PREPROC_FLAG([-D_FORTIFY_SOURCE=2],[
@@ -299,10 +301,6 @@ if test x$use_hardening != xno; then
AX_CHECK_LINK_FLAG([[-Wl,-z,now]], [LDFLAGS="-Wl,-z,now"])
if test x$TARGET_OS != xwindows; then
- # -fstack-protector-all can produce broken binaries with mingw
- AX_CHECK_COMPILE_FLAG([-fno-stack-protector],[HARDENED_CXXFLAGS="$HARDENED_CXXFLAGS -fno-stack-protector"])
- AX_CHECK_COMPILE_FLAG([-fstack-protector-all],[HARDENED_CXXFLAGS="$HARDENED_CXXFLAGS -fstack-protector-all"])
-
# -pie will link successfully with MinGW, but it's unsupported and leads to undeterministic binaries
AX_CHECK_LINK_FLAG([[-pie]], [HARDENED_LDFLAGS="$HARDENED_LDFLAGS -pie"])
fi
Something went wrong with that request. Please try again.