Bug to track C++ problems with the SSP we add to gcc-3.x The SSP implementation we add to gcc-3.x does not like data declared elsewhere than in the initial declaration section of a function, which is legal in C++ but not in C. Definitely the issue on 133301, likely also for 115237 and probably 136891 and 101776.
Would backing off on the -all option for CXX be ideal?
I don't think so, as -all will just reduce the likelihood of it being hit. By how much is difficult to say as it depends on how often sweep-able variables occur in the same functions as the declarations that trigger the bug.
Regarding the dep'd bugs that are Qt specific: The users have noted that the breakage occurs in 3.3.6 but NOT in 3.3.4. I viewed the source for two of the bugs in question and the source hasn't changed between these versions (ie, the creation of a stack variable within a subblock of a function exists exactly the same in both versions). What else could be the cause then? Could some kind of bad cflags possibly be the culprit? Perhaps the buildsystem mechanisms changed between 3.3.4 and 3.3.6 and we just haven't caught it yet.
(In reply to comment #3) > The users have noted that the breakage occurs in 3.3.6 but NOT in 3.3.4. Yeah, I noticed that. The difficulty is in knowing how the issue is triggered. I'm inclined to believe it is down to context; perhaps the data passed into the function is different in size for example. Changes elsewhere in the code could cause the fault to become visible. Note that the stack smash only occurs if the canary is overwritten - perhaps whatever data is being written doesn't quite reach the canary. SSP does play significantly with the stack layout; it duplicates parameters and re-orders locally declared data to arrange to have any buffers located after the scalar data, so that buffer overflows won't corrupt the scalar data and are more likely to hit the canary. It should be detectable by comparing the asm output from the function with the declaration in each place; I'm building some stuff at the moment to investigate.
re 133301 - seems SSP isn't causing the problem, just highlighting it (see comments there). I think it'll be worth investigating the other bugs further, see if they're the same.
all these bugs remind on one that solar gave me some 2-3 years ago, a few lines of c++ that crashed when compiled with SSP. i had spent a whole day of debugging what turned out to be a function prologue code generation bug in SSP and these bugs look very similar to that, maybe an angle to pursue... the next question is then, how are you going to fix it? that old bug was never addressed by Etoh (even though we gave him all the details) and i doubt he'd touch SSP these days again.
i think bug 133092 belongs here as well.
I think bind in bug 158664 also suffer some kind of strange interaction with SSP.
*** Bug 192564 has been marked as a duplicate of this bug. ***
https://hardened.gentooexperimental.org/secure/ Dw.
GCC 4.3.4 is stable on hardened. All tracked bugs closed in one form or another. GCC 3.4.x is frozen/not being worked on. Closing as WONTFIX.
For anyone looking to solve this bug 302534 may be of particular interest.
