On Tue, Jan 29, 2008 at 11:45:32PM +0100, Pierre Habouzit wrote: > * SSP has a cost proportional to the number of calls an application > performs (If I'm correct), which in CPU intensive tasks may become an > issue.
In testing I've done, this is trivial overhead. Note that the extra code is only generated for functions with >8 byte of stack. (-fstack-protector-all is for doing _all_ functions, which doesn't make any sense.) > * FORTITY_SOURCES=2 checks memcpy and memmove, though other functions it > checks should just not be used and applications beeing too slow > because of them should just be shot down. I still haven't found a comprehensive list of what -D_FORTIFY_SOURCE does, and at which levels various features are enabled. I've dug up various bits and pieces, but I'd love to see a pointer to good documentation. Without that, I suspect attempting to develop a reasonable test workload is bound to miss certain things. > * PIE is just IMHO not an option on x86 :/ I disagree here -- the bulk of applications tend to use shared libraries, and those are all PIC. I have a hard time believing that adding the same relocation overhead for the main program is an issue. Of course, without numbers, we're all just waving our arms. :) > Though probably someone should come up with some benchmarks. The usual > culprits (multimedia libraries, html renderers, xml processors, …) all > provide easily deployed bench, and before we go any further I'd like to > see some numbers. Does anyone have any good test harnesses we can try this on? I'd be more than happy to run them on some modern hardware. -Kees -- Kees Cook -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]