Preventing stack guard-page hopping

Posted Jun 19, 2017 21:45 UTC (Mon) by roc (subscriber, #30627)
In reply to: Preventing stack guard-page hopping by roc
Parent article: Preventing stack guard-page hopping

Anyway, the important thing is that the overhead of inserting stack page probes should be pretty low compared to what's been measured for -fstack-check in the past.

Preventing stack guard-page hopping

Posted Jun 19, 2017 23:31 UTC (Mon) by nix (subscriber, #2304) [Link]

It's not even one byte per page. It's one byte per page for all pages but the last. (So nearly all functions need no probe at all, and the ones that do will probably be fairly slow monsters anyway.)

Preventing stack guard-page hopping

Posted Jun 20, 2017 18:54 UTC (Tue) by dd9jn (✭ supporter ✭, #4459) [Link] (1 responses)

If my memory serves me right, the OS/2 compilers inserted stack probes by default --- more than 25 years ago. I am baffled to learn that gcc doesn't default to this simple robustness feature. (Fortunately I am in the habit of avoiding alloca or possible large stack reservations.)

Preventing stack guard-page hopping

Posted Jun 22, 2017 22:02 UTC (Thu) by cesarb (subscriber, #6266) [Link]

From what I understand of what I've read on Raymond Chen's blog, Windows compilers must insert stack probes, since the stack will only grow if the guard page is hit (https://blogs.msdn.microsoft.com/oldnewthing/20060927-07/...); Linux seems to be able to grow the stack for a hit anywhere in the stack VMA. OS/2 is probably similar to Windows, so its compilers must also implement stack probing.