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". _______________________________________________ lsb-discuss mailing list [email protected] https://lists.linuxfoundation.org/mailman/listinfo/lsb-discuss
