[lsb-discuss] LSBCC and -fstack-protector

Mats Wichmann mats at wichmann.us
Thu Apr 14 14:13:58 UTC 2016

On 04/14/2016 06:01 AM, Dallman, John wrote:

> I'm tinkering with this on Fedora 23 with GCC 5.3 and the LSB 5.0 SDK. That version of lsbcc doesn't recognise the GCC I'm using, warns about it, and proceeds. Using -fstack-protector-strong with this combination works, and I can detect stack smashes in a simple example program.
> However, when I look at the command line, thus:
> $P_CC --lsb-verbose -fstack-protector-strong demonstrate_guardstack.c
> unrecognized gcc version: "5.3.1"
> cc -I /opt/lsb/include/libpng12 -isystem /opt/lsb/include -fstack-protector-strong demonstrate_guardstack.c -D__LSB_VERSION__=40 -nodefaultlibs -L /opt/lsb/lib64-4.0 -lpthread -lpthread_nonshared -Wl,--dynamic-linker=/lib64/ld-lsb-x86-64.so.3 -L /usr/lib/gcc/x86_64-redhat-linux/5.3.1 -Wl,-rpath-link,/opt/lsb/lib64-4.0 -L/lib64 -L/usr/lib64 -Wl,--hash-style=sysv -lgcc -lm -lc -lc_nonshared -lgcc
> I see that lsbcc is not emitting -fnostack-protector, and I'm suspicious that this is because it doesn't recognise the GCC and thus doesn't know if it should take precautions. Am I correct?
> The end-user customers for my products are getting more and more paranoid about security, and I suspect that in a few years, I'm going to have to use a -fstack-protector option, and if this is incompatible with LSB, I'll have to give up using LSB. What needs doing to make that option compatible with LSB?
> thanks,

it's something we'll have to look into.  Like I said, I don't quite
remember the details - my memory hints that there were some non-LSB
symbols emitted if you go the stack protector route, and they'd need to
make an appearance in an LSB version to be usable, if so.  It's not
technically a complex issue if that's the case, but logistically... will
there be an LSB update that could do this?  Anyway my memory on the
symbols could be wrong.  The __stack_chk_fail function does appear in
LSB since 4.0.

The somewhat more complicated issue is that the stack canary code messes
with the ABI, as it modifies the stack frame.

As to the technical question you raise above, I'm a little surprised at
the output, the dumb code that tries to make decisions based on gcc
version doesn't even know about gcc 5.x, and so avoids returning a value
indicating it's a gcc 4 compiler.  Of course it isn't a gcc 4, but that
check should really be gcc-4-or-later.

Any gcc5 compiler used with lsbcc is "uncharted waters".

More information about the lsb-discuss mailing list