Enable (and check for) 64-bit ASLR on Windows #8249

1. 
   laanwj commented at 2:57 PM on June 23, 2016: member

   See #8248 for more information.

2. laanwj added the label Windows on Jun 23, 2016
3. 
   laanwj commented at 3:08 PM on June 23, 2016: member

   Ugh, looks like the mingw64 ld on Trusty doesn't support this:

   checking host system type... x86_64-w64-mingw32
   ...
   checking whether the linker accepts -Wl,--high-entropy-va... no
   

   user@trusty:~$ i686-w64-mingw32-ld --version
   GNU ld (GNU Binutils) 2.23.52.20130620
   Copyright 2013 Free Software Foundation, Inc.
   This program is free software; you may redistribute it under the terms of
   the GNU General Public License version 3 or (at your option) a later version.
   This program has absolutely no warranty.
   

   Minimum version would be binutils 2.25: https://sourceware.org/ml/binutils/2014-08/msg00167.html.

   We should look at upgrading the build image to 16.04 LTS after the 0.13 release, this will also resolve the heap initialize-to-zero issue we currently have to work around.

4. laanwj added this to the milestone 0.14 on Jun 23, 2016
5. 
   luke-jr commented at 7:44 AM on September 10, 2016: member

   Maybe have configure check if this is supported, so it can be built both ways?

6. 
   laanwj commented at 9:29 AM on September 14, 2016: member

   Maybe have configure check if this is supported, so it can be built both ways?

   That's what the check_link_flag already does. It's just the security check that fails after the build. If you don't run that, this pull works fine w/ older gccs.

7. 
   laanwj commented at 11:50 AM on September 21, 2016: member

   @theuni @luke-jr What if I change this to make the extra security check non-fatal, issue a warning for now? This is still useful to have in the future if we ever get to the end of #8653 and the xenial mess cleaned up. Otherwise I'm going to close it for now.

8. 
   theuni commented at 6:30 AM on September 22, 2016: member

   @laanwj ACK on making it non-fatal for now. Optimally with some kind of switch to elevate warnings to errors like -Werror. That way we could set it as a real error in gitian when it should be supported, even though we allow older toolchains to configure with warnings.

   I'm still head-down in toolchain stuff, maybe we can have this turned on for 0.14.

9. devtools: Check for high-entropy ASLR in 64-bit PE executables

   check_PE_PIE only checked for DYNAMIC_BASE, this is not enough
   for (secure) ASLR on 64-bit.

   9a75d29b6f
10. build: supply `-Wl,--high-entropy-va`

    This should enable high-entropy ASLR on 64-bit targets, for better
    mitigation of exploits.

    62c291596b
11. laanwj force-pushed on Sep 26, 2016
12. 
    laanwj commented at 11:02 AM on September 26, 2016: member

    I split off the high entropy check and added this to the security-checks for now:

    NONFATAL = {'HIGH_ENTROPY_VA'} # checks which are non-fatal for now but only generate a warning
    

    I didn't find it worth the trouble to add a command-line option. The script can just be updated once we switch build platforms. The security check script exists for our releases, nothing else.

13. laanwj merged this on Sep 26, 2016
14. laanwj closed this on Sep 26, 2016

    ---

15. laanwj referenced this in commit 4e1567acff on Sep 26, 2016
16. fanquake moved this from the "In progress" to the "Done" column in a project

---

17. codablock referenced this in commit e55ed5c1fb on Sep 19, 2017
18. str4d cross-referenced this on Dec 1, 2017 from issue Build system improvements by str4d
19. zkbot referenced this in commit 75604363cc on Dec 1, 2017
20. zkbot referenced this in commit 6aef4033a7 on Dec 1, 2017
21. str4d cross-referenced this on Dec 15, 2017 from issue Make the high-entropy-hardening check mandatory by str4d
22. zkbot referenced this in commit 83af270002 on Dec 15, 2017
23. codablock referenced this in commit 8edc2a78cb on Jan 11, 2018
24. kotodev referenced this in commit c8a979fc92 on Jan 25, 2018
25. renium9 referenced this in commit 23640da445 on Feb 6, 2018
26. andvgal referenced this in commit 07d8514956 on Jan 6, 2019
27. fanquake cross-referenced this on Apr 28, 2020 from issue scripts: security-check.py refactors by fanquake
28. laanwj referenced this in commit 2d7489be8f on May 14, 2020
29. bitcoin locked this on Sep 8, 2021

Contributors

laanwjluke-jrtheuni

Milestone
0.14.0