On 3/3/2025 4:22, Jacek Caban wrote:
This is mandatory on ARM64EC and also required on AArch64 for ARM64X builds.
Instead of extending the existing logic, unify it by always including it in
mingwex.
Fill CF Guard fields with zeroes when CF Guard is not enabled in CRT builds.
This
leverages existing LLD load config validation warnings to signal potential
issues
if the user enables CF Guard while using a CRT that was not built with it.
In practice, this means load config will always be present in output images
when using
LLD. Since ld.bfd does not support load config, it remains unaffected.
---
mingw-w64-crt/Makefile.am | 8 ++---
mingw-w64-crt/configure.ac | 4 +--
.../mingw_cfguard_loadcfg.S => crt/loadcfg.S} | 30 +++++++++++++------
3 files changed, 24 insertions(+), 18 deletions(-)
rename mingw-w64-crt/{cfguard/mingw_cfguard_loadcfg.S => crt/loadcfg.S} (82%)
diff --git a/mingw-w64-crt/Makefile.am b/mingw-w64-crt/Makefile.am
index 423e233ac..186e17979 100644
--- a/mingw-w64-crt/Makefile.am
+++ b/mingw-w64-crt/Makefile.am
@@ -22,6 +22,7 @@ endif
AM_CPPFLAGS=$(sysincludes)
AM_CFLAGS=-pipe -std=gnu99 -D_CRTBLD -D_WIN32_WINNT=0x0f00
-D__MSVCRT_VERSION__=0x600 -D__USE_MINGW_ANSI_STDIO=0 @IMAGEBASE_CFLAGS@
@CFGUARD_CFLAGS@ @ADD_C_CXX_WARNING_FLAGS@ @ADD_C_ONLY_WARNING_FLAGS@
AM_CXXFLAGS=@ADD_C_CXX_WARNING_FLAGS@ @ADD_CXX_ONLY_WARNING_FLAGS@
+AM_CCASFLAGS=@CFGUARD_CFLAGS@
CPPFLAGSARM32=-mfpu=vfpv3
CPPFLAGS32=-m32 -masm=att
CPPFLAGS64=-m64 -masm=att
@@ -928,6 +929,7 @@ src_msvcr120_app=\
# These mingwex sources are target independent:
src_libmingwex=\
+ crt/loadcfg.S \
cfguard/mingw_cfguard_support.c \
\
misc/dllmain.c \
@@ -1015,12 +1017,6 @@ src_libmingwex=\
stdio/vsnprintf.c stdio/vsnwprintf.c \
stdio/wtoll.c stdio/mingw_asprintf.c stdio/mingw_vasprintf.c
-# Include the default load config struct only for Control Flow Guard support.
-if CFGUARD
-src_libmingwex+=\
- cfguard/mingw_cfguard_loadcfg.S
-endif
-
# these go into both 32 and 64 bit x86 versions:
src_libmingwex_x86=\
math/cbrtl.c math/erfl.c math/fdiml.c
math/fmal.c math/fmaxl.c \
diff --git a/mingw-w64-crt/configure.ac b/mingw-w64-crt/configure.ac
index 37851f605..f4f8d954d 100644
--- a/mingw-w64-crt/configure.ac
+++ b/mingw-w64-crt/configure.ac
@@ -273,10 +273,8 @@ AC_ARG_ENABLE([cfguard],
AC_MSG_RESULT([$enable_cfguard])
AS_CASE([$enable_cfguard],
[no],[],
- [yes],[AS_VAR_SET([CFGUARD])
- AS_VAR_SET([CFGUARD_CFLAGS],[-mguard=cf])],
+ [yes],[AS_VAR_SET([CFGUARD_CFLAGS],["-mguard=cf -DHAS_CFGUARD"])],
[AC_MSG_ERROR([invalid argument. Must be either yes or no.])])
-AM_CONDITIONAL([CFGUARD], [AS_VAR_TEST_SET([CFGUARD])])
AC_SUBST([CFGUARD_CFLAGS])
AC_MSG_CHECKING([whether to enable experimental features])
diff --git a/mingw-w64-crt/cfguard/mingw_cfguard_loadcfg.S
b/mingw-w64-crt/crt/loadcfg.S
similarity index 82%
rename from mingw-w64-crt/cfguard/mingw_cfguard_loadcfg.S
rename to mingw-w64-crt/crt/loadcfg.S
index a7028b1a8..ab445d708 100644
--- a/mingw-w64-crt/cfguard/mingw_cfguard_loadcfg.S
+++ b/mingw-w64-crt/crt/loadcfg.S
@@ -13,6 +13,12 @@ Many of the symbols referenced here are supplied by the
linker. This file has
been constructed with LLVM/LLD in mind.
*/
+#ifdef HAS_CFGUARD
+ .def @feat.00; .scl 3; .type 0; .endef
+ .globl @feat.00
+@feat.00 = 0x800
+#endif
+
I agree with Martin that this change should not be in this patch.
#if defined(__x86_64__) || defined(__aarch64__)
# define PTR .8byte
# define ALIGN 8
@@ -37,6 +43,12 @@ Ref:
https://docs.microsoft.com/en-us/windows/win32/secbp/pe-metadata
# define SYM(x) x
#endif
+#ifdef HAS_CFGUARD
+# define CFGSYM(x) SYM(x)
+#else
+# define CFGSYM(x) 0
+#endif
+
#if defined(INCLUDE_MSVC_FEATURES)
/*
These features are specific to MSVC as far as I am aware.
@@ -87,17 +99,17 @@ SYM(_load_config_used):
#else
PTR 0 /* GuardCFCheckDispatch */
#endif
I think `GuardCFCheckFunction` and `GuardCFCheckDispatch` should also
get the same treatment. These fields will not be used when CFGuard is
not enabled. Besides, if none of the objects to be linked use CFGuard,
we should not be pulling in `__guard_check_icall_fptr`,
`__guard_dispatch_icall_fptr`, and the assorted dummy functions for no
reason.
- PTR SYM(__guard_fids_table) /* GuardCFFunctionTable */
- PTR SYM(__guard_fids_count) /* GuardCFFunctionCount */
- .4byte SYM(__guard_flags) /* GuardFlags */
+ PTR CFGSYM(__guard_fids_table) /* GuardCFFunctionTable */
+ PTR CFGSYM(__guard_fids_count) /* GuardCFFunctionCount */
+ .4byte CFGSYM(__guard_flags) /* GuardFlags */
.2byte 0 /* CodeIntegrity_Flags */
.2byte 0 /* CodeIntegrity_Catalog */
.4byte 0 /* CodeIntegrity_CatalogOffset */
.4byte 0 /* CodeIntegrity_Reserved */
- PTR SYM(__guard_iat_table) /* GuardAddressTakenIatEntryTable */
- PTR SYM(__guard_iat_count) /* GuardAddressTakenIatEntryCount */
- PTR SYM(__guard_longjmp_table) /* GuardLongJumpTargetTable */
- PTR SYM(__guard_longjmp_count) /* GuardLongJumpTargetCount */
+ PTR CFGSYM(__guard_iat_table) /* GuardAddressTakenIatEntryTable */
+ PTR CFGSYM(__guard_iat_count) /* GuardAddressTakenIatEntryCount */
+ PTR CFGSYM(__guard_longjmp_table) /* GuardLongJumpTargetTable */
+ PTR CFGSYM(__guard_longjmp_count) /* GuardLongJumpTargetCount */
PTR 0 /* DynamicValueRelocTable */
PTR 0 /* CHPEMetadataPointer */
PTR 0 /* GuardRFFailureRoutine */
@@ -114,8 +126,8 @@ SYM(_load_config_used):
PTR 0 /* EnclaveConfigurationPointer */
#endif
PTR 0 /* VolatileMetadataPointer */
- PTR SYM(__guard_eh_cont_table) /* GuardEHContinuationTable */
- PTR SYM(__guard_eh_cont_count) /* GuardEHContinuationCount */
+ PTR CFGSYM(__guard_eh_cont_table) /* GuardEHContinuationTable */
+ PTR CFGSYM(__guard_eh_cont_count) /* GuardEHContinuationCount */
PTR 0 /* GuardXFGCheckFunctionPointer */
PTR 0 /* GuardXFGDispatchFunctionPointer */
PTR 0 /* GuardXFGTableDispatchFunctionPointer */
Thanks. I made a couple of inline comments, but otherwise it seems good
to me.
Regards,
Alvin
_______________________________________________
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
