delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin/2018/01/24/14:26:09

X-Recipient: archive-cygwin AT delorie DOT com
DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
:list-unsubscribe:list-subscribe:list-archive:list-post
:list-help:sender:subject:to:references:from:message-id:date
:mime-version:in-reply-to:content-type
:content-transfer-encoding; q=dns; s=default; b=HISJy65SHK1WPwgo
yLaeiCrMxYSB/JELOfA6xKr9RTcNwo+giC3jaEuw+R5J5EU/RCp4wC6KA6BiDGQ6
YkqKZFzYiHmJUQ3mY5f+ouYYmgmLi5EUeHKxRvAX9QXzbwzDOtVi9OOcELmMUzlQ
dBbHz/JfEre/d4kv+qaEdbbrAqk=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id
:list-unsubscribe:list-subscribe:list-archive:list-post
:list-help:sender:subject:to:references:from:message-id:date
:mime-version:in-reply-to:content-type
:content-transfer-encoding; s=default; bh=DDzg5UqxwwqWxAhprz4Wbc
qb9Sc=; b=Gs+yG5Z6iZUe43shw8VeSOT79Ewf7A8TUSaTzSGsiIO5yy4KWKDlJG
n8A4qHbDfuR2WgEThBSZuOU+UAm+UWUToU2seNqEKmwV0Q2TP/4mPpgGGpBljvVc
Ss0E8VBhvk2VGTYl/2vt2vfIVtGc4UF+Qhl4L6vTQzZUbu3yQM+pg=
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id: <cygwin.cygwin.com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
Authentication-Results: sourceware.org; auth=none
X-Virus-Found: No
X-Spam-SWARE-Status: No, score=-10.6 required=5.0 tests=AWL,BAYES_00,GIT_PATCH_2,GIT_PATCH_3,KAM_NUMSUBJECT,SPF_HELO_PASS,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy=CONTENTS
X-HELO: limerock03.mail.cornell.edu
X-CornellRouted: This message has been Routed already.
Subject: Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.10.0-0.1
To: cygwin AT cygwin DOT com
References: <announce DOT 20180116155108 DOT GA9503 AT calimero DOT vinschen DOT de> <9990d909-f112-9658-1b0f-d63e3f338a18 AT cornell DOT edu> <4f7edc68-4c98-8fa3-9fef-47bdd3343330 AT cornell DOT edu> <3b738a06-a3b8-210b-2886-4c9701efcd48 AT cygwin DOT com> <eb4e6cf2-12aa-bb4c-738e-f2259f58f3fe AT cornell DOT edu> <c5a92ae1-3b63-0227-f170-fa1d0ac959eb AT cornell DOT edu> <39045e32-8a2c-c767-0fcd-27d544ba6d93 AT cornell DOT edu> <e8cdfc99-bcad-eb80-ec48-9e1bdefbe69d AT cornell DOT edu>
From: Ken Brown <kbrown AT cornell DOT edu>
Message-ID: <5769e163-8716-23b3-520e-dbae6faaa84a@cornell.edu>
Date: Wed, 24 Jan 2018 14:25:51 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2
MIME-Version: 1.0
In-Reply-To: <e8cdfc99-bcad-eb80-ec48-9e1bdefbe69d@cornell.edu>
X-PMX-Cornell-Gauge: Gauge=XX
X-PMX-CORNELL-AUTH-RESULTS: dkim-out=none;
X-IsSubscribed: yes
Note-from-DJ: This may be spam 

