X-Recipient: archive-cygwin AT delorie DOT com
X-Original-To: cygwin AT cygwin DOT com
Delivered-To: cygwin AT cygwin DOT com
DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 1363B3858004
Authentication-Results: sourceware.org;
 dmarc=none (p=none dis=none) header.from=nexgo.de
Authentication-Results: sourceware.org;
 spf=pass smtp.mailfrom=Stromeko AT nexgo DOT de
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nexgo.de;
 s=vfde-smtpout-mb-15sep; t=1614580974;
 bh=Yn5beIwJ4KZg9d/I4SAut0eTE1yf60SslyCSX3j7cus=;
 h=From:To:Subject:References:Date:In-Reply-To;
 b=TuJ31KkWqf2T2Sve1ToZH3lQ5ctJXhksQYKniDdvwZACMRSVcylKwh+K4OV3Jp5Mx
 +auIwdnBq77GjmrO5S2bIeb82ZEI9+5kPj/DNTE5fnFx0qTZyImdlxBVgCUMC3k+56
 3+FtvV6f3dppsqUtkwfOpOxiaizafeVgzv9xjNvE=
From: ASSI <Stromeko AT nexgo DOT de>
To: cygwin AT cygwin DOT com
Subject: Re: cygwin + binutils 2.36 + ASLR/dynamicbase defaults
References: <CAE6_+UewLqP2Tf5FphSqzG21_P-AnXdBjZ+-5-LwJy5n4fXMqg AT mail DOT gmail DOT com>
 <87zgzo9zpa DOT fsf AT Otto DOT invalid>
 <alpine DOT BSO DOT 2 DOT 21 DOT 2102281958220 DOT 9707 AT resin DOT csoft DOT net>
Date: Mon, 01 Mar 2021 07:42:40 +0100
In-Reply-To: <alpine.BSO.2.21.2102281958220.9707@resin.csoft.net> (Jeremy
 Drake via Cygwin's message of "Sun, 28 Feb 2021 20:16:56 -0800 (PST)")
Message-ID: <87mtvn9xy7.fsf@Otto.invalid>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux)
MIME-Version: 1.0
X-purgate-type: clean
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate: This mail is considered clean (visit http://www.eleven.de for
 further information)
X-purgate: clean
X-purgate-size: 2822
X-purgate-ID: 155817::1614580974-000006DE-E9BDF89B/0/0
X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00, DKIM_SIGNED,
 DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H2,
 SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2
X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on
 server2.sourceware.org
X-BeenThere: cygwin AT cygwin DOT com
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: General Cygwin discussions and problem reports <cygwin.cygwin.com>
List-Unsubscribe: <https://cygwin.com/mailman/options/cygwin>,
 <mailto:cygwin-request AT cygwin DOT com?subject=unsubscribe>
List-Archive: <https://cygwin.com/pipermail/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-request AT cygwin DOT com?subject=help>
List-Subscribe: <https://cygwin.com/mailman/listinfo/cygwin>,
 <mailto:cygwin-request AT cygwin DOT com?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: cygwin-bounces AT cygwin DOT com
Sender: "Cygwin" <cygwin-bounces AT cygwin DOT com>

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
--
Problem reports:      https://cygwin.com/problems.html
FAQ:                  https://cygwin.com/faq/
Documentation:        https://cygwin.com/docs.html
Unsubscribe info:     https://cygwin.com/ml/#unsubscribe-simple