build: add -Wl,-z,separate-code to hardening flags #19525

TLDR: We are generally explicit about the hardening related flags we use, rather than letting the distro / toolchain decide via their defaults. This PR adds -z,separate-code which has been enabled by default for Linux targets since binutils 2.31. Ubuntu Bionic (currently used for gitian) ships with binutils 2.30, so this will enable the option for those builds.

This flag was added to binutils/ld in the 2.30 release, see commit c11c786f0b45617bb8807ab6a57220d5ff50e414:

The new "-z separate-code" option will generate separate code LOAD segment which must be in wholly disjoint pages from any other data.

It was made the default for Linux/x86 targets in the 2.31 release, see commit f6aec96dce1ddbd8961a3aa8a2925db2021719bb:

This patch adds --enable-separate-code to ld configure to turn on -z separate-code by default and enables it by default for Linux/x86. This avoids mixing code pages with data to improve cache performance as well as security.

To reduce x86-64 executable and shared object sizes, the maximum page size is reduced from 2MB to 4KB when -z separate-code is turned on by default. Note: -z max-page-size= can be used to set the maximum page size.

We compared SPEC CPU 2017 performance before and after this change on Skylake server. There are no any significant performance changes. Everything is mostly below +/-1%.

Support was also added to LLVMs lld: https://reviews.llvm.org/D64903, however there it remains off by default.

There were concerns about an increase in binary size, however in our case, the difference would seem negligible, given we are shipping a multi-megabyte binary, which then downloads 100's of GBs of data.

