cygwin + binutils 2.36 + ASLR/dynamicbase defaults

[ASSI]

Jeremy Drake via Cygwin writes:
> Well, Microsoft's LINK.EXE and LLVM's LLD have already been using these
> new defaults for some time.  But I was surprised how quickly my patch was
> accepted/merged.

That was not under dispute in any of the discussions I've seen on this
topic.

> To clarify, default base addresses should not have changed for cygwin
> targets, they were already above 4GB.

For 64bit, yes -- so I wasn't overly worried about that.

> I have a prelimiary patch that I plan to send upstream once I get some
> testing done on it, which reverts the default dll characteristics for
> cygwin targets.  I don't know if what you've done to 'nix it' for Cygwin
> was similar.

I've just done what makes it close enough to 2.35.2 in my view:

https://cygwin.com/git-cygwin-packages/?p=git/cygwin-packages/binutils.git;a=blob_plain;f=binutils-2.36.1-cygwin-peflags.patch

I don't want to carry such a patch for any longer time of course.

> I have not seen anything one way or the other on the NXCOMPAT flag.  Does
> that also needs to be reverted for Cygwin?

I don't know.  I think maybe not since it should announce itself pretty
early in testing, but things are always a bit more complicated than they
seem at first.

> I have seen the issues you described on 32-bit, but my understanding of
> how ASLR works suggested that it should be very rare on 64-bit.

That's the crux of the matter.  It fails when it produces a collision
and the chances of it doing that are going down exponentially with the
size of the address space.  But the target is not to have it fail
rarely, it must not fail at all.

> ... but now that you mention the stack moving, yes, I could see that
> being an issue.

Note that I don't have an idea if the stack really got moved or
something else mapped into the space formerly occupied by the stack.
Either way would be surprising since the case where it happened isn't
using any libraries besides cygwin1.dll.

> Yes, the specific field where these flags are stored is called "DLL
> Characteristics" so that is how it was referred to, but they do not
> exclusively apply to DLLs.
>
> https://docs.microsoft.com/en-us/windows/win32/debug/pe-format#dll-characteristics

Again, the question really is "what does this flag actually do for
executables"?  ASLR is not very well documented beyond the fact that it
exists and the odd blog post here and there as far as I can tell.  Its
been changed quite a bit over the time too, but which change went into
which release of Windows (or patches) is not documented, again AFAIK.


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

SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada