Commit Graph

257 Commits

Author SHA1 Message Date
Kittywhiskers Van Gogh
a7cb99b184 build: use glibc 2.28 for all Linux builds 2023-08-01 12:07:31 -05:00
Kittywhiskers Van Gogh
04d77f72e9 merge bitcoin#27029: consolidate to glibc 2.27 for Linux builds 2023-08-01 12:07:31 -05:00
Kittywhiskers Van Gogh
66e1541808 merge bitcoin#21851: support cross-compiling for arm64-apple-darwin 2023-06-29 12:31:03 -05:00
Kittywhiskers Van Gogh
1158ebb2e6 merge bitcoin#23778: Guix 1.4.0 & GCC 10.3 2023-06-18 11:47:54 -05:00
Kittywhiskers Van Gogh
3c8088f2e8 merge bitcoin#26075: remove 32bit linux code from release scripts 2023-06-07 14:42:02 +05:30
Kittywhiskers Van Gogh
e91a62be3c merge bitcoin#24561: use LIEF 0.12.0 2023-06-07 14:42:02 +05:30
Kittywhiskers Van Gogh
f2a5b472fd merge bitcoin#23148: Fix guix linker-loader path and add check_ELF_interpreter 2023-06-07 14:42:02 +05:30
Kittywhiskers Van Gogh
e39a1de731 merge bitcoin#23839: build with and test for control flow instrumentation on x86_64 2023-06-07 14:42:02 +05:30
Kittywhiskers Van Gogh
38c3bd0b61 merge bitcoin#23838: make security checks architecture independent 2023-06-07 14:42:02 +05:30
Kittywhiskers Van Gogh
bd2135fbd5 merge bitcoin#23811: match on EXE_FORMATS rather than name string 2023-06-07 14:42:02 +05:30
Kittywhiskers Van Gogh
1e9278ea11 merge bitcoin#23535: check for control flow instrumentation 2023-06-07 14:42:02 +05:30
Kittywhiskers Van Gogh
110dbf82e8 merge bitcoin#22392: use LIEF for ELF security & symbol checks 2023-06-07 14:42:02 +05:30
Kittywhiskers Van Gogh
cdedbea0b4 merge bitcoin#21889: check for control flow instrumentation 2023-06-07 14:42:02 +05:30
Kittywhiskers Van Gogh
853583019b fix: add exception for 32-bit ARM builds which need glibc 2.28
note: focal uses glibc 2.31, which is used by gitian, so our build
      environment has support for a version of glibc that far exceeds
      our maximum supported version (2.28). this could be remedied by
      switching to debian buster (oldstable) which uses 2.28.
2023-06-07 14:42:02 +05:30
Kittywhiskers Van Gogh
24a6642b6f partial bitcoin#22381: Test security-check sanity before performing them (with macOS)
excludes:
- d6ef3543ae16847d5a91fa9271acee9bd2164b32
2023-06-07 14:42:02 +05:30
Kittywhiskers Van Gogh
d4a8d49e56 merge bitcoin#21428: Cleanup in test-{security,symbol}-check.py 2023-06-07 14:42:02 +05:30
Kittywhiskers Van Gogh
1be3afd82c merge bitcoin#21255: run test-symbol-check for RISC-V 2023-06-07 14:42:02 +05:30
Kittywhiskers Van Gogh
ef65f610bb merge bitcoin#21871: add checks for minimum required OS versions 2023-06-07 14:42:02 +05:30
Kittywhiskers Van Gogh
067d4a4541 merge bitcoin#20608: add symbol check test for PE binaries 2023-06-07 14:42:02 +05:30
Kittywhiskers Van Gogh
ef9300ad63 merge bitcoin#21664: use LIEF for macOS and Windows symbol & security checks 2023-06-07 14:42:02 +05:30
Kittywhiskers Van Gogh
994fb5739c merge bitcoin#18434: add a test-security target and run it in CI 2023-06-07 14:40:37 +05:30
Kittywhiskers Van Gogh
772ec4c536 merge bitcoin#22305: Avoid fcntl64@GLIBC_2.28 in libsqlite3.a 2023-05-31 11:06:40 -05:00
Kittywhiskers Van Gogh
8eab21bd33 contrib: add symbols and libraries used by dash 2023-05-31 11:06:40 -05:00
Konstantin Akimov
b8b37f314b Merge #17891: scripted-diff: Replace CCriticalSection with RecursiveMutex
e09c701e0110350f78366fb837308c086b6503c0 scripted-diff: Bump copyright of files changed in 2020 (MarcoFalke)
6cbe6209646db8914b87bf6edbc18c6031a16f1e scripted-diff: Replace CCriticalSection with RecursiveMutex (MarcoFalke)

