Cygwin: link the DLL with --dynamicbase again

[alirobe]

MSYS2 quickly removed the --dynamicbase link flag that upstream Cygwin introduced in 3.4.0, on 2022-12-17 (msys2/MSYS2-packages#3425). This was due to Docker-only fork() failures that emerged one day after updating to 3.4.3. The precise reason for those failures was never found.

Subsequently, upstream Cygwin fixed three fork() regressions from that period in 3.4.4, 3.4.5 and 3.4.7:

• Child-side initialisation order broken by cygwin/cygwin@30add3e6b3e3, fixed in 3.4.4 by cygwin/cygwin@a81fef51cf9f;
• Shared region allocation under ASLR, cygwin/cygwin@dc0fe7742b8c in 3.4.4/3.4.5;
• Cygheap size computation from the ASLR work itself, cygwin/cygwin@a14a0e542d3a in 3.4.7, whose symptom was the same "child_copy: ... read copy failed, Win32 error 299" as the Docker reports.

I think this solved the problem, so this patch brings back --dynamicbase from upstream.

Without this flag, Mandatory ASLR breaks every MSYS program (#327, git-for-windows/git#1412), inside process-isolated containers too. Git for Windows even has an explicit installer step to help solve this for people.

I tested the on the shipped 3.6.10 DLL with only the dynamicbase bit set, and again on the DLL CI builds from this branch (DllCharacteristics 0x0040, no high-entropy VA): on Windows 11 with Mandatory ASLR on and no exemptions, 200 subshell forks, pipelines, git and perl all work, where the stock DLL fails on the first fork.

In Windows containers on Server 2022 and Server 2025 runners, under both process and Hyper-V isolation, 50/50 forks in every combination: https://github.com/alirobe/msys2-aslr-fork-test (run 37634248186).

So I think it's safe to removes the previous emergency patch from the series, bringing our behavior closer to upstream stable behavior.

Supersedes #380.

Assisted by Claude Fable 5.1; reviewed, tested and signed off by the author.

[mmuetzel]

Not a real review: But it might make sense to change the first line of the commit message to fixup! Revert "Cygwin: Enable dynamicbase on the Cygwin DLL by default". If I understand correctly, that will indicate that the commit from this PR should be squashed with f53fdff on the next rebase on upstream Cygwin.
(But it might make sense to wait for feedback by maintainers first.)

[alirobe]

Done. It's 3am here in oz, so I am logging off for the night - sorry if unresponsive for next few hours. Appreciate any feedback/review.

[alirobe]

Follow-up: this change is necessary but not sufficient for running without exemptions under Mandatory ASLR.

72 of the 74 DLLs in Git for Windows 2.55.0's usr/bin also lack dynamicbase, so programs that load them and then fork still fail:

child_info_fork::abort: \??\C:\Program Files\Git\usr\bin\msys-iconv-2.dll: Loaded to different address: parent(0xC10000) != child(0xC60000)

With only the runtime flagged, timeout 5 true succeeded 1/50 (Windows 11, Mandatory ASLR on, no exemptions); with every DLL flagged, 50/50. Bash's own forks pass either way, which is why I missed it.

So exemption-free use also needs the package DLLs linked with --dynamicbase. I'm trying that now: running my machine with every DLL flagged, and building libiconv and gettext with LDFLAGS="-Wl,--dynamicbase" as the msys default in a fork (alirobe/MSYS2-packages@dynamicbase-default, no PR) to check a real build behaves the same. I'll report back. Happy to adjust or close this PR if you'd rather consider it all together.

[alirobe]

Update: building the DLLs with --dynamicbase works the same as setting the bit afterwards.

I changed the msys default in pacman/makepkg.conf to LDFLAGS="-Wl,--dynamicbase" and built libiconv 1.19 and gettext 0.22.5 in CI. All seven resulting DLLs have dynamicbase and a .reloc section.

Branch: https://github.com/alirobe/MSYS2-packages/tree/dynamicbase-default
CI run: https://github.com/alirobe/MSYS2-packages/actions/runs/37910713034

Test setup: a copy of Git for Windows 2.55.0 with this PR's runtime flag, under Mandatory ASLR with no exemptions. timeout 5 true loads only the runtime, msys-intl-8.dll and msys-iconv-2.dll. With those two libraries as shipped, it succeeded 2/50. With the rebuilt ones, 50/50.

So one-line default plus rebuilds looks like enough. I'll make a PR to MSYS2-packages for it.