All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alban Gruin <alban.gruin@gmail.com>
To: Johannes Schindelin <Johannes.Schindelin@gmx.de>,
	Johannes Sixt <j6t@kdbg.org>
Cc: "İsmail Dönmez" <ismail@i10z.com>,
	"İsmail Dönmez via GitGitGadget" <gitgitgadget@gmail.com>,
	git@vger.kernel.org, "Junio C Hamano" <gitster@pobox.com>
Subject: Re: [PATCH 2/2] mingw: enable DEP and ASLR
Date: Wed, 1 May 2019 20:39:22 +0200	[thread overview]
Message-ID: <2e7be484-74d7-7258-954e-3a4a34a36c01@gmail.com> (raw)
In-Reply-To: <nycvar.QRO.7.76.6.1904301838400.45@tvgsbejvaqbjf.bet>

Hi Johannes,

Le 01/05/2019 à 00:41, Johannes Schindelin a écrit :
> Hi Hannes,
> 
> On Tue, 30 Apr 2019, Johannes Sixt wrote:
> 
>> [had to add Dscho as recipient manually, mind you]
> 
> I usually pick up responses to GitGitGadget patch series even if I am not
> on explicit Cc: (but it might take a couple of days when I am too busy
> elsewhere to read the Git mailing list).
> 
>> Am 29.04.19 um 23:56 schrieb İsmail Dönmez via GitGitGadget:
>>> From: =?UTF-8?q?=C4=B0smail=20D=C3=B6nmez?= <ismail@i10z.com>
>>>
>>> Enable DEP (Data Execution Prevention) and ASLR (Address Space Layout
>>> Randomization) support. This applies to both 32bit and 64bit builds
>>> and makes it substantially harder to exploit security holes in Git by
>>> offering a much more unpredictable attack surface.
>>>
>>> ASLR interferes with GDB's ability to set breakpoints. A similar issue
>>> holds true when compiling with -O2 (in which case single-stepping is
>>> messed up because GDB cannot map the code back to the original source
>>> code properly). Therefore we simply enable ASLR only when an

I don’t know if it stands true when combined with something like -ggdb3,
but I may be very wrong.  Feel free to correct me.

>>> optimization flag is present in the CFLAGS, using it as an indicator
>>> that the developer does not want to debug in GDB anyway.
>>>
>>> Signed-off-by: İsmail Dönmez <ismail@i10z.com>
>>> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
>>> ---
>>>  config.mak.uname | 6 ++++++
>>>  1 file changed, 6 insertions(+)
>>>
>>> diff --git a/config.mak.uname b/config.mak.uname
>>> index e7c7d14e5f..a9edcc5f0b 100644
>>> --- a/config.mak.uname
>>> +++ b/config.mak.uname
>>> @@ -570,6 +570,12 @@ else
>>>  	ifeq ($(shell expr "$(uname_R)" : '2\.'),2)
>>>  		# MSys2
>>>  		prefix = /usr/
>>> +		# Enable DEP
>>> +		BASIC_LDFLAGS += -Wl,--nxcompat
>>> +		# Enable ASLR (unless debugging)
>>> +		ifneq (,$(findstring -O,$(CFLAGS)))
>>> +			BASIC_LDFLAGS += -Wl,--dynamicbase
>>> +		endif
>>>  		ifeq (MINGW32,$(MSYSTEM))
>>>  			prefix = /mingw32
>>>  			HOST_CPU = i686
>>>
>>
>> I'm a bit concerned that this breaks my debug sessions where I use -O0.
>> But I'll test without -O0 before I really complain.
> 
> Weird. Jameson Miller also mentioned this very concern in an internal
> review.
> 
> I guess I'll do something like
> 
> 	ifneq (,$(findstring -O,$(filter-out -O0,$(CFLAGS))))
> 

-Og also exists to debug[0], even if it’s far less known.  Perhaps it’s
better to check for -g (and its variants[1]) as the user clearly states
their intent to debug the resulting binary, rather than checking for
special cases.

> Does that work for you?
> 
> Ciao,
> Dscho
> 

[0] https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html#index-Og
[1] https://gcc.gnu.org/onlinedocs/gcc/Debugging-Options.html

Cheers,
Alban


  parent reply	other threads:[~2019-05-01 18:39 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-29 21:56 [PATCH 0/2] Enable Data Execution Protection and Address Space Layout Randomization on Windows Johannes Schindelin via GitGitGadget
2019-04-29 21:56 ` [PATCH 1/2] mingw: do not let ld strip relocations İsmail Dönmez via GitGitGadget
2019-04-29 21:56 ` [PATCH 2/2] mingw: enable DEP and ASLR İsmail Dönmez via GitGitGadget
2019-04-30  6:26   ` Johannes Sixt
2019-04-30 22:41     ` Johannes Schindelin
2019-04-30 22:59       ` Johannes Sixt
2019-05-01 18:39       ` Alban Gruin [this message]
2019-05-01 23:36         ` brian m. carlson
2019-05-08 11:33           ` Johannes Schindelin
2019-05-08 11:33         ` Johannes Schindelin
2019-05-01 20:46       ` Jeff King
2019-05-01 22:02         ` Jonathan Nieder
2019-05-08 11:27           ` Johannes Schindelin
2019-05-08 11:30 ` [PATCH v2 0/2] Enable Data Execution Protection and Address Space Layout Randomization on Windows Johannes Schindelin via GitGitGadget
2019-05-08 11:30   ` [PATCH v2 1/2] mingw: do not let ld strip relocations İsmail Dönmez via GitGitGadget
2019-05-08 11:30   ` [PATCH v2 2/2] mingw: enable DEP and ASLR İsmail Dönmez via GitGitGadget

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2e7be484-74d7-7258-954e-3a4a34a36c01@gmail.com \
    --to=alban.gruin@gmail.com \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=git@vger.kernel.org \
    --cc=gitgitgadget@gmail.com \
    --cc=gitster@pobox.com \
    --cc=ismail@i10z.com \
    --cc=j6t@kdbg.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.