apps built w/ -fstack-protector-all segfault

apps built w/ -fstack-protector-all segfault

[Peter S. Mazinger]

Hello!

gcc-4.1.20051105
-fno-stack-protector-all is not recognised/implemented

apps built w/ -fstack-protector-all segfault

test env:
- uClibc-svn
- guard is set up like glibc does in ld.so as non-TLS version
- libssp is not used, gcc's configure check was enabled to recognize 
__stack_chk_guard in uClibc

Peter

PS: please CC to me, not on list, thanks

-- 
Peter S. Mazinger <ps dot m at gmx dot net>           ID: 0xA5F059F2
Key fingerprint = 92A4 31E1 56BC 3D5A 2D08  BB6E C389 975E A5F0 59F2

Re: apps built w/ -fstack-protector-all segfault

[Jim Wilson]

Peter S. Mazinger wrote:
> -fno-stack-protector-all is not recognised/implemented

You could just submit this as a bug report into bugzilla.

> apps built w/ -fstack-protector-all segfault

You will have to give us more info.  Most gcc developers probably don't 
have a copy of UClibc, and plus it sounds like you have made gcc changes 
that weren't included in your message.  So there isn't much we can do 
here except ask for more details.  Try debugging the problem.  If you 
can identify a specific problem here, and give us details about it, we 
can probably help.
-- 
Jim Wilson, GNU Tools Support, http://www.specifix.com

Re: apps built w/ -fstack-protector-all segfault

[Eric Christopher]

>
>> apps built w/ -fstack-protector-all segfault
>
> You will have to give us more info.  Most gcc developers probably  
> don't have a copy of UClibc, and plus it sounds like you have made  
> gcc changes that weren't included in your message.  So there isn't  
> much we can do here except ask for more details.  Try debugging the  
> problem.  If you can identify a specific problem here, and give us  
> details about it, we can probably help.

Also since __builtin_trap is used in the fail mechanism the comment  
above the trap instruction in i386.md might be useful:

;; We used to use "int $5", in honor of #BR which maps to interrupt  
vector 5.
;; That, however, is usually mapped by the OS to SIGSEGV, which is often
;; caught for use by garbage collectors and the like.  Using an insn  
that
;; maps to SIGILL makes it more likely the program will rightfully die.
;; Keeping with tradition, "6" is in honor of #UD.

So you may be seeing something mapped odd, or...

-eric

Re: apps built w/ -fstack-protector-all segfault

[Peter S. Mazinger]

On Mon, 14 Nov 2005, Jim Wilson wrote:

> Peter S. Mazinger wrote:
> > -fno-stack-protector-all is not recognised/implemented
> 
> You could just submit this as a bug report into bugzilla.
> 
> > apps built w/ -fstack-protector-all segfault
> 
> You will have to give us more info.  Most gcc developers probably don't 
> have a copy of UClibc, and plus it sounds like you have made gcc changes 
> that weren't included in your message.  So there isn't much we can do 

sorry, the used gcc patches are those from 
http://buildroot.uclibc.org/cgi-bin/viewcvs.cgi/trunk/buildroot/toolchain/gcc/4.1.0/#dirlist 
(these are mostly needed due to gcc missing real uClibc support)

> here except ask for more details.  Try debugging the problem.  If you 

