Add branch protection flags

[david-a-wheeler]

No description provided.

[david-a-wheeler]

@eslerm @thomasnyman - what do you think?

[kees]

This looks good to me!

[eslerm]

thank you @david-a-wheeler !

[siddhesh]

Should there be a separate Architecture-specific hardening flags section? Also, recommending both flags in the TL;DR section seems wrong since the flags won't get recognized anywhere other than the platform they're implemented for.

[david-a-wheeler]

siddhesh commented yesterday asked:

Should there be a separate Architecture-specific hardening flags section? Also, recommending both flags in the TL;DR section seems wrong since the flags won't get recognized anywhere other than the platform they're implemented for.

I disagree. Many projects compile for multiple architectures. Even if they only use one today, they may add another one tomorrow. I think it's safer to enable the hardening flags where you can, even if they don't apply to the architecture you're using today. It hurts nothing.

[david-a-wheeler]

I've posted an update that I believe resolves all posted issues.

[siddhesh]

I disagree. Many projects compile for multiple architectures. Even if they only use one today, they may add another one tomorrow. I think it's safer to enable the hardening flags where you can, even if they don't apply to the architecture you're using today. It hurts nothing.

I'm not saying we shouldn't recommend the architecture-specific flags in the TL;DR; section, I'm saying that the way it is represented right now is incorrect because it will result in a compiler error on all architectures since the architecture-specific flags are recognized only on the supported target. Maybe something like this instead:

When compiling C or C++ code on compilers such as GCC and clang, turn on these generic flags for detecting vulnerabilities at compile time and enable run-time protection mechanisms:
~~~~sh
-O2 -Wall -Wformat=2 -Wconversion -Wtrampolines -Werror \
-D_FORTIFY_SOURCE=3 \
-D_GLIBCXX_ASSERTIONS \
-fstack-clash-protection -fstack-protector-strong \
-Wl,-z,nodlopen -Wl,-z,noexecstack \
-Wl,-z,relro -Wl,-z,now \
-fPIE -pie -fPIC -shared
~~~~

Additionally, turn on `-fcf-protection=full` on x86 or  `-mbranch-protection=standard` on aarch64 to get protection against ROP based security attacks on hardware platforms that support it.

Instead of "on Intel" I'll just say "on many x86 architectures". If they need to know precisely which ones they'll need to consult their specific compiler documentation anyway.

The instructions for both PAC/BTI and SHSTK/IBT are in the NOP space, so they'll work seamlessly even on chips that don't have those features. In fact FWIW, SHSTK only got kernel support in 6.6, so at the moment it's still NOP pretty much everywhere in the Linux world.

[david-a-wheeler]

I'm not saying we shouldn't recommend the architecture-specific flags in the TL;DR; section, I'm saying that the way it is represented right now is incorrect because it will result in a compiler error on all architectures since the architecture-specific flags are recognized only on the supported target.

Are you sure? I don't see that behavior. I tried this on both clang and GCC on Mac Intel - including the ARM options - and had no problems.

Here's my text Makefile:

# Set CC to the compiler to use. E.g.:

CC=/usr/local/Cellar/gcc/13.2.0/bin/gcc-13

CFLAGS_HARDENING = \
-O2 -Wall -Wformat=2 -Wconversion -Wtrampolines -Werror \
-D_FORTIFY_SOURCE=3 \
-D_GLIBCXX_ASSERTIONS \
-fstack-clash-protection -fstack-protector-strong \
-fcf-protection=full -mbranch-protection=standard \
-Wl,-z,nodlopen -Wl,-z,noexecstack \
-Wl,-z,relro -Wl,-z,now \
-fPIE -pie -fPIC -shared

demo: demo.c
	$(CC) $(CFLAGS_HARDNING) $(CFLAGS) -o demo demo.c

[eslerm]

It might be more accurate to say that these flags mitigate code reuse attacks, rather than branch protections or specifying ROP. -fcfp is not exclusively for branch protection.

iiuc, the stronger portion of -fcfp is it's shadow stack protection to prevent ROP, where as the endbranch protection is for COP/JOP. -mbranch-protections' BTI and PAC are both branch specific.

[david-a-wheeler]

Ah! My makefile had a bug. Once fixed, I do see clang generating errors for unknown flags. Well, that's annoying.

I guess we can list options "per architecture". Frankly the best solution here is something like autoconf, so you can add all the options that work, but not everyone will use autoconf. Is there a better approach?

[david-a-wheeler]

I've pulled out the architecture-specific flags. How is this?

[david-a-wheeler]

I haven't resolved this one: eslerm suggested changes last week - suggestions welcome.

[david-a-wheeler]

I managed to eliminate the merge conflicts (for the moment). I propose merging this (as it's an improvement), and we can make future changes without fighting as many merge conflicts.

[david-a-wheeler]

Per meeting today, we agreed to merge this.