RE: [gentoo-hardened] SSP + setjmp() = badness?

[Richard Hansen]

Kevin F. Quinn <mailto:kevquinn@g.o> wrote:
> On Sat, 29 Jul 2006 17:37:03 -0400
> "Richard Hansen" <gentoo-a7x@×××××××××××.org> wrote:
>> After spending hours with gdb, I believe I have narrowed down the
>> problem to a setjmp() call in the Wireshark code.  That call seems to
>> be trashing the stack, based on comparing local variable values
>> before and after the call.  Is this a known limitation of SSP, or
>> should setjmp() work with SSP?
>
> Well, the setjmp() connection is new, but we do know that SSP in
> gcc-3.x sometimes generates bad code, and that sometimes gcc-3.x
> generates bad code regardless of SSP (where enabling SSP just causes
> the error to be detected -see bug #133301 for an example). However we
> haven't yet worked out what's going on.  It would be worth building
> Wireshark with SSP off and running gdb in the same way you did before,
> breaking at the same place, to see if the same local variables are
> corrupted or not when SSP is disabled.

According to my gdb tests, the stack is not corrupted when SSP is disabled.

I'm not sure how SSP alters the layout of the stack, but considering setjmp() and longjmp() are written in assembly, it makes sense that they would trash the stack when SSP is turned on.  However, I would expect the SSP patch to include updated versions of setjmp() and longjmp() to accommodate the changes to the stack...  Is this not the case?

Is there an official web page or mailing list for the SSP patch?

Thanks,
Richard


-- 
gentoo-hardened@g.o mailing list