ICU4C: Remove fixed DLL base addresses when building Windows DLLs
When building DLLs for Windows, ICU4C still uses fixed base addresses for the libraries, despite the fact that (seemingly) nothing within the ICU code base ever uses or relies on these fixed address.
This is rather bad for a number of reasons:
This forces ASLR to be completely disabled for the ICU libraries, which is a security risk.
It prevents using high-entropy virtual addresses for 64-bit architectures (an enhanced form of ASLR).
It completely blocks building ICU libraries for architectures like ARM64, were DYNAMICBASE is required/mandated.
It also prevents using the non-UWP binaries in a UWP application as well.
I suspect that these fixed base addresses are a hold over from back when ICU supported Windows XP/2000. However, as of ICU 58 these older OSs are no longer supported, and the minimum supported OS version is Windows Vista, which fully supports ASLR.
We should consider removing these fixed base addresses and enable DYNAMICBASE in order to improve the security of the ICU libraries on Windows, and to unblock building for other architectures.
Thanks for the related info Markus!
I found this older related ticket
We now have /DYNAMICBASE and /NXCOMPAT enabled on all the DLLs with this ticket.
https://docs.oracle.com/cd/E19879-01/820-4343/abeio/index.html “Sun GlassFish Enterprise Server 2.1 Performance Tuning Guide” (how to rebase ICU DLLs to increase the amount of contiguous address space available for Java memory)
https://sourceforge.net/p/icu/mailman/message/5625490/ (2002) “Re: Windows build question – DLL base address“ (where I explained why we do this, and gave a hint about how we got the addresses)
I suspect that these fixed base addresses are a hold over from back when ICU supported Windows XP/2000.
Or even earlier. I am pretty sure I did this based on good old Win32 practice, in ca. year 2000.
I believe the idea was that giving non-default addresses would reduce library relocations at load time.
(x86 CPUs at the time didn't support PIC, or not well, so library relocation could be expensive.)
Clearly the addresses that I chose then don't make much sense in a 64-bit world