[mingw] use delay loading for DLLs that are subject to side loading
* This reverts much of commits f6ac559f4d0a9a2e5043a972442d272c2da71de3 and 19472668370aacec0dba9dda306601cfc4a4ed7e
so that we call the Windows APIs directly again, while ensuring that, by the time we load the DLLs,
sideloading mitigation has already been applied by the application.
* This is a continuation of #1877, and should help prevent re-introducing side-loading issues when we
link against new libraries, as well as allow us to drop some of the manual DLL hooking we've been
doing to prevent it, to clean up the code.
* Note that this is a bit more complex than what the stackoverflow post suggests, because we need to
create delayloaded libs for both 32-bit and 64-bit, which use a different calling convention and
therefore need to use different .def files. So there's a lot of gymkhana involved, with Makefiles
and whatnot, to get us there.
* Also simplify the use of CM_Get_DevNode_Registry_PropertyA() in dev.c since recent versions of
MinGW now have support for it.
* Also fix 2 small issues in net.c (potential overflow) and format.c (memory leak).
2022-04-12 10:09:29 +00:00
|
|
|
# Create delay-loaded libraries from a DLL, that aren't vulnerable to side-loading
|
|
|
|
|
AM_V_DLLTOOL_0 = @echo " LIB $@";$(DLLTOOL)
|
|
|
|
|
AM_V_DLLTOOL_1 = $(DLLTOOL)
|
|
|
|
|
AM_V_DLLTOOL_ = $(AM_V_DLLTOOL_$(AM_DEFAULT_VERBOSITY))
|
|
|
|
|
AM_V_DLLTOOL = $(AM_V_DLLTOOL_$(V))
|
|
|
|
|
|
|
|
|
|
AM_V_SED_0 = @echo " SED $<";$(SED)
|
|
|
|
|
AM_V_SED_1 = $(SED)
|
|
|
|
|
AM_V_SED_ = $(AM_V_SED_$(AM_DEFAULT_VERBOSITY))
|
|
|
|
|
AM_V_SED = $(AM_V_SED_$(V))
|
|
|
|
|
|
|
|
|
|
# Ah the joys of Windows DLL calling conventions, that require an @## suffix in the .def
|
|
|
|
|
# for x86_32 and but no @## for x86_64, thereby forcing us to strip stuff according to the
|
|
|
|
|
# target arch. Oh, and we can't use 'target_cpu' or AC definitions on account that we are
|
|
|
|
|
# switching archs when building on our local machine, and don't want to have to go though
|
|
|
|
|
# a costly reconf each time when we can simply issue a 'make clean'.
|
|
|
|
|
TUPLE := $(shell $(CC) -dumpmachine)
|
|
|
|
|
TARGET := $(word 1,$(subst -, ,$(TUPLE)))
|
|
|
|
|
DEF_SUFFIX := $(if $(TARGET:x86_64=),.def,.def64)
|
|
|
|
|
|
|
|
|
|
.PHONY: all
|
2023-07-15 21:20:59 +00:00
|
|
|
all: dwmapi-delaylib.lib version-delaylib.lib wintrust-delaylib.lib
|
[mingw] use delay loading for DLLs that are subject to side loading
* This reverts much of commits f6ac559f4d0a9a2e5043a972442d272c2da71de3 and 19472668370aacec0dba9dda306601cfc4a4ed7e
so that we call the Windows APIs directly again, while ensuring that, by the time we load the DLLs,
sideloading mitigation has already been applied by the application.
* This is a continuation of #1877, and should help prevent re-introducing side-loading issues when we
link against new libraries, as well as allow us to drop some of the manual DLL hooking we've been
doing to prevent it, to clean up the code.
* Note that this is a bit more complex than what the stackoverflow post suggests, because we need to
create delayloaded libs for both 32-bit and 64-bit, which use a different calling convention and
therefore need to use different .def files. So there's a lot of gymkhana involved, with Makefiles
and whatnot, to get us there.
* Also simplify the use of CM_Get_DevNode_Registry_PropertyA() in dev.c since recent versions of
MinGW now have support for it.
* Also fix 2 small issues in net.c (potential overflow) and format.c (memory leak).
2022-04-12 10:09:29 +00:00
|
|
|
|
|
|
|
|
%.def64: %.def
|
|
|
|
|
$(AM_V_SED) "s/@.*//" $< >$@
|
|
|
|
|
|
|
|
|
|
%-delaylib.lib: %$(DEF_SUFFIX)
|
|
|
|
|
$(AM_V_DLLTOOL) --input-def $< --output-delaylib $@ --dllname $(basename $<).dll
|
|
|
|
|
|
|
|
|
|
clean:
|
|
|
|
|
$(RM) -rf *.lib
|