Also note that most recent versions of distros are shipping a new enough version of binutils that this is available and/or already on by default (assuming the distro has not turned it off, I haven't checked everywhere):

CentOS 8: 2.30 Debian Buster 2.31.1 Fedora 29: 2.31.1 FreeBSD: 2.33 GNU Guix: 2.33 / 2.34 Ubuntu 18.04: 2.30

Related threads / discussion: https://bugzilla.redhat.com/show_bug.cgi?id=1623218

The ELF header when building on Debian Buster (where it's already enabled by default in binutils):

Program Header:
    PHDR off    0x0000000000000040 vaddr 0x0000000000000040 paddr 0x0000000000000040 align 2**3
         filesz 0x00000000000002a0 memsz 0x00000000000002a0 flags r--
  INTERP off    0x00000000000002e0 vaddr 0x00000000000002e0 paddr 0x00000000000002e0 align 2**0
         filesz 0x000000000000001c memsz 0x000000000000001c flags r--
    LOAD off    0x0000000000000000 vaddr 0x0000000000000000 paddr 0x0000000000000000 align 2**12
         filesz 0x0000000000038f10 memsz 0x0000000000038f10 flags r--
    LOAD off    0x0000000000039000 vaddr 0x0000000000039000 paddr 0x0000000000039000 align 2**12
         filesz 0x00000000006b9389 memsz 0x00000000006b9389 flags r-x
    LOAD off    0x00000000006f3000 vaddr 0x00000000006f3000 paddr 0x00000000006f3000 align 2**12
         filesz 0x0000000000204847 memsz 0x0000000000204847 flags r--
    LOAD off    0x00000000008f7920 vaddr 0x00000000008f8920 paddr 0x00000000008f8920 align 2**12
         filesz 0x00000000000183e0 memsz 0x0000000000022fd0 flags rw-
 DYNAMIC off    0x000000000090adb0 vaddr 0x000000000090bdb0 paddr 0x000000000090bdb0 align 2**3
         filesz 0x0000000000000240 memsz 0x0000000000000240 flags rw-

vs when opting out using -Wl,-z,noseparate-code:

Program Header:
    PHDR off    0x0000000000000040 vaddr 0x0000000000000040 paddr 0x0000000000000040 align 2**3
         filesz 0x0000000000000230 memsz 0x0000000000000230 flags r--
  INTERP off    0x0000000000000270 vaddr 0x0000000000000270 paddr 0x0000000000000270 align 2**0
         filesz 0x000000000000001c memsz 0x000000000000001c flags r--
    LOAD off    0x0000000000000000 vaddr 0x0000000000000000 paddr 0x0000000000000000 align 2**12
         filesz 0x00000000008f6a87 memsz 0x00000000008f6a87 flags r-x
    LOAD off    0x00000000008f7920 vaddr 0x00000000008f8920 paddr 0x00000000008f8920 align 2**12
         filesz 0x00000000000183e0 memsz 0x0000000000022fd0 flags rw-
 DYNAMIC off    0x000000000090adb0 vaddr 0x000000000090bdb0 paddr 0x000000000090bdb0 align 2**3
         filesz 0x0000000000000240 memsz 0x0000000000000240 flags rw-

Sounds good to me. I'm surprised that this wasn't already the case. Read-only code and data was already kept apart from writable data. I guess mixing read-only code and read-only data has a smaller security impact. But this is better. ACK d9315eae407e3180580befda17c0005347d82900

ACK d9315eae407e3180580befda17c0005347d82900 -- explicit is better than implicit, and hardened is better than non-hardened. @fanquake Would it make sense to test for this in contrib/devtools/security-check.py?

@fanquake Would it make sense to test for this in contrib/devtools/security-check.py?

I think this is a good idea, but how would you go about this? It is not entirely trivial. I think you'd have to correlate sections with LOAD headers and check that data sections are in a separate LOAD command than text ones? Or maybe it's easier.

Without the option there is no LOAD with r-- flags:

    LOAD off    0x0000000000000000 vaddr 0x0000000000000000 paddr 0x0000000000000000 align 2**12
         filesz 0x00000000008f6a87 memsz 0x00000000008f6a87 flags r-x
    LOAD off    0x00000000008f7920 vaddr 0x00000000008f8920 paddr 0x00000000008f8920 align 2**12
         filesz 0x00000000000183e0 memsz 0x0000000000022fd0 flags rw-

But with the option, there are:

    LOAD off    0x0000000000000000 vaddr 0x0000000000000000 paddr 0x0000000000000000 align 2**12
         filesz 0x0000000000038f10 memsz 0x0000000000038f10 flags r--
    LOAD off    0x0000000000039000 vaddr 0x0000000000039000 paddr 0x0000000000039000 align 2**12
         filesz 0x00000000006b9389 memsz 0x00000000006b9389 flags r-x
    LOAD off    0x00000000006f3000 vaddr 0x00000000006f3000 paddr 0x00000000006f3000 align 2**12
         filesz 0x0000000000204847 memsz 0x0000000000204847 flags r--
    LOAD off    0x00000000008f7920 vaddr 0x00000000008f8920 paddr 0x00000000008f8920 align 2**12
         filesz 0x00000000000183e0 memsz 0x0000000000022fd0 flags rw-

Also, LOADs with different flags than the previous one are page-aligned (they need to be, otherwise it wouldn't work with MMU permission bits). Maybe that's enough of a heuristic, I don't know.

edit: the load offset for the writable data is curious: 0x00000000008f7920 is not page aligned, and right after the read-only data, does this mean read-only and read-write data are stilll allowed to share a page?

<!--a722867cd34abeea1fadc8d60700f111-->

Gitian builds

<!--9cd9c72976c961c55c7acef8f6ba82cd-->

Guix builds

I've implemented a security check here: https://github.com/laanwj/bitcoin/tree/2020_07_separate_code_security_check

I think it's correct, though it might be too strict, it might be enough to spot-check only a few sections like .text and .data and .rodata. Then again, sometimes it's better to be strict to catch future problems. Haven't tested it for all platforms so we might still get some surprises there.

I've implemented a security check here @laanwj I've pulled in that commit, and queued up some builds. We'll see how it goes.

<!--9cd9c72976c961c55c7acef8f6ba82cd-->

Guix builds

make[1]: Leaving directory '/bitcoin/distsrc-x86_64-linux-gnu'
+ make -C src --jobs=1 check-security V=1
make: Entering directory '/bitcoin/distsrc-x86_64-linux-gnu/src'
Checking binary security...
READELF=/gnu/store/pzq9s5ldl90h72p26jkdakyccdg9ib3k-profile/bin/x86_64-linux-gnu-readelf OBJDUMP=x86_64-linux-gnu-objdump OTOOL= /gnu/store/pzq9s5ldl90h72p26jkdakyccdg9ib3k-profile/bin/python3.7 ../contrib/devtools/security-check.py bitcoind  bitcoin-cli bitcoin-tx bitcoin-wallet test/test_bitcoin bench/bench_bitcoin qt/bitcoin-qt  
test/test_bitcoin: failed separate_code
qt/bitcoin-qt: failed separate_code
make: *** [Makefile:20581: check-security] Error 1
make: Leaving directory '/bitcoin/distsrc-x86_64-linux-gnu/src'

That's strange. It works locally for x86_64. This temporary patch might help figure out, it prints the mismatching sections and complete elfread output in case of failure:

diff --git a/contrib/devtools/security-check.py b/contrib/devtools/security-check.py
index 4f315e10d1d69157f93dfc47e1be8f3deb07a11a..dd16c132dfdf275b3767e8e230988f6d1343a14f 100755
--- a/contrib/devtools/security-check.py
+++ b/contrib/devtools/security-check.py
@@ -178,11 +178,15 @@ def check_ELF_separate_code(executable):
                 flags_per_section[section] = flags
     # Spot-check ELF LOAD program header flags per section
     # If these sections exist, check them against the expected R/W/E flags
+    retval = True
     for (section, flags) in flags_per_section.items():
         if section in EXPECTED_FLAGS:
             if EXPECTED_FLAGS[section] != flags:
-                return False
-    return True
+                print(f"Section {section} {flags} != {EXPECTED_FLAGS[section]}")
+                retval = False
+    if not retval:
+        subprocess.run([READELF_CMD, '-l', '-W', executable])
+    return retval
 
 def get_PE_dll_characteristics(executable) -> int:
     '''Get PE DllCharacteristics bits'''

<!--a722867cd34abeea1fadc8d60700f111-->

Gitian builds

guix error also on gitian:

make[1]: Leaving directory '/home/ubuntu/build/bitcoin/distsrc-x86_64-linux-gnu'
+ make -j1 -C src check-security
make: Entering directory '/home/ubuntu/build/bitcoin/distsrc-x86_64-linux-gnu/src'
Checking binary security...
test/test_bitcoin: failed separate_code
qt/bitcoin-qt: failed separate_code
Makefile:18662: recipe for target 'check-security' failed
make: *** [check-security] Error 1
make: Leaving directory '/home/ubuntu/build/bitcoin/distsrc-x86_64-linux-gnu/src'

That's strange. It works locally for x86_64. This temporary patch might help figure out, it prints the mismatching sections and complete elfread output in case of failure:

guix error also on gitian:

Thanks. I can recreate some issues locally, have been taking a look today.

edit: the load offset for the writable data is curious: 0x00000000008f7920 is not page aligned, and right after the read-only data, does this mean read-only and read-write data are stilll allowed to share a page?

I'm still spooked by this, by the way. Not sure if it is an (upstream) bug or expected behavior. I thought about adding a check that LOAD ranges with different permissions don't overlap on the same memory pages, but this is a clear violation of this, making the separation less effective.

(in any case, not a reason to not move forward with this as it is, better is better)

Edit: it does seem to work out locally, maybe I just miscounted? I've added a per-page permission check in this commit: https://github.com/laanwj/bitcoin/commit/9d9fcefcaec3d638f472ea77c146eaec8f9079c1

I've pushed up a modified version of @laanwj's test that works for me across all binaries, and I think is a bit more robust. One of the issues with the previous test was that when the binaries were large (i.e bitcoin-qt and test_bitcoin) the output in the readelf table would spill into adjacent columns, and you'd end up testing something like 9 R against R E etc. I've also added some additional sections to check for.

If someone wants to test, one way to at least sanity-check the behaviour is to modify the permission of one of the sections in EXPECTED_FLAGS. i.e:

diff --git a/contrib/devtools/security-check.py b/contrib/devtools/security-check.py
index dc74de919..965a9b250 100755
--- a/contrib/devtools/security-check.py
+++ b/contrib/devtools/security-check.py
@@ -146,7 +146,7 @@ def check_ELF_separate_code(executable):
         # Read + execute
         '.init': 'R E',
         '.plt': 'R E',
-        '.plt.got': 'R E',
+        '.plt.got': 'WRONG!',
         '.plt.sec': 'R E',
         '.text': 'R E',
         '.fini': 'R E',

and check that the test fails for all binaries (assuming you've chosen a section that is in all binaries. i.e NOT .qtmetadata).

make -C src check-security
make: Entering directory '/home/ubuntu/build/bitcoin/distsrc-x86_64-linux-gnu/src'
Checking binary security...
bitcoind: failed separate_code
bitcoin-cli: failed separate_code
bitcoin-tx: failed separate_code
bitcoin-wallet: failed separate_code
test/test_bitcoin: failed separate_code
qt/bitcoin-qt: failed separate_code

I'm still spooked by this, by the way. Not sure if it is an (upstream) bug or expected behavior. I thought about adding a check that LOAD ranges with different permissions don't overlap on the same memory pages, but this is a clear violation of this, making the separation less effective.

Now that I've got this test working, I'll take a look here as well. In any case, I think any changes / an additional test for that behaviour could be a in a followup PR.

<!--9cd9c72976c961c55c7acef8f6ba82cd-->

Guix builds

ACK 65d0f1a53354fb25c8152ee5b430cf57e6508594 Thanks for fixing the test. I think further improving the check can be left for another PR.

<!--a722867cd34abeea1fadc8d60700f111-->

Gitian builds