[MonetDB-users] stack protector error
Hello,
I get an error when trying to compile latest MonetDB default branch on my Ubuntu 10.04 64bit machine.
bootstrap: OK configure (../configure --prefix=/opt/MonetDB/ --enable-monetdb5 --enable-sql --enable-rdf --enable-geom --enable-bits=64 --enable-debug --enable-datacell): OK make -j2: ERROR
The error is: ../../gdk/gdk_batop.mx: In function ‘BATsetprop’: ../../gdk/gdk_batop.mx:2890: error: not protecting function: no buffer at least 8 bytes long
I think flags -fstack-protector-all and -Wstack-protector are to blame, they default to 8 bytes. I can skip the problem if I set 8 byte long dummy buffers to EVERY function that doesn't have such a buffer, e.g., char mybuf[8]; memset(buf, 0, sizeof(buf));
I also thought of setting the buffer size to 1, by passing --param spp-buffer-size=1 as a compiler option, but then I get various other errors.
gcc version: gcc (Ubuntu 4.4.3-4ubuntu5) 4.4.3 Copyright (C) 2009 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Mike
On 21-08-2011 17:04:52 +0300, Michael Sioutis wrote:
Hello,
I get an error when trying to compile latest MonetDB default branch on my Ubuntu 10.04 64bit machine.
bootstrap: OK configure (../configure --prefix=/opt/MonetDB/ --enable-monetdb5 --enable-sql --enable-rdf --enable-geom --enable-bits=64 --enable-debug --enable-datacell): OK make -j2: ERROR
The error is: ../../gdk/[1]gdk_batop.mx: In function ‘BATsetprop’: ../../gdk/[2]gdk_batop.mx:2890: error: not protecting function: no buffer at least 8 bytes long
I think flags -fstack-protector-all and -Wstack-protector are to blame, they default to 8 bytes. I can skip the problem if I set 8 byte long dummy buffers to EVERY function that doesn't have such a buffer, e.g., char mybuf[8]; memset(buf, 0, sizeof(buf));
I also thought of setting the buffer size to 1, by passing --param spp-buffer-size=1 as a compiler option, but then I get various other errors.
-fstack-protector-all should check everything.
I'd be interested to see your configure output.
I attached the configure output.
Mike
On Sun, Aug 21, 2011 at 5:45 PM, Fabian Groffen Fabian.Groffen@cwi.nlwrote:
On 21-08-2011 17:04:52 +0300, Michael Sioutis wrote:
Hello,
I get an error when trying to compile latest MonetDB default branch on my Ubuntu 10.04 64bit machine.
bootstrap: OK configure (../configure --prefix=/opt/MonetDB/ --enable-monetdb5 --enable-sql --enable-rdf --enable-geom --enable-bits=64 --enable-debug --enable-datacell): OK make -j2: ERROR
The error is: ../../gdk/[1]gdk_batop.mx: In function ‘BATsetprop’: ../../gdk/[2]gdk_batop.mx:2890: error: not protecting function: no
buffer at
least 8 bytes long
I think flags -fstack-protector-all and -Wstack-protector are to blame, they default to 8 bytes. I can skip the problem if I set 8 byte long dummy buffers to EVERY
function
that doesn't have such a buffer, e.g., char mybuf[8]; memset(buf, 0, sizeof(buf));
I also thought of setting the buffer size to 1, by passing --param spp-buffer-size=1 as a compiler option, but then I get various other errors.
-fstack-protector-all should check everything.
I'd be interested to see your configure output.
Get a FREE DOWNLOAD! and learn more about uberSVN rich system, user administration capabilities and model configuration. Take the hassle out of deploying and managing Subversion and the tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2 _______________________________________________ MonetDB-users mailing list MonetDB-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/monetdb-users
I passed --param ssp-buffer-size=2 as a compiler option and make went fine :) Configuring with --disable-strict also works, since a lot of flags are disabled.
I only have a warning about some opt_centiped file that could not be opened, and sth about datacell module that could not loaded, but other than that installation seems functional for simple operations.
I'm attaching the merovingian.log just in case.
I think for gcc >= 4.5 -fstack-protector-all, should be replaced by -fstack-protector, but I could be mistaken.
Mike
On Sun, Aug 21, 2011 at 6:06 PM, Fabian Groffen Fabian.Groffen@cwi.nlwrote:
On 21-08-2011 17:56:05 +0300, Michael Sioutis wrote:
I attached the configure output.
configure with --disable-strict, or update your Ubuntu machine.
Get a FREE DOWNLOAD! and learn more about uberSVN rich system, user administration capabilities and model configuration. Take the hassle out of deploying and managing Subversion and the tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2 _______________________________________________ MonetDB-users mailing list MonetDB-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/monetdb-users
On 21-08-2011 19:58:45 +0300, Michael Sioutis wrote:
I passed --param ssp-buffer-size=2 as a compiler option and make went fine :) Configuring with --disable-strict also works, since a lot of flags are disabled.
I only have a warning about some opt_centiped file that could not be opened, and sth about datacell module that could not loaded, but other than that installation seems functional for simple operations.
use the latest release branch (candidate): Aug2011, that's a lot safer
disable experimental features that you won't need anyway (don't --enable-datacell)
I'm attaching the merovingian.log just in case.
I think for gcc >= 4.5 -fstack-protector-all, should be replaced by -fstack-protector, but I could be mistaken.
We need to use -fstack-protector-all because some distributions (e.g. Ubuntu) have decided to enable -fstack-protector by default, and in that mode gcc will issue a warning when it won't protect a function because it is under the threshold of 8 bytes (which Ubuntu seems to have quietly altered as well), which with -Werror becomes a warning. Hence we need to force gcc protecting all functions, regardless whether or not they use the stack more than 8 bytes.
I found a good solution: compiler option -fno-stack-protector
Example: $ cat test.c #include <stdio.h>
int main(void) { char x[3]; return 0; }
$ gcc -o test test.c -fno-stack-protector -fstack-protector-all -Wstack-protector
$ hardening-check test test: Position Independent Executable: no, normal executable! Stack protected: yes <-- SUCCESS!!! Fortify Source functions: no, not found! Read-only relocations: yes Immediate binding: no, not found!
Whereas..
$ gcc -o test test.c -fstack-protector-all -Wstack-protector test.c: In function ‘main’: test.c:3: warning: not protecting function: no buffer at least 8 bytes long
$ hardening-check test test: Position Independent Executable: no, normal executable! Stack protected: no, not found! <-- You get a warning and NO success!!! Fortify Source functions: no, not found! Read-only relocations: yes Immediate binding: no, not found!
Think it's a gcc bug, -fstack-protector-all should oversubscribe default enabled -fstack-protector.
Mike
On Sun, Aug 21, 2011 at 8:07 PM, Fabian Groffen Fabian.Groffen@cwi.nlwrote:
On 21-08-2011 19:58:45 +0300, Michael Sioutis wrote:
I passed --param ssp-buffer-size=2 as a compiler option and make went
fine
:) Configuring with --disable-strict also works, since a lot of flags are disabled.
I only have a warning about some opt_centiped file that could not be
opened,
and sth about datacell module that could not loaded, but other than that installation seems functional for simple operations.
use the latest release branch (candidate): Aug2011, that's a lot safer
disable experimental features that you won't need anyway (don't --enable-datacell)
I'm attaching the merovingian.log just in case.
I think for gcc >= 4.5 -fstack-protector-all, should be replaced by -fstack-protector, but I could be mistaken.
We need to use -fstack-protector-all because some distributions (e.g. Ubuntu) have decided to enable -fstack-protector by default, and in that mode gcc will issue a warning when it won't protect a function because it is under the threshold of 8 bytes (which Ubuntu seems to have quietly altered as well), which with -Werror becomes a warning. Hence we need to force gcc protecting all functions, regardless whether or not they use the stack more than 8 bytes.
Get a FREE DOWNLOAD! and learn more about uberSVN rich system, user administration capabilities and model configuration. Take the hassle out of deploying and managing Subversion and the tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2 _______________________________________________ MonetDB-users mailing list MonetDB-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/monetdb-users
I thought this would make it to the hg bugfix log. -fno-stack-protector -fstack-protector-all seems like a nice flag combo.
It resolves the issue in Ubuntu, and it doesn't do any harm in other distros either, as far as I can tell.
Mike
On Sun, Aug 21, 2011 at 9:52 PM, Michael Sioutis papito.dit@gmail.comwrote:
I found a good solution: compiler option -fno-stack-protector
Example: $ cat test.c #include <stdio.h>
int main(void) { char x[3]; return 0; }
$ gcc -o test test.c -fno-stack-protector -fstack-protector-all -Wstack-protector
$ hardening-check test test: Position Independent Executable: no, normal executable! Stack protected: yes <-- SUCCESS!!! Fortify Source functions: no, not found! Read-only relocations: yes Immediate binding: no, not found!
Whereas..
$ gcc -o test test.c -fstack-protector-all -Wstack-protector test.c: In function ‘main’: test.c:3: warning: not protecting function: no buffer at least 8 bytes long
$ hardening-check test test: Position Independent Executable: no, normal executable! Stack protected: no, not found! <-- You get a warning and NO success!!! Fortify Source functions: no, not found! Read-only relocations: yes Immediate binding: no, not found!
Think it's a gcc bug, -fstack-protector-all should oversubscribe default enabled -fstack-protector.
Mike
On Sun, Aug 21, 2011 at 8:07 PM, Fabian Groffen Fabian.Groffen@cwi.nlwrote:
On 21-08-2011 19:58:45 +0300, Michael Sioutis wrote:
I passed --param ssp-buffer-size=2 as a compiler option and make went
fine
:) Configuring with --disable-strict also works, since a lot of flags are disabled.
I only have a warning about some opt_centiped file that could not be
opened,
and sth about datacell module that could not loaded, but other than that installation seems functional for simple operations.
use the latest release branch (candidate): Aug2011, that's a lot safer
disable experimental features that you won't need anyway (don't --enable-datacell)
I'm attaching the merovingian.log just in case.
I think for gcc >= 4.5 -fstack-protector-all, should be replaced by -fstack-protector, but I could be mistaken.
We need to use -fstack-protector-all because some distributions (e.g. Ubuntu) have decided to enable -fstack-protector by default, and in that mode gcc will issue a warning when it won't protect a function because it is under the threshold of 8 bytes (which Ubuntu seems to have quietly altered as well), which with -Werror becomes a warning. Hence we need to force gcc protecting all functions, regardless whether or not they use the stack more than 8 bytes.
Get a FREE DOWNLOAD! and learn more about uberSVN rich system, user administration capabilities and model configuration. Take the hassle out of deploying and managing Subversion and the tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2 _______________________________________________ MonetDB-users mailing list MonetDB-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/monetdb-users
On 27-08-2011 04:26:35 +0300, Michael Sioutis wrote:
I thought this would make it to the hg bugfix log. -fno-stack-protector -fstack-protector-all seems like a nice flag combo.
well, it might seem nice to you, but it is absolute non-sense to me.
It resolves the issue in Ubuntu, and it doesn't do any harm in other distros either, as far as I can tell.
Ubuntu should fix their compiler, which they did in their latest release (we test that one). If you don't want to upgrade, just forcibly use --disable-strict.
participants (2)
-
Fabian Groffen -
Michael Sioutis