On 1/20/2018 6:49 PM, Ken Brown wrote:
> On 1/20/2018 7:23 AM, Ken Brown wrote:
>> On 1/19/2018 10:27 PM, Ken Brown wrote:
>>> On 1/18/2018 6:28 PM, Ken Brown wrote:
>>>> On 1/18/2018 4:30 PM, Yaakov Selkowitz wrote:
>>>>> On 2018-01-18 08:35, Ken Brown wrote:
>>>>>> On 1/17/2018 5:29 PM, Ken Brown wrote:
>>>>>>> Do we need a new gcc release to go along with the recent ssp 
>>>>>>> changes?
>>>>>>
>>>>>> The following commit message seems to answer my question:
>>>>>>
>>>>>>      Note that this does require building gcc with 
>>>>>> --disable-libssp and
>>>>>>      gcc_cv_libc_provides_ssp=yes.
>>>>>
>>>>> Correct.
>>>>>
>>>>>> Are there plans to coordinate the release of Cygwin 2.10.0 with a new
>>>>>> gcc release?  In the meantime, I guess package maintainers have to 
>>>>>> build
>>>>>> with -U_FORTIFY_SOURCE in order to test building with Cygwin 
>>>>>> 2.10.0.  Or
>>>>>> am I missing something?
>>>>>
>>>>> -D_FORTIFY_SOURCE is not the default, so simply omitting it is
>>>>> sufficient.
>>>>
>>>> I was talking about building projects in which _FORTIFY_SOURCE is 
>>>> defined by default.  That happens, for instance, in the gnulib 
>>>> subdirectory of the emacs tree, so it may affect other projects that 
>>>> use gnulib also.
>>>>
>>>>> You could also just delete
>>>>> /usr/lib/gcc/*-pc-cygwin/6.4.0/include/ssp, since we won't need it
>>>>> anymore and it wasn't even being used properly in the first place.
>>>>
>>>> That's a simpler workaround than what I was doing.  Thanks.
>>>
>>> Here's another issue that's come up with _FORTIFY_SOURCE.  One of the 
>>> emacs source files, fileio.c, makes use of a pointer to readlinkat. 
>>> [More precisely, the file uses an external function foo() with a 
>>> parameter 'bar' that's a pointer to a function; foo is called in 
>>> fileio.c with bar = readlinkat.]
>>>
>>> When _FORTIFY_SOURCE > 0, this leads to an "undefined reference to 
>>> `__ssp_protected_readlinkat'" linking error.  Does this sound like 
>>> something that will be fixed with the new gcc release?
>>>
>>> I realize I haven't given you full details, but it might be a few 
>>> days until I have a chance to extract an STC for this issue, so I 
>>> thought I'd give it a shot.
>>>
>>> If you can't answer the question based on the information above, I'll 
>>> make an STC as soon as I can.
>>
>> I got to this sooner than expected:
>>
>> $ cat ssp_test.c
>> #define  _FORTIFY_SOURCE 1
>> #include <unistd.h>
>> void foo (ssize_t (*preadlinkat) (int, char const *, char *, size_t));
>>
>> void baz ()
>> {
>>    foo (readlinkat);
>> }
>>
>> $ gcc -c -O1 ssp_test.c
>>
>> $ objdump -x ssp_test.o | grep readlinkat
>>    6 .rdata$.refptr.__ssp_protected_readlinkat 00000010 
>> 0000000000000000  0000000000000000  00000180  2**4
>> [...]

The following patch seems to fix the problem:

--- ssp.h~      2018-01-22 09:18:18.000000000 -0500
+++ ssp.h       2018-01-24 13:44:55.856635800 -0500
@@ -41,7 +41,7 @@
 #endif
 #define __ssp_real(fun)                __ssp_real_(fun)

-#define __ssp_inline extern __inline__ __attribute__((__always_inline__, __gnu_inline__))
+#define __ssp_inline extern __inline__ __attribute__((__always_inline__))

 #define __ssp_bos(ptr) __builtin_object_size(ptr, __SSP_FORTIFY_LEVEL > 1)
 #define __ssp_bos0(ptr) __builtin_object_size(ptr, 0)

I arrived at this by comparing Cygwin's ssp.h with NetBSD's, on which
Cygwin's was based, and I noticed that NetBSD didn't use __gnu_inline__.
Yaakov, is there a reason that Cygwin needs __gnu_inline__?  It apparently
prevents fortified functions from being used as function pointers.

Using my test case again, here's what happens with and without __gnu_inline__:

With:
$ gcc -O1 -c ssp_test.c && objdump -x ssp_test.o | grep readlinkat
  6 .rdata$.refptr.__ssp_protected_readlinkat 00000010  0000000000000000  0000000000000000  00000180  2**4
                  CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA, LINK_ONCE_DISCARD (COMDAT .refptr.__ssp_protected_readlinkat 18)
[  4](sec  7)(fl 0x00)(ty   0)(scl   3) (nx 1) 0x0000000000000000 .rdata$.refptr.__ssp_protected_readlinkat
[ 18](sec  7)(fl 0x00)(ty   0)(scl   2) (nx 0) 0x0000000000000000 .refptr.__ssp_protected_readlinkat
[ 19](sec  0)(fl 0x00)(ty   0)(scl   2) (nx 0) 0x0000000000000000 __ssp_protected_readlinkat
0000000000000007 R_X86_64_PC32     __ssp_protected_readlinkat
RELOCATION RECORDS FOR [.rdata$.refptr.__ssp_protected_readlinkat]:
0000000000000000 R_X86_64_64       __ssp_protected_readlinkat

Without:
$ gcc -O1 -c ssp_test.c && objdump -x ssp_test.o | grep readlinkat
[  2](sec  1)(fl 0x00)(ty  20)(scl   2) (nx 1) 0x0000000000000000 __ssp_protected_readlinkat
[ 27](sec  0)(fl 0x00)(ty   0)(scl   2) (nx 0) 0x0000000000000000 readlinkat
0000000000000005 R_X86_64_PC32     readlinkat

Ken

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019