[ld] 2.36 PE flags changes (PR19011, commit 514b4e19)

[ld] 2.36 PE flags changes (PR19011, commit 514b4e19)

[ASSI]

This change is fundamentally incompatible with how Cygwin operates (and
also MSys2 since they're using the same code base, although they don't
seem to have that fully realized yet).  So I'll have to patch it out for
Cygwin (and likely MingW64 the cross compilation toolchain to be safe).

I am wondering how this change made it into the code base without a
configure option.  Also, the way it was announced is somewhat misleading
since it also affects executables, not just DLL (I wasn't even aware
that ASLR would affect executables, but it does -- if anybody knows
where that is documented, please let me know).  In other words, you can
create failures by simply compiling to an a.out file since that will now
have both ASLR and NX switched on for i686 and additionally high entropy
for x86_64 as this excerpt from running a bog standard configure test
for fork shows:

--8<---------------cut here---------------start------------->8---
checking for working fork...       1 [main] conftest 7615 D:\Freeware\CygProShare\cygpkgs\mosh\mosh.x86\build\conftest.exe: *** fatal error in forked process - fork: can't reserve 
memory for parent stack 0x1400000 - 0x1600000, (child has 0x840000 - 0xA40000), Win32 error 487
  74330 [main] conftest 7615 cygwin_exception::open_stackdumpfile: Dumping stack trace to conftest.exe.stackdump
      1 [main] conftest 7614 dofork: child -1 - forked process 1224 died unexpectedly, retry 0, exit code 0x100, errno 11
no
--8<---------------cut here---------------end--------------->8---

In this case either the space that the stack occupied in the parent got
clobbered in the forked image or the stack itself got moved.  I'm
suspecting the latter since I have never seen additional mappings in a
process on fork before, especially not when the image uses only
cygwin1.dll and nothing else.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Waldorf MIDI Implementation & additional documentation:
http://Synth.Stromeko.net/Downloads.html#WaldorfDocs

Re: [ld] 2.36 PE flags changes (PR19011, commit 514b4e19)

[Jan Beulich]

On 28.02.2021 13:22, ASSI wrote:
> 
> This change is fundamentally incompatible with how Cygwin operates (and
> also MSys2 since they're using the same code base, although they don't
> seem to have that fully realized yet).  So I'll have to patch it out for
> Cygwin (and likely MingW64 the cross compilation toolchain to be safe).
> 
> I am wondering how this change made it into the code base without a
> configure option.  Also, the way it was announced is somewhat misleading
> since it also affects executables, not just DLL (I wasn't even aware
> that ASLR would affect executables, but it does -- if anybody knows
> where that is documented, please let me know).  In other words, you can
> create failures by simply compiling to an a.out file since that will now
> have both ASLR and NX switched on for i686 and additionally high entropy
> for x86_64 as this excerpt from running a bog standard configure test
> for fork shows:

As reported previously, that change has caused me headache too,
entirely outside of Cygwin or alike. However, having looked at
the change in some detail, I'm not sure I see the ASLR aspect here,
since ...

> --8<---------------cut here---------------start------------->8---
> checking for working fork...       1 [main] conftest 7615 D:\Freeware\CygProShare\cygpkgs\mosh\mosh.x86\build\conftest.exe: *** fatal error in forked process - fork: can't reserve 
> memory for parent stack 0x1400000 - 0x1600000, (child has 0x840000 - 0xA40000), Win32 error 487
>   74330 [main] conftest 7615 cygwin_exception::open_stackdumpfile: Dumping stack trace to conftest.exe.stackdump

... 0x1400000 doesn't look like a randomized (image base?) address,
but a link-time one. So I wonder what specific "flags" changes you
are talking about. Of course I know nothing about Cygwin's
internal workings, yet a first guess would be that it doesn't deal
properly with the case where said range is already occupied (by
the executable image in this case, as it would seem)? If that was
the case, then the binutils change would merely have uncovered a
shortcoming ...

Irrespective I do agree with what I imply from your posting - the
change, despite its good intentions, didn't care enough about
compatibility with existing use cases.

Jan

Re: [ld] 2.36 PE flags changes (PR19011, commit 514b4e19)

[ASSI]

Jan Beulich via Binutils writes:
> ... 0x1400000 doesn't look like a randomized (image base?) address,
> but a link-time one. So I wonder what specific "flags" changes you
> are talking about.

That's the stack and it has to be at a fixed address.  Setting the ASLR
flag on the executable has either caused something else to be mapped
there during the fork emulation or the stack to get moved.  Either way
it's not going to work since the map in the child process has to be
exactly the same as the one in the parent.

> Irrespective I do agree with what I imply from your posting - the
> change, despite its good intentions, didn't care enough about
> compatibility with existing use cases.

It almost never hurts to have an option of switching back to the old
behaviour and then see who needs to do it and why.

Just to make it clear, I'd love to have ASLR working for Cygwin, but the
behaviour of it on Windows doesn't allow that currently.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf rackAttack:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds