"Strong" stack protection for GCC [LWN.net]

"Strong" stack protection for GCC

Posted Feb 7, 2014 15:04 UTC (Fri) by jzbiciak (guest, #5246)
In reply to: "Strong" stack protection for GCC by jzbiciak
Parent article: "Strong" stack protection for GCC

And on machines whose stack grows down, if you have anything that fills a buffer in reverse (it happens, but it's admittedly far less common), you could do the same there.

to post comments

"Strong" stack protection for GCC

Posted Feb 9, 2014 19:05 UTC (Sun) by eru (subscriber, #2753) [Link] (1 responses)

if you have anything that fills a buffer in reverse (it happens, but it's admittedly far less common), you could do the same there.

You could have two canaries: the second one is at the opposite end of the stack frame. A colleague actually added this feature to an in-house C compiler. The run-time system then reports which canary got killed. This was done to help catch programming errors, not so much for security.

"Strong" stack protection for GCC

Posted Feb 9, 2014 20:21 UTC (Sun) by jzbiciak (guest, #5246) [Link]

I'm not sure why that didn't occur to me here, as I've actually done the same in my own debugging infrastructure.

For example, in our DSP assembly kernel test benches, we actually went further than keeping a single canary word. We actually kept a sizeable buffer zone ahead of and behind the "live" data in the test bench, since some DSP algorithms write results separated by particular stride. (Think column accesses in a 2-D array for one common class.) I also wrote a "dmalloc" wrapper that put pad at both ends as well. Of course, that was all back in the 90s, when writing large amounts of assembly code for DSPs was much more commonplace.

But, as you said, it was more for catching programming errors than for preventing security exploits.