can't really tell what is going on. I can only say, that I am using the 
stack protector since gcc 3.3.x in conjunction w/ uClibc (the "original" 
version), and now that I wanted to test it with newer gcc I have modified 
the guard setup part in uClibc so that it can both use the old (<gcc-4) 
and the new (>=gcc-4) guard style and fail (I have mimiced here the glibc 
non-TLS version for __stack_chk_guard). With gcc-3.4.4 it works well (as 
earlier), but gcc-4 (I have backported even *_chk and the ssp stuff to 
4.0.2) fails.
I have really hoped that someone here can duplicate it in any environment 
(because if fno-stack-protector-all does not even exist, then this part of 
the code wasn't even tested)
There are 2 scenarios were it could behave the same:
1. Using newest glibc (2.3.6 is not enough), you need cvs, so it won't use 
libssp.so
2. Using any glibc in conjunction w/ libssp.so

> can identify a specific problem here, and give us details about it, we 
> can probably help.

what kind of details should I provide?

Thanks, Peter

-- 
Peter S. Mazinger <ps dot m at gmx dot net>           ID: 0xA5F059F2
Key fingerprint = 92A4 31E1 56BC 3D5A 2D08  BB6E C389 975E A5F0 59F2

Re: apps built w/ -fstack-protector-all segfault

[Peter S. Mazinger]

On Mon, 14 Nov 2005, Eric Christopher wrote:

> >
> >> apps built w/ -fstack-protector-all segfault
> >
> > You will have to give us more info.  Most gcc developers probably  
> > don't have a copy of UClibc, and plus it sounds like you have made  
> > gcc changes that weren't included in your message.  So there isn't  
> > much we can do here except ask for more details.  Try debugging the  
> > problem.  If you can identify a specific problem here, and give us  
> > details about it, we can probably help.
> 
> Also since __builtin_trap is used in the fail mechanism the comment  
> above the trap instruction in i386.md might be useful:

This is only true is libssp.so is used, I am using "established, working" 
exit code, that worked w/ earlier ssp as well (when it was not 
integrated) I mentioned that I use it as integrated into libc (exactly 
like glibc-cvs does), glibc uses libc_message iirc for exit.

this should also influence the -fstack-protector behaviour, but that seems 
to be OK.
__builtin_trap is used as I can see only if a vulnerability is found, this 
happens though on a simple hello world.

Thanks, Peter

> 
> ;; We used to use "int $5", in honor of #BR which maps to interrupt  
> vector 5.
> ;; That, however, is usually mapped by the OS to SIGSEGV, which is often
> ;; caught for use by garbage collectors and the like.  Using an insn  
> that
> ;; maps to SIGILL makes it more likely the program will rightfully die.
> ;; Keeping with tradition, "6" is in honor of #UD.
> 
> So you may be seeing something mapped odd, or...
> 
> -eric
> 
> 

-- 
Peter S. Mazinger <ps dot m at gmx dot net>           ID: 0xA5F059F2
Key fingerprint = 92A4 31E1 56BC 3D5A 2D08  BB6E C389 975E A5F0 59F2

Re: apps built w/ -fstack-protector-all segfault

[Eric Christopher]

>
> this should also influence the -fstack-protector behaviour, but  
> that seems
> to be OK.
> __builtin_trap is used as I can see only if a vulnerability is  
> found, this
> happens though on a simple hello world.

Aaah. You'll probably need to step through the program in a debugger  
then and find out where and why it segfaults.

-eric

Re: apps built w/ -fstack-protector-all segfault

[Peter S. Mazinger]

On Mon, 14 Nov 2005, Eric Christopher wrote:

> >
> > this should also influence the -fstack-protector behaviour, but  
> > that seems
> > to be OK.
> > __builtin_trap is used as I can see only if a vulnerability is  
> > found, this
> > happens though on a simple hello world.
> 
> Aaah. You'll probably need to step through the program in a debugger  
> then and find out where and why it segfaults.

app:
#include <stdio.h>

int main() {
	printf("Hello\n");
	return 0;
}

I don't really know gdb how to use, but
gdb run:
Program received signal SIGSEGV, Segmentation fault.
main () at tes.c:3
3	int main () {
>bt
#0 main () at tes.c:3

allowing it to core dump and running gdb against the core
#... 0x0000000 in ?? ()
finally
Error accessing memory address 0xc0000000: No such file or directory

The same built only w/ -fstack-protector is OK.

What else can I do to help finding the problem?

Apropos: there is another bug probably related to libssp.so use (does not 
influence the case here, due to __stack_chk_guard being in libc), it 
should write %{fstack-protector|fstack-protector-all: -lssp ....}, else for 
-fstack-protector-all it won't link against libssp.so

Thanks, Peter

-- 
Peter S. Mazinger <ps dot m at gmx dot net>           ID: 0xA5F059F2
Key fingerprint = 92A4 31E1 56BC 3D5A 2D08  BB6E C389 975E A5F0 59F2

Re: apps built w/ -fstack-protector-all segfault

[James E Wilson]

On Mon, 2005-11-14 at 22:45, Peter S. Mazinger wrote:
> I have really hoped that someone here can duplicate it in any environment 

In that case, I'd suggest creating a bugzilla bug report.  The gcc list
is really more of a self-help list for gcc developers.  If you want to
try to debug the problem yourself, we may be able to provide useful
advice.  If you want someone else to look at it, then just file a bug
report.  You may also want to report this to the uClibc developers. 
They are probably more interested in looking at this than the gcc
developers.

> (because if fno-stack-protector-all does not even exist, then this part of 
> the code wasn't even tested)

Isn't this the default?  I.e. no stack protection at all is what gcc
does by default.  So clearly this has been tested.  The only thing
missing is that we don't have an override option, so that you can say
-fstack-protector-all -fno-stack-protector-all and get the default
behaviour back.  If you meant something else, then you will need to
explain what you meant.
-- 
Jim Wilson, GNU Tools Support, http://www.specifix.com

Re: apps built w/ -fstack-protector-all segfault

[Peter S. Mazinger]

On Tue, 15 Nov 2005, James E Wilson wrote:

> On Mon, 2005-11-14 at 22:45, Peter S. Mazinger wrote:
> > I have really hoped that someone here can duplicate it in any environment 
> 
> In that case, I'd suggest creating a bugzilla bug report.  The gcc list
> is really more of a self-help list for gcc developers.  If you want to
> try to debug the problem yourself, we may be able to provide useful
> advice.  If you want someone else to look at it, then just file a bug

I wanted to only know if there is a configuration/scenario where this 
really worked. 

I would do the testing, I lack the needed gdb/other debug knowledge, if 
you would be so kind to guide me, I would try to get this working.

> report.  You may also want to report this to the uClibc developers. 
> They are probably more interested in looking at this than the gcc
> developers.

gcc-4.1-pre is "future" music, not even glibc's changes went into 2.3.6 to 
support these features ...

> 
> > (because if fno-stack-protector-all does not even exist, then this part of 
> > the code wasn't even tested)
> 
> Isn't this the default?  I.e. no stack protection at all is what gcc
> does by default.  So clearly this has been tested.  The only thing
> missing is that we don't have an override option, so that you can say
> -fstack-protector-all -fno-stack-protector-all and get the default
> behaviour back.  If you meant something else, then you will need to
> explain what you meant.

I meant exactly this, gcc supports -fno-stack-protector (although gcc 
defaults to no-ssp), so -fno-stack-protector-all should be there too

Peter

-- 
Peter S. Mazinger <ps dot m at gmx dot net>           ID: 0xA5F059F2
Key fingerprint = 92A4 31E1 56BC 3D5A 2D08  BB6E C389 975E A5F0 59F2

Re: apps built w/ -fstack-protector-all segfault

[James E Wilson]

On Tue, 2005-11-15 at 12:01, Peter S. Mazinger wrote:
> I wanted to only know if there is a configuration/scenario where this 
> really worked. 

I haven't been involved with the stack protector development or usage,
but as far as I know, it works unless some one reports a bug, and the
only bug I can recall seeing is yours.  Since the development work was
mostly done on linux systems with glibc, and you are using uClibc, it
isn't surprising that some additional work may be needed here.

> I would do the testing, I lack the needed gdb/other debug knowledge, if 
> you would be so kind to guide me, I would try to get this working.

First you try running a problem under gdb, getting a backtrace, then you
start looking at the source code to figure out why it failed at that
point.  The code, and any relevant libraries, need to be compiled with
-g.
-- 
Jim Wilson, GNU Tools Support, http://www.specifix.com

Re: apps built w/ -fstack-protector-all segfault

[Richard Henderson]

On Tue, Nov 15, 2005 at 09:01:21PM +0100, Peter S. Mazinger wrote:
> I meant exactly this, gcc supports -fno-stack-protector (although gcc 
> defaults to no-ssp), so -fno-stack-protector-all should be there too

Why?  What option would it perform?


r~

Re: apps built w/ -fstack-protector-all segfault

[Peter S. Mazinger]

On Wed, 16 Nov 2005, Richard Henderson wrote:

> On Tue, Nov 15, 2005 at 09:01:21PM +0100, Peter S. Mazinger wrote:
> > I meant exactly this, gcc supports -fno-stack-protector (although gcc 
> > defaults to no-ssp), so -fno-stack-protector-all should be there too
> 
> Why?  What option would it perform?

to have the possibility to override an earlier one, as it is done w/ many 
fno* options. Why should this one not have it's counterpart.

Ex. gcc does not default to fomit-frame-pointer, but we have 
fno-omit-frame-pointer

Peter 

-- 
Peter S. Mazinger <ps dot m at gmx dot net>           ID: 0xA5F059F2
Key fingerprint = 92A4 31E1 56BC 3D5A 2D08  BB6E C389 975E A5F0 59F2

Re: apps built w/ -fstack-protector-all segfault

[Richard Henderson]

On Wed, Nov 16, 2005 at 08:40:11PM +0100, Peter S. Mazinger wrote:
> On Wed, 16 Nov 2005, Richard Henderson wrote:
> 
> > On Tue, Nov 15, 2005 at 09:01:21PM +0100, Peter S. Mazinger wrote:
> > > I meant exactly this, gcc supports -fno-stack-protector (although gcc 
> > > defaults to no-ssp), so -fno-stack-protector-all should be there too
> > 
> > Why?  What option would it perform?
> 
> to have the possibility to override an earlier one, as it is done w/ many 
> fno* options. Why should this one not have it's counterpart.

There are three states we can be in:

  (0) no stack protection		-fno-stack-protector
  (1) heuristic stack protection	-fstack-protector
  (2) all stack protection		-fstack-protector-all

All of these three states have corresponding switches.  You can
use any of them at any time.

But what does -fno-stack-protector-all mean?  I claim it doesn't
mean anything at all, and is useless.  I claim you either wanted
-fstack-protector or -fno-stack-protector.


r~

Re: apps built w/ -fstack-protector-all segfault

[Peter S. Mazinger]

On Wed, 16 Nov 2005, Richard Henderson wrote:

> On Wed, Nov 16, 2005 at 08:40:11PM +0100, Peter S. Mazinger wrote:
> > On Wed, 16 Nov 2005, Richard Henderson wrote:
> > 
> > > On Tue, Nov 15, 2005 at 09:01:21PM +0100, Peter S. Mazinger wrote:
> > > > I meant exactly this, gcc supports -fno-stack-protector (although gcc 
> > > > defaults to no-ssp), so -fno-stack-protector-all should be there too
> > > 
> > > Why?  What option would it perform?
> > 
> > to have the possibility to override an earlier one, as it is done w/ many 
> > fno* options. Why should this one not have it's counterpart.
> 
> There are three states we can be in:
> 
>   (0) no stack protection		-fno-stack-protector
>   (1) heuristic stack protection	-fstack-protector
>   (2) all stack protection		-fstack-protector-all
> 
> All of these three states have corresponding switches.  You can
> use any of them at any time.

True for default configs. Let's consider though other distros like 
ubuntu/adamantix/gentoo that can default to "(2) all stack protection"
but sometimes, due to problems (mainly c++) -all has to be disabled. 
-fno-stack-protector would disable all the protection, that is not what 
would be needed.
 
> But what does -fno-stack-protector-all mean?  I claim it doesn't
> mean anything at all, and is useless.  I claim you either wanted
> -fstack-protector or -fno-stack-protector.

to illustrate how the above is currently done (specs, cc1)
%{!fno-stack-protector:-fstack-protector %{!fno-stack-protector-all:-fstack-protector-all}}

Peter

-- 
Peter S. Mazinger <ps dot m at gmx dot net>           ID: 0xA5F059F2
Key fingerprint = 92A4 31E1 56BC 3D5A 2D08  BB6E C389 975E A5F0 59F2

Re: apps built w/ -fstack-protector-all segfault

[Richard Henderson]

On Wed, Nov 16, 2005 at 10:02:23PM +0100, Peter S. Mazinger wrote:
> On Wed, 16 Nov 2005, Richard Henderson wrote:
> 
> > On Wed, Nov 16, 2005 at 08:40:11PM +0100, Peter S. Mazinger wrote:
> > > On Wed, 16 Nov 2005, Richard Henderson wrote:
> > > 
> > > > On Tue, Nov 15, 2005 at 09:01:21PM +0100, Peter S. Mazinger wrote:
> > > > > I meant exactly this, gcc supports -fno-stack-protector (although gcc 
> > > > > defaults to no-ssp), so -fno-stack-protector-all should be there too
> > > > 
> > > > Why?  What option would it perform?
> > > 
> > > to have the possibility to override an earlier one, as it is done w/ many 
> > > fno* options. Why should this one not have it's counterpart.
> > 
> > There are three states we can be in:
> > 
> >   (0) no stack protection		-fno-stack-protector
> >   (1) heuristic stack protection	-fstack-protector
> >   (2) all stack protection		-fstack-protector-all
> > 
> > All of these three states have corresponding switches.  You can
> > use any of them at any time.
> 
> True for default configs. Let's consider though other distros like 
> ubuntu/adamantix/gentoo that can default to "(2) all stack protection"
> but sometimes, due to problems (mainly c++) -all has to be disabled. 
> -fno-stack-protector would disable all the protection, that is not what 
> would be needed.

Use -fstack-protector to return to state (1).


r~

Re: apps built w/ -fstack-protector-all segfault

[Peter S. Mazinger]

On Wed, 16 Nov 2005, Richard Henderson wrote:

> On Wed, Nov 16, 2005 at 10:02:23PM +0100, Peter S. Mazinger wrote:
> > On Wed, 16 Nov 2005, Richard Henderson wrote:
> > 
> > > On Wed, Nov 16, 2005 at 08:40:11PM +0100, Peter S. Mazinger wrote:
> > > > On Wed, 16 Nov 2005, Richard Henderson wrote:
> > > > 
> > > > > On Tue, Nov 15, 2005 at 09:01:21PM +0100, Peter S. Mazinger wrote:
> > > > > > I meant exactly this, gcc supports -fno-stack-protector (although gcc 
> > > > > > defaults to no-ssp), so -fno-stack-protector-all should be there too
> > > > > 
> > > > > Why?  What option would it perform?
> > > > 
> > > > to have the possibility to override an earlier one, as it is done w/ many 
> > > > fno* options. Why should this one not have it's counterpart.
> > > 
> > > There are three states we can be in:
> > > 
> > >   (0) no stack protection		-fno-stack-protector
> > >   (1) heuristic stack protection	-fstack-protector
> > >   (2) all stack protection		-fstack-protector-all
> > > 
> > > All of these three states have corresponding switches.  You can
> > > use any of them at any time.
> > 
> > True for default configs. Let's consider though other distros like 
> > ubuntu/adamantix/gentoo that can default to "(2) all stack protection"
> > but sometimes, due to problems (mainly c++) -all has to be disabled. 
> > -fno-stack-protector would disable all the protection, that is not what 
> > would be needed.
> 
> Use -fstack-protector to return to state (1).

you missed the example earlier, or the behaviour of these 2 flags are not 
like they were earlier.

what happens w/ -fstack-protector-all -fstack-protector (in this order) ? 
do we have (2) or (1)
If the order is relevant then (1) will apply.

so now it does
-fstack-protector #define __SSP__ 1 ; #undef __SSP_ALL__
-fstack-protector-all #define __SSP_ALL__ 2 ; #undef __SSP__

and the last wins.

I think this is not quite correct, because -all is a 
superset of -fstack-protector, so it also should define __SSP__ 1

Peter

-- 
Peter S. Mazinger <ps dot m at gmx dot net>           ID: 0xA5F059F2
Key fingerprint = 92A4 31E1 56BC 3D5A 2D08  BB6E C389 975E A5F0 59F2

Re: apps built w/ -fstack-protector-all segfault

[Richard Henderson]

On Wed, Nov 16, 2005 at 10:32:45PM +0100, Peter S. Mazinger wrote:
> what happens w/ -fstack-protector-all -fstack-protector (in this order) ? 
> do we have (2) or (1)

We have 1.

> so now it does
> -fstack-protector #define __SSP__ 1 ; #undef __SSP_ALL__
> -fstack-protector-all #define __SSP_ALL__ 2 ; #undef __SSP__
> 
> and the last wins.

I don't know what you're looking at, but it isn't mainline.
The defines are not controled this way.


r~

Re: apps built w/ -fstack-protector-all segfault

[Peter S. Mazinger]

On Wed, 16 Nov 2005, Richard Henderson wrote:

> On Wed, Nov 16, 2005 at 10:32:45PM +0100, Peter S. Mazinger wrote:
> > what happens w/ -fstack-protector-all -fstack-protector (in this order) ? 
> > do we have (2) or (1)
> 
> We have 1.
> 
> > so now it does
> > -fstack-protector #define __SSP__ 1 ; #undef __SSP_ALL__
> > -fstack-protector-all #define __SSP_ALL__ 2 ; #undef __SSP__
> > 
> > and the last wins.
> 
> I don't know what you're looking at, but it isn't mainline.
> The defines are not controled this way.

The defines are exactly like this (only undef is not done, because the 
last wins)

so -fstack-protector -fstack-protector-all will have only __SSP_ALL__ 2
-fstack-protector-all -fstack-protector will have only __SSP__ 1

so in any case the last wins

-fstack-protector-all (all protection) being superset of -fstack-protector 
(random protection) it should also define __SSP__ 1

Peter

-- 
Peter S. Mazinger <ps dot m at gmx dot net>           ID: 0xA5F059F2
Key fingerprint = 92A4 31E1 56BC 3D5A 2D08  BB6E C389 975E A5F0 59F2

Re: apps built w/ -fstack-protector-all segfault

[Peter S. Mazinger]

On Thu, 17 Nov 2005, Peter S. Mazinger wrote:

> On Wed, 16 Nov 2005, Richard Henderson wrote:
> 
> > On Wed, Nov 16, 2005 at 10:32:45PM +0100, Peter S. Mazinger wrote:
> > > what happens w/ -fstack-protector-all -fstack-protector (in this order) ? 
> > > do we have (2) or (1)
> > 
> > We have 1.
> > 
> > > so now it does
> > > -fstack-protector #define __SSP__ 1 ; #undef __SSP_ALL__
> > > -fstack-protector-all #define __SSP_ALL__ 2 ; #undef __SSP__
> > > 
> > > and the last wins.
> > 
> > I don't know what you're looking at, but it isn't mainline.
> > The defines are not controled this way.
> 
> The defines are exactly like this (only undef is not done, because the 
> last wins)
> 
> so -fstack-protector -fstack-protector-all will have only __SSP_ALL__ 2
> -fstack-protector-all -fstack-protector will have only __SSP__ 1
> 
> so in any case the last wins
> 
> -fstack-protector-all (all protection) being superset of -fstack-protector 
> (random protection) it should also define __SSP__ 1

or maybe better, remove __SSP_ALL__ and define __SSP__ 2 for -all

Peter

-- 
Peter S. Mazinger <ps dot m at gmx dot net>           ID: 0xA5F059F2
Key fingerprint = 92A4 31E1 56BC 3D5A 2D08  BB6E C389 975E A5F0 59F2

Re: apps built w/ -fstack-protector-all segfault

[Richard Henderson]

On Thu, Nov 17, 2005 at 08:17:07AM +0100, Peter S. Mazinger wrote:
> -fstack-protector-all (all protection) being superset of -fstack-protector 
> (random protection) it should also define __SSP__ 1

The IBM patch that I followed did exactly what I implemented.
I see no compelling reason to change it.


r~