Pull request description:

  `RecursiveMutex` better clarifies that the mutex is recursive, see also the standard library naming: https://en.cppreference.com/w/cpp/thread/recursive_mutex

  For that reason, and to avoid different people asking me the same question repeatedly (e.g. https://github.com/bitcoin/bitcoin/pull/15932#pullrequestreview-339175124 ), remove the outdated alias `CCriticalSection` with a scripted-diff
2023-05-24 12:43:57 -05:00
W. J. van der Laan
8ca3005a91 Merge bitcoin/bitcoin#22645: scripts: prevent GCC optimising test symbols in test-symbol-check
5449d44e37982fcd5251fd47873c5f7d34c39fc9 scripts: prevent GCC optimising test symbols in test-symbol-check (fanquake)

Pull request description:

  I noticed in #22381 that when the test-symbol-check target was being built with Clang and run in the CI it would fail due to using a too-new version of `pow` (used [here](d67330d112/contrib/devtools/test-symbol-check.py (L85))). Our CIs use Focal (glibc 2.31) and the version of `pow` was the optimized version introduced in [glibc 2.29](https://lwn.net/Articles/778286/):
  ```bash
  * Optimized generic exp, exp2, log, log2, pow, sinf, cosf, sincosf and tanf.
  ```
  This made sense, except for that if it was failing when built using Clang, why hadn't it also been failing when being built with GCC?

  Turns out GCC is optimizing away that call to `pow` at all optimization levels, including `-O0`, see: https://godbolt.org/z/53MhzMxT7, and this has been the case forever, or at least since GCC 5.x. Clang on the other hand, will only optimize away the `pow` call at `-O1` and `-O2`, not `-O0`: https://godbolt.org/z/Wbnqj3q6c. Thus when this test was built with Clang (we don't pass `-O` so we default to `-O0`) it was failing in the CI environment, because it would actually have a call to the "new" `pow`.

  Avoid this issue by using a symbol that won't be optimized away, or that we are unlikely to ever have versioning issues with.

ACKs for top commit:
  laanwj:
    ACK 5449d44e37982fcd5251fd47873c5f7d34c39fc9

Tree-SHA512: 3a26c5c3a5f2905fd0dd90892470e241ba625c0af3be2629d06d5da3a97534c1d6a55b796bbdd41e2e6a26a8fab7d981b98c45d4238565b0eb7edf3c5da02007
2023-04-16 23:40:59 +03:00
Wladimir J. van der Laan
b4285d03da Merge #18395: scripts: add PE dylib checking to symbol-check.py
1a0993ae354c36d6f219e67f82ca8236530d6201 scripts: add PE dylib checking to symbol-check.py (fanquake)

Pull request description:

  Uses `objdump -x` and looks for `DLL Name:` lines. i.e:
  ```bash
  objdump -x src/qt/bitcoin-qt.exe | grep "DLL Name:"
  	DLL Name: ADVAPI32.dll
  	DLL Name: dwmapi.dll
  	DLL Name: GDI32.dll
  	DLL Name: IMM32.dll
  	DLL Name: IPHLPAPI.DLL
  	DLL Name: KERNEL32.dll
  	DLL Name: msvcrt.dll
  	DLL Name: ole32.dll
  	DLL Name: OLEAUT32.dll
  	DLL Name: SHELL32.dll
  	DLL Name: SHLWAPI.dll
  	DLL Name: USER32.dll
  	DLL Name: UxTheme.dll
  	DLL Name: VERSION.dll
  	DLL Name: WINMM.dll
  	DLL Name: WS2_32.dll
  ```

ACKs for top commit:
  dongcarl:
    Concept ACK 1a0993ae354c36d6f219e67f82ca8236530d6201
  hebasto:
    ACK 1a0993ae354c36d6f219e67f82ca8236530d6201, tested on Linux Mint 19.3:

Tree-SHA512: 0099a50e2c616d5239a15cafa9a7c483e9c40244af41549e4738be0f5360f27a2afb956eb50b47cf446b242f4cfc6dc9d111306a056fb83789eefbd71eddabd2
2023-03-26 16:50:26 -05:00
fanquake
088342b617 partial Merge bitcoin/bitcoin#22405: build: remove --enable-glibc-back-compat from Guix build
797b3ed9090030f32fade81803b580562d4a90a3 script: remove gitian reference from symbol-check.py (fanquake)
15fc9a0299091bfeb3370f993ad95ff638f6ba8c guix: add additional documentation to patches (fanquake)
4516e5ec9223486fe2eba7f4320d786d074a58fd lint: exclude Guix patches from spell-checking (fanquake)
de6ca41a52d2646598daae5f4620bbe766757e21 guix: no-longer pass --enable-glibc-back-compat to Guix (fanquake)
84dd81fb5bf7308b8070b53520266854fb6efad3 build: remove glibc backcompat requirement for Linux symbol checks (fanquake)

Pull request description:

  Now that our Guix toolchains are based on glibc 2.24 and 2.27 (RISCV), we don't need to use the `--enable-glibc-back-compat` option to produce binaries that don't use any symbols from glibc 2.17 and 2.27 or later.

  This also adds additional documentation to some Guix patches (pointed out in #22365) and removes Guix patches from the spelling linter, because that isn't our spelling.

  Symbol usage: https://gist.github.com/fanquake/d15604fc580718444c5aa4b3c3c75fdc.

  Guix Builds:
  ```bash
  bash-5.1# find guix-build-$(git rev-parse --short=12 HEAD)/output/ -type f -print0 | env LC_ALL=C sort -z | xargs -r0 sha256sum
  ed54e6a6cf4fab328557c0c72eb08c73f2a58c6c70959544cf4b1882e75ea69e  guix-build-797b3ed90900/output/aarch64-linux-gnu/SHA256SUMS.part
  83bd9dadc59f89f848d143fa4fc3964f16fe0b4bdf35e5093b577ff2c4bd1f43  guix-build-797b3ed90900/output/aarch64-linux-gnu/bitcoin-797b3ed90900-aarch64-linux-gnu-debug.tar.gz
  94cb8c35281f12dec6ea5b390b66cad5e27ac8c45a30c42c8d38c438695d54c0  guix-build-797b3ed90900/output/aarch64-linux-gnu/bitcoin-797b3ed90900-aarch64-linux-gnu.tar.gz
  7318b63d65c0aa52d2446de8e1f40658d2e47ab8fb0268820c3b7585d140fb23  guix-build-797b3ed90900/output/arm-linux-gnueabihf/SHA256SUMS.part
  95e1ffb372964b73f539653ca703b70cf0c018801a9c4c0ffc46a0b63539253c  guix-build-797b3ed90900/output/arm-linux-gnueabihf/bitcoin-797b3ed90900-arm-linux-gnueabihf-debug.tar.gz
  039d3842e6499626cf955ae0a7590dd6b3d0935cdc217c98aaf9d156b0ebd3b4  guix-build-797b3ed90900/output/arm-linux-gnueabihf/bitcoin-797b3ed90900-arm-linux-gnueabihf.tar.gz
  e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855  guix-build-797b3ed90900/output/dist-archive/SKIPATTEST.TAG
  2c4e7b6e7aff63ba811e5bf59362d16866c3a358f8844fba8739a61192870622  guix-build-797b3ed90900/output/dist-archive/bitcoin-797b3ed90900.tar.gz
  955029b949c368eabd517dd33040d2f01e2ac6a55e7b4f9107907a7c6e0c6060  guix-build-797b3ed90900/output/powerpc64-linux-gnu/SHA256SUMS.part
  fd6d6b137f8efedf58a879d11205b1d4649e1f97d7f91e193239ef206fcc285d  guix-build-797b3ed90900/output/powerpc64-linux-gnu/bitcoin-797b3ed90900-powerpc64-linux-gnu-debug.tar.gz
  51736ac8e77737999f1b5bd4c381b0016f19a8d5e40e786fe941ff04e84c11c9  guix-build-797b3ed90900/output/powerpc64-linux-gnu/bitcoin-797b3ed90900-powerpc64-linux-gnu.tar.gz
  8c244c16bfa46c1efdb120e1d91fdd14d3f14eefee8d7e1fbb0a9b4664a5c315  guix-build-797b3ed90900/output/powerpc64le-linux-gnu/SHA256SUMS.part
  704ee593251a1b1c65a5bebeef93b23f266af4e8cbf8ae556150c3b2e8f06a6c  guix-build-797b3ed90900/output/powerpc64le-linux-gnu/bitcoin-797b3ed90900-powerpc64le-linux-gnu-debug.tar.gz
  0ec06ae7d344de20d61e3965d8b383747ef20b0e9d93a3165733ea23bdf2ead8  guix-build-797b3ed90900/output/powerpc64le-linux-gnu/bitcoin-797b3ed90900-powerpc64le-linux-gnu.tar.gz
  2dd6c6ecc67b0ea40ca9c43f92efca81ccd054b8db8c197ad84ad9674d510a25  guix-build-797b3ed90900/output/riscv64-linux-gnu/SHA256SUMS.part
  5ebb27a855a677f7a188d83995be6b2a3ea8606be152abb7fc7832713fb0677a  guix-build-797b3ed90900/output/riscv64-linux-gnu/bitcoin-797b3ed90900-riscv64-linux-gnu-debug.tar.gz
  bdaf1783f5e1861597afa37c1880364e118d9a7a7af8017302d82202791019f6  guix-build-797b3ed90900/output/riscv64-linux-gnu/bitcoin-797b3ed90900-riscv64-linux-gnu.tar.gz
  726c9092b60ac2e7d7e14b2c24467fcf276a6f89170a871ddab9dce6ac230699  guix-build-797b3ed90900/output/x86_64-apple-darwin18/SHA256SUMS.part
  2af4d709b44952654f3c08c86593bf2ccc9a44ed422783a1b95b8a199a894db2  guix-build-797b3ed90900/output/x86_64-apple-darwin18/bitcoin-797b3ed90900-osx-unsigned.dmg
  fd49ba445aa6cf3d8c47019a05e9e5740cb0f53349344dd80671297127f49f1a  guix-build-797b3ed90900/output/x86_64-apple-darwin18/bitcoin-797b3ed90900-osx-unsigned.tar.gz
  3f51cbf8cf18420d4be70e656aa993675cf5e828a255c2030047ae2e059ed5b7  guix-build-797b3ed90900/output/x86_64-apple-darwin18/bitcoin-797b3ed90900-osx64.tar.gz
  afd1edee1447bb88d81e972abfae4c4e065b5b1827769f033cff9472084c7c1b  guix-build-797b3ed90900/output/x86_64-linux-gnu/SHA256SUMS.part
  ec468ef886d25e685f4f7a18b4f7d497dedf757495e0d5beb72c23cc32ab69b5  guix-build-797b3ed90900/output/x86_64-linux-gnu/bitcoin-797b3ed90900-x86_64-linux-gnu-debug.tar.gz
  1934d7294f0c9e083d38a3f68d4a61cd679defa79ce0a89f77386978692b9b18  guix-build-797b3ed90900/output/x86_64-linux-gnu/bitcoin-797b3ed90900-x86_64-linux-gnu.tar.gz
  94c11c328a628052eb6f50e9816aa768f87ea7acfbbbafdab60f6928da766811  guix-build-797b3ed90900/output/x86_64-w64-mingw32/SHA256SUMS.part
  fd371922ba93d81bd4a2b711d617af6756f9f0494db6d83aa0e5f491a24168ef  guix-build-797b3ed90900/output/x86_64-w64-mingw32/bitcoin-797b3ed90900-win-unsigned.tar.gz
  4e4ad976bc029bbbf9596ad8493accaaba8b0d5c598dd342f8da330609bbdf21  guix-build-797b3ed90900/output/x86_64-w64-mingw32/bitcoin-797b3ed90900-win64-debug.zip
  3a89a16b9101e9a17d98efb9234b5bdd264c0bba2c6326511017730e1a08311f  guix-build-797b3ed90900/output/x86_64-w64-mingw32/bitcoin-797b3ed90900-win64-setup-unsigned.exe
  e285ab737e3c843fd3f1c26c2f053e421a3c39b33995747ce48281884d3f28d1  guix-build-797b3ed90900/output/x86_64-w64-mingw32/bitcoin-797b3ed90900-win64.zip
  ```

ACKs for top commit:
  sipa:
    utACK 797b3ed9090030f32fade81803b580562d4a90a3
  hebasto:
    ACK 797b3ed9090030f32fade81803b580562d4a90a3

Tree-SHA512: 3a569702d8832c155c5ce8d2f6d823f7f12603885576078bc5192bc9038a48261ecb541800f79d1e9bc86d71fa640265c5b8b89df9d8bb680b3bb05d9d78a666
2023-03-26 16:50:26 -05:00
Kittywhiskers Van Gogh
07bd5977e5 partial bitcoin#23511: require glibc 2.18+ 2023-01-18 19:02:39 -06:00
Kittywhiskers Van Gogh
d37f30ce46 merge bitcoin#20476: Add test for ELF symbol-check 2023-01-18 19:02:39 -06:00
Kittywhiskers Van Gogh
f62fd6f51f merge bitcoin#22244: Correctly extract symbol versions in symbol-check 2023-01-18 19:02:39 -06:00
Kittywhiskers Van Gogh
29c885c9f7 merge bitcoin#20434: Parse ELF directly for symbol and security checks 2023-01-18 19:02:39 -06:00
Kittywhiskers Van Gogh
ef69317b59 merge bitcoin#19525: add -Wl,-z,separate-code to hardening flags 2023-01-18 19:02:39 -06:00
UdjinM6
498e8c5017 chore: run copyright_header.py update 2023-01-13 00:49:04 +03:00
UdjinM6
a86b891d20 chore: update copyright_header.py 2023-01-13 00:49:04 +03:00
Kittywhiskers Van Gogh
816edc4e4f build: add exclusions to linting scripts and filters 2022-12-01 00:51:08 +05:30
Kittywhiskers Van Gogh
305abe91f9
build/depends: commit dashpay/bls-signatures@66ee820f to source tree as vendored (#5077)
* Squashed 'src/dashbls/' content from commit 66ee820fbc

git-subtree-dir: src/dashbls
git-subtree-split: 66ee820fbc9e3b97370db8c164904af48327a124

* build: stop tracking build-system generated relic_conf.h.in

* build: add support for building bls-signatures from local subtree

* build: add exclusions to linting scripts and filters

* build: drop bls-signatures (bls-dash) from depends
2022-11-22 11:34:46 -06:00
UdjinM6
815cd1d906 more of 17863/21376 2022-10-03 16:08:31 -04:00
Wladimir J. van der Laan
7fb31bc434 Merge #17863: scripts: Add MACHO dylib checks to symbol-check.py
c491368d8cfddf3a5b6d574f10ed67492fcecbed scripts: add MACHO dylib checking to symbol-check.py (fanquake)
76bf97213f4b153dd3ccf1314088a73c4804601d scripts: fix check-symbols & check-security argument passing (fanquake)

Pull request description:

  Based on #17857.

  This adds dynamic library checks for MACHO executables to symbol-check.py. The script has been modified to function more like `security-check.py`. The error output is now also slightly different. i.e:
  ```bash
  # Linux x86
  bitcoin-cli: symbol operator new[](unsigned long) from unsupported version GLIBCXX_3.4
  bitcoin-cli: export of symbol vtable for std::basic_ios<char, std::char_traits<char> > not allowed
  bitcoin-cli: NEEDED library libstdc++.so.6 is not allowed
  bitcoin-cli: failed IMPORTED_SYMBOLS EXPORTED_SYMBOLS LIBRARY_DEPENDENCIES

  # RISCV (skips exported symbols checks)
  bitcoin-tx: symbol operator new[](unsigned long) from unsupported version GLIBCXX_3.4
  bitcoin-tx: NEEDED library libstdc++.so.6 is not allowed
  bitcoin-tx: failed IMPORTED_SYMBOLS LIBRARY_DEPENDENCIES

  # macOS
  Checking macOS dynamic libraries...
  libboost_filesystem.dylib is not in ALLOWED_LIBRARIES!
  bitcoind: failed DYNAMIC_LIBRARIES
  ```

  Compared to `v0.19.0.1` the macOS allowed dylibs has been slimmed down somewhat:
  ```diff
   src/qt/bitcoin-qt:
   /usr/lib/libSystem.B.dylib
  -/System/Library/Frameworks/DiskArbitration.framework/Versions/A/DiskArbitration
   /System/Library/Frameworks/IOKit.framework/Versions/A/IOKit
   /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation
   /System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices
   /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit
   /System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices
   /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation
  -/System/Library/Frameworks/Security.framework/Versions/A/Security
  -/System/Library/Frameworks/SystemConfiguration.framework/Versions/A/SystemConfiguration
   /System/Library/Frameworks/CoreGraphics.framework/Versions/A/CoreGraphics
  -/System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL
  -/System/Library/Frameworks/AGL.framework/Versions/A/AGL
   /System/Library/Frameworks/Carbon.framework/Versions/A/Carbon
   /usr/lib/libc++.1.dylib
  -/System/Library/Frameworks/CFNetwork.framework/Versions/A/CFNetwork
   /System/Library/Frameworks/CoreText.framework/Versions/A/CoreText
   /System/Library/Frameworks/ImageIO.framework/Versions/A/ImageIO
   /usr/lib/libobjc.A.dylib
  ```

ACKs for top commit:
  laanwj:
    ACK c491368d8cfddf3a5b6d574f10ed67492fcecbed

Tree-SHA512: f8624e4964e80b3e0d34e8d3cc33f3107938f3ef7a01c07828f09b902b5ea31a53c50f9be03576e1896ed832cf2c399e03a7943a4f537a1e1c705f3804aed979
2022-10-03 16:08:31 -04:00
MarcoFalke
2353920662
Merge #16878: Fix non-deterministic coverage of test DoS_mapOrphans
4455949d6f0218b40d33d7fe6de6555f8f62192f Make test DoS_mapOrphans deterministic (David Reikher)

Pull request description:

  This pull request proposes a solution to make the test `DoS_mapOrphans` in denialofservice_tests.cpp have deterministic coverage.

  The `RandomOrphan` function in denialofservice_tests.cpp and the implicitly called function `ecdsa_signature_parse_der_lax` in pubkey.cpp were causing the non-deterministic test coverage.

  In the former, if a random orphan was selected the index of which is bigger than the max. orphan index in `mapOrphanTransactions`, the last orphan was returned from `RandomOrphan`. If the random number generated was never large enough, this condition would not be fulfilled and the corresponding branch wouldn't run. The proposed solution is to force one of the 50 dependant orphans to depend on the last orphan in `mapOrphanTransactions` using the newly introduced function `OrphanByIndex` (and passing it a large uint256), forcing this branch to run at least once.

  In the latter, if values for ECDSA `R` or `S` (or both) had no leading zeros, some code would not be executed. The solution was to find a constant signature that would be comprised of `R` and `S` values with leading zeros and calling `CPubKey::Verify` at the end of the test with this signature forcing this code to always run at least once at the end even if it hadn't throughout the test.

  To test that the coverage is (at least highly likely) deterministic, I ran

  `contrib/devtools/test_deterministic_coverage.sh denialofservice_tests/DoS_mapOrphans 1000`

  and the result was deterministic coverage across 1000 runs.

  Also - removed denialofservice_tests test entry from the list of non-deterministic tests in the coverage script.

ACKs for top commit:
  MarcoFalke:
    ACK 4455949d6f0218b40d33d7fe6de6555f8f62192f

Tree-SHA512: 987eb1f94b80d5bec4d4944e91ef43b9b8603055750362d4b4665b7f011be27045808aa9f4c6ccf8ae009b61405f9a1b8671d65a843c3328e5b8acce1f1c00a6
2022-09-03 10:43:14 -05:00
Wladimir J. van der Laan
33c473a8e3
Merge #18796: scripts: security-check.py refactors
eacedfb0230978748cbcfb13817fed7e7c756ba7 scripts: add additional type annotations to security-check.py (fanquake)
83d063e9541cc9ea41ea86919eb9435c73efb14e scripts: add run_command to security-check.py (fanquake)
13f606b4f940e5820ff21ea62fc27a5a91774b05 scripts: remove NONFATAL from security-check.py (fanquake)
061acf62a15ad3dbb9f055b7c2569b9832ed623a scripts: no-longer check for 32 bit windows in security-check.py (fanquake)

Pull request description:

  * Remove 32-bit Windows checks.
  * Remove NONFATAL checking. Added in #8249, however unused since #13764.
  * Add `run_command` to de-duplicate all of the subprocess calls. Mentioned in #18713.
  * Add additional type annotations.
  * Print stderr when there is an issue running a command.

ACKs for top commit:
  laanwj:
    ACK eacedfb0230978748cbcfb13817fed7e7c756ba7

Tree-SHA512: 69a7ccfdf346ee202b3e8f940634c5daed1d2b5a5d15ac9800252866ba3284ec66e391a66a0b341f5a4e5e8482fe1b614d4671e8e766112ff059405081184a85
2022-06-18 22:14:03 -07:00
fanquake
f7a94b58d4
Merge #18629: scripts: add PE .reloc section check to security-check.py
3e38023af724a76972d39cbccfb0bba4c54a0323 scripts: add PE .reloc section check to security-check.py (fanquake)

Pull request description:

  The `ld` in binutils has historically had a few issues with PE binaries, there's a good summary in this [thread](https://sourceware.org/bugzilla/show_bug.cgi?id=19011).

  One issue in particular was `ld` stripping the `.reloc` section out of PE binaries, even though it's required for functioning ASLR. This was [reported by a Tor developer in 2014](https://sourceware.org/bugzilla/show_bug.cgi?id=17321) and they have been patching their [own binutils](https://gitweb.torproject.org/builders/tor-browser-build.git/tree/projects/binutils) ever since. However their patch only made it into binutils at the [start of this year](https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=dc9bd8c92af67947db44b3cb428c050259b15cd0). It adds an `--enable-reloc-section` flag, which is turned on by default if you are using `--dynamic-base`. In the mean time this issue has also been worked around by other projects, such as FFmpeg, see [this commit](91b668acd6).

  I have checked our recent supported Windows release binaries, and they do contain a `.reloc` section. From what I understand, we are using all the right compile/linker flags, including `-pie` & `-fPIE`, and have never run into the crashing/entrypoint issues that other projects might have seen.

  One other thing worth noting here, it how Debian/Ubuntu patch the binutils that they distribute, because that's what we end up using in our gitian builds.

  In the binutils-mingw-w64 in Bionic (18.04), which we currently use in gitian, PE hardening options/security flags are enabled by default. See the [changelog](https://changelogs.ubuntu.com/changelogs/pool/universe/b/binutils-mingw-w64/binutils-mingw-w64_8ubuntu1/changelog) and the [relevant commit](452b3013b8).

  However in Focal (20.04), this has now been reversed. PE hardening options are no-longer the default. See the [changelog](https://changelogs.ubuntu.com/changelogs/pool/universe/b/binutils-mingw-w64/binutils-mingw-w64_8.8/changelog) and [relevant commit](7bd8b2fbc2), which cites same .reloc issue mentioned here.

  Given that we explicitly specify/opt-in to everything that we want to use, the defaults aren't necessarily an issue for us. However I think it highlights the importance of continuing to be explicit about what we want, and not falling-back or relying on upstream.

  This was also prompted by the possibility of us doing link time garbage collection, see #18579 & #18605. It seemed some sanity checks would be worthwhile in-case the linker goes haywire while garbage collecting.

  I think Guix is going to bring great benefits when dealing with these kinds of issues. Carl you might have something to say in that regard.

ACKs for top commit:
  dongcarl:
    ACK 3e38023af724a76972d39cbccfb0bba4c54a0323

Tree-SHA512: af14d63bdb334bde548dd7de3e0946556b7e2598d817b56eb4e75b3f56c705c26aa85dd9783134c4b6a7aeb7cb4de567eed996e94d533d31511f57ed332287da
2022-06-18 22:14:03 -07:00
fanquake
bd7b5a3ad4
Merge #18713: scripts: Add MACHO stack canary check to security-check.py
8334ee31f868f0f9baf0920d14d20174ed889dbe scripts: add MACHO LAZY_BINDINGS test to test-security-check.py (fanquake)
7b99c7454cdb74cd9cd7a5eedc2fb9d0a19df456 scripts: add MACHO Canary check to security-check.py (fanquake)

Pull request description:

  7b99c7454cdb74cd9cd7a5eedc2fb9d0a19df456 uses `otool -Iv` to check for `___stack_chk_fail` in the macOS binaries. Similar to the [ELF check](https://github.com/bitcoin/bitcoin/blob/master/contrib/devtools/security-check.py#L105). Note that looking for a triple underscore prefixed function (as opposed to two for ELF) is correct for the macOS binaries. i.e:
  ```bash
  otool -Iv bitcoind | grep chk
  0x00000001006715b8   509 ___memcpy_chk
  0x00000001006715be   510 ___snprintf_chk
  0x00000001006715c4   511 ___sprintf_chk
  0x00000001006715ca   512 ___stack_chk_fail
  0x00000001006715d6   517 ___vsnprintf_chk
  0x0000000100787898   513 ___stack_chk_guard
  ```

  8334ee31f868f0f9baf0920d14d20174ed889dbe is a follow up to #18295 and adds test cases to `test-security-check.py` that for some reason I didn't add at the time. I'll sort out #18434 so that we can run these tests in the CI.

ACKs for top commit:
  practicalswift:
    ACK 8334ee31f868f0f9baf0920d14d20174ed889dbe: Mitigations are important. Important things are worth asserting :)
  jonasschnelli:
    utACK 8334ee31f868f0f9baf0920d14d20174ed889dbe.

Tree-SHA512: 1aa5ded34bbd187eddb112b27278deb328bfc21ac82316b20fab6ad894f223b239a76b53dab0ac1770d194c1760fcc40d4da91ec09959ba4fc8eadedb173936a
2022-06-18 22:14:03 -07:00
fanquake
67ceda1b5a
Merge #18295: scripts: add MACHO lazy bindings check to security-check.py
5ca90f8b598978437340bb8467f527b9edfb2bbf scripts: add MACHO lazy bindings check to security-check.py (fanquake)

Pull request description:

  This is a slightly belated follow up to #17686 and some discussion with Cory. It's not entirely clear if we should make this change due to the way the macOS dynamic loader appears to work. However I'm opening this for some discussion. Also related to #17768.

  #### Issue:
  [`LD64`](https://opensource.apple.com/source/ld64/) doesn't set the [MH_BINDATLOAD](https://opensource.apple.com/source/xnu/xnu-6153.11.26/EXTERNAL_HEADERS/mach-o/loader.h.auto.html) bit in the header of MACHO executables, when building with `-bind_at_load`. This is in contradiction to the [documentation](https://opensource.apple.com/source/ld64/ld64-450.3/doc/man/man1/ld.1.auto.html):
  ```bash
  -bind_at_load
       Sets a bit in the mach header of the resulting binary which tells dyld to
       bind all symbols when the binary is loaded, rather than lazily.
  ```

  The [`ld` in Apples cctools](https://opensource.apple.com/source/cctools/cctools-927.0.2/ld/layout.c.auto.html) does set the bit, however the [cctools-port](https://github.com/tpoechtrager/cctools-port/) that we use for release builds, bundles `LD64`.

  However; even if the linker hasn't set that bit, the dynamic loader ([`dyld`](https://opensource.apple.com/source/dyld/)) doesn't seem to ever check for it, and from what I understand, it looks at a different part of the header when determining whether to lazily load symbols.

  Note that our release binaries are currently working as expected, and no lazy loading occurs.

  #### Example:

  Using a small program, we can observe the behaviour of the dynamic loader.

  Conducted using:
  ```bash
  clang++ --version
  Apple clang version 11.0.0 (clang-1100.0.33.17)
  Target: x86_64-apple-darwin18.7.0

  ld -v
  @(#)PROGRAM:ld  PROJECT:ld64-530
  BUILD 18:57:17 Dec 13 2019
  LTO support using: LLVM version 11.0.0, (clang-1100.0.33.17) (static support for 23, runtime is 23)
  TAPI support using: Apple TAPI version 11.0.0 (tapi-1100.0.11)
  ```

  ```cpp
  #include <iostream>
  int main() {
  	std::cout << "Hello World!\n";
  	return 0;
  }
  ```

  Compile and check the MACHO header:
  ```bash
  clang++ test.cpp -o test
  otool -vh test
  ...
  Mach header
        magic cputype cpusubtype  caps    filetype ncmds sizeofcmds      flags
  MH_MAGIC_64  X86_64        ALL LIB64     EXECUTE    16       1424   NOUNDEFS DYLDLINK TWOLEVEL WEAK_DEFINES BINDS_TO_WEAK PIE

  # Run and dump dynamic loader bindings:
  DYLD_PRINT_BINDINGS=1 DYLD_PRINT_TO_FILE=no_bind.txt ./test
  Hello World!
  ```

  Recompile with `-bind_at_load`. Note still no `BINDATLOAD` flag:
  ```bash
  clang++ test.cpp -o test -Wl,-bind_at_load
  otool -vh test
  Mach header
        magic cputype cpusubtype  caps    filetype ncmds sizeofcmds      flags
  MH_MAGIC_64  X86_64        ALL LIB64     EXECUTE    16       1424   NOUNDEFS DYLDLINK TWOLEVEL WEAK_DEFINES BINDS_TO_WEAK PIE
  ...
  DYLD_PRINT_BINDINGS=1 DYLD_PRINT_TO_FILE=bind.txt ./test
  Hello World!
  ```

  If we diff the outputs, you can see that `dyld` doesn't perform any lazy bindings when the binary is compiled with `-bind_at_load`, even if the `BINDATLOAD` flag is not set:
  ```diff
  @@ -1,11 +1,27 @@
  +dyld: bind: test:0x103EDF030 = libc++.1.dylib:__ZNKSt3__16locale9use_facetERNS0_2idE, *0x103EDF030 = 0x7FFF70C9FA58
  +dyld: bind: test:0x103EDF038 = libc++.1.dylib:__ZNKSt3__18ios_base6getlocEv, *0x103EDF038 = 0x7FFF70CA12C2
  +dyld: bind: test:0x103EDF068 = libc++.1.dylib:__ZNSt3__113basic_ostreamIcNS_11char_traitsIcEEE6sentryC1ERS3_, *0x103EDF068 = 0x7FFF70CA12B6
  +dyld: bind: test:0x103EDF070 = libc++.1.dylib:__ZNSt3__113basic_ostreamIcNS_11char_traitsIcEEE6sentryD1Ev, *0x103EDF070 = 0x7FFF70CA1528
  +dyld: bind: test:0x103EDF080 = libc++.1.dylib:__ZNSt3__16localeD1Ev, *0x103EDF080 = 0x7FFF70C9FAE6
  <trim>
  -dyld: lazy bind: test:0x10D4AC0C8 = libsystem_platform.dylib:_strlen, *0x10D4AC0C8 = 0x7FFF73C5C6E0
  -dyld: lazy bind: test:0x10D4AC068 = libc++.1.dylib:__ZNSt3__113basic_ostreamIcNS_11char_traitsIcEEE6sentryC1ERS3_, *0x10D4AC068 = 0x7FFF70CA12B6
  -dyld: lazy bind: test:0x10D4AC038 = libc++.1.dylib:__ZNKSt3__18ios_base6getlocEv, *0x10D4AC038 = 0x7FFF70CA12C2
  -dyld: lazy bind: test:0x10D4AC030 = libc++.1.dylib:__ZNKSt3__16locale9use_facetERNS0_2idE, *0x10D4AC030 = 0x7FFF70C9FA58
  -dyld: lazy bind: test:0x10D4AC080 = libc++.1.dylib:__ZNSt3__16localeD1Ev, *0x10D4AC080 = 0x7FFF70C9FAE6
  -dyld: lazy bind: test:0x10D4AC070 = libc++.1.dylib:__ZNSt3__113basic_ostreamIcNS_11char_traitsIcEEE6sentryD1Ev, *0x10D4AC070 = 0x7FFF70CA1528
  ```

  Note: `dyld` also has a `DYLD_BIND_AT_LAUNCH=1` environment variable, that when set, will force any lazy bindings to be non-lazy:
  ```bash
  dyld: forced lazy bind: test:0x10BEC8068 = libc++.1.dylib:__ZNSt3__113basic_ostream
  ```

  #### Thoughts:
  After looking at the dyld source, I can't find any checks for `MH_BINDATLOAD`. You can see the flags it does check for, such as MH_PIE or MH_BIND_TO_WEAK [here](https://opensource.apple.com/source/dyld/dyld-732.8/src/ImageLoaderMachO.cpp.auto.html).

  It seems that the lazy binding of any symbols depends on whether or not [lazy_bind_size](https://opensource.apple.com/source/xnu/xnu-6153.11.26/EXTERNAL_HEADERS/mach-o/loader.h.auto.html) from the `LC_DYLD_INFO_ONLY` load command is > 0. Which was mentioned in [#17686](https://github.com/bitcoin/bitcoin/pull/17686#issue-350216254).

  #### Changes:
  This PR is one of [Corys commits](7b6ba26178), that I've rebased and modified to make build. I've also included an addition to the `security-check.py` script to check for the flag.

  However, given the above, I'm not entirely sure this patch is the correct approach. If the linker no-longer inserts it, and the dynamic loader doesn't look for it, there might be little benefit to setting it. Or, maybe this is an oversight from Apple and needs some upstream discussion. Looking for some thoughts / Concept ACK/NACK.

  One alternate approach we could take is to drop the patch and modify security-check.py to look for `lazy_bind_size` == 0 in the `LC_DYLD_INFO_ONLY` load command, using `otool -l`.

ACKs for top commit:
  theuni:
    ACK 5ca90f8b598978437340bb8467f527b9edfb2bbf

Tree-SHA512: 444022ea9d19ed74dd06dc2ab3857a9c23fbc2f6475364e8552d761b712d684b3a7114d144f20de42328d1a99403b48667ba96885121392affb2e05b834b6e1c
2022-06-18 22:14:02 -07:00
Wladimir J. van der Laan
3c4982205c
Merge #18415: scripts: add MACHO tests to test-security-check.py
7142d50ac33e0ad7d24e49e04c1fc7e3e769ed46 scripts: rename test_64bit_PE to test_PE (fanquake)
edaca2dd123cef958699c07ab248cf0ffc71af07 scripts: add MACHO NX check to security-check.py (fanquake)
1a4e9f32efcc5f6a74290446dc58784fd85c7b31 scripts: add MACHO tests to test-security-check.py (fanquake)

Pull request description:

  Adds tests for the MACHO checks in security-check.py:
  ac579ada7e/contrib/devtools/security-check.py (L212-L214)

  I'm planning on following up with more checks in security-check.py, and corresponding tests in test-security-check.py.

  Note that you'll probably have to be on macOS to run them. You can run just this suite with `python3 test-security-check.py TestSecurityChecks.test_MACHO`.

ACKs for top commit:
  laanwj:
    ACK 7142d50ac33e0ad7d24e49e04c1fc7e3e769ed46

Tree-SHA512: ace3ca9f6df5d4fedd5988938fb7dc7563ec7dc587aa275f780b5f51e9b8d7d6f7768e0a1e05ce438510a07b8640aba92c76847b30c2990f46c66b78a0acf960
2022-06-18 22:14:02 -07:00
Wladimir J. van der Laan
a25ee06cc1 Merge #17787: scripts: add MACHO PIE check to security-check.py
7c9e821c4e6cb186208ead9c8df616d1f393a49a scripts: add MACHO NOUNDEFS check to security-check.py (fanquake)
4ca92dc6d3f3e487d63286d8871d1829b3d279ff scripts: add MACHO PIE check to security-check.py (fanquake)

Pull request description:

  This uses `otool -vh` to print the mach header and look for the `PIE` flag:
  ```bash
  otool -vh src/bitcoind
  Mach header
        magic cputype cpusubtype  caps    filetype ncmds sizeofcmds      flags
  MH_MAGIC_64  X86_64        ALL LIB64     EXECUTE    24       2544   NOUNDEFS DYLDLINK TWOLEVEL WEAK_DEFINES BINDS_TO_WEAK PIE
  ```

  From [`mach-o/loader.h`](https://opensource.apple.com/source/cctools/cctools-927.0.2/include/mach-o/loader.h.auto.html):
  ```c
  #define	MH_PIE 0x200000			/* When this bit is set, the OS will
  					   load the main executable at a
  					   random address.  Only used in
  					   MH_EXECUTE filetypes. */
  ```

ACKs for top commit:
  laanwj:
    code review ACK 7c9e821c4e6cb186208ead9c8df616d1f393a49a

Tree-SHA512: 5ba2f60440d0e31c70371a355c91ca4f723d80f7287d04e2098bf5b11892cc74216ff8f1454603c4db9675d4f7983614843b992b8dcfca0309aadf2aa7ab2e4b
2022-06-08 12:36:52 +07:00
PastaPastaPasta
d64b7229cd
chore: bump copyrights (#4873)
* chore: bump copyright in configure.ac

* chore: bump copyright via copyright_header.py

ran command `python3 contrib/devtools/copyright_header.py update .`
2022-06-08 02:36:46 +03:00
Kittywhiskers Van Gogh
3ba8431900 merge bitcoin#16899: UTXO snapshot creation (dumptxoutset)
Co-authored-by: UdjinM6 <UdjinM6@users.noreply.github.com>
2022-05-23 10:38:33 +05:30
PastaPastaPasta
b421cfacae
perf: enable more multi-threading and caching in linters (#4807)
* perf: enable more multi-threading and caching in linters

20s -> 6s

* ci: add multiprocess to ci dockerfile

* Update test/lint/lint-cppcheck-dash.sh

Co-authored-by: UdjinM6 <UdjinM6@users.noreply.github.com>

Co-authored-by: UdjinM6 <UdjinM6@users.noreply.github.com>
2022-04-27 21:14:40 +03:00
UdjinM6
c6e724bf21 partial bitcoin#22244: Add xkb version to symbol-check 2022-04-26 20:37:20 +05:30
Kittywhiskers Van Gogh
1763f727b5 merge bitcoin#21376: Qt 5.12.10 2022-04-26 00:54:10 +05:30