Control Flow Guard is a security mitigation that verifies the
target address of indirect calls. It works by having the compiler insert
instrumentation code at indirect call sites, and also the linker write the
necessary data and flags into the PE/COFF image to enable the feature on
Windows' end.
In LLVM, Clang already knows how to insert the CFGuard instrumentation code
and LLD is able to produce CFGuard data, like how MSVC does it. 1 2
Conveniently, these work the same when targeting mingw-w64 given the proper
compiler and linker flags. They however assume certain symbols to be available
in order to work, and mingw-w64 does not provide them yet. For example, if
you try to compile a source file into an x86_64 EXE with -Xclang -cfguard
,
you may get this:
ld.lld: error: undefined symbol: __guard_dispatch_icall_fptr
To be compatible with MSVC, Clang expects the symbol __guard_dispatch_icall_fptr
on x86_64, and __guard_check_icall_fptr
on x86, arm and aarch64. In addition,
LLD uses the contents of the _load_config_used
symbol as the load config
directory, which contains CFGuard support flags and data pointers.
If we are fine with reusing these existing support in LLVM as-is, here is
what we need to do:
__guard_check_icall_fptr
and __guard_dispatch_icall_fptr
_load_config_used
data structure which LLD will usemingw-w64-*
, compiler-rt
, libc++
)-Xclang -cfguard
to compile flags-Wl,-Xlink,-guard:cf
to link flags.Users will still need to opt into enabling CFGuard by passing the same compile
flags and link flags. For users who does not enable CFGuard, this setup does
add a small amount of bloat:
As far as I can tell, there is zero support for CFGuard in GCC and Binutils.
These changes should not affect a GCC-based mingw-w64 toolchain.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4