|
|
Subscribe / Log in / New account

Rethinking the Stack Clash fix

Rethinking the Stack Clash fix

Posted Jul 14, 2017 0:45 UTC (Fri) by eru (subscriber, #2753)
Parent article: Rethinking the Stack Clash fix

How about doing it like in the bad old days of MS-DOS programming: have the compiler insert a stack overflow check at each function entry and into specials like alloca(), at least when compiling sensitive code. MS-DOS compilers did this because there was no other way to attempt memory protection, but the article gives the impression Linux actually is not so much better in this respect!

to post comments

Rethinking the Stack Clash fix

Posted Jul 14, 2017 1:06 UTC (Fri) by josh (subscriber, #17465) [Link]

The compiler has code to do exactly that, though it turns out that wasn't sufficient (see the various discussions about the compiler needing to probe each page).

But you also can't count on all of userspace using a reasonable compiler.

Rethinking the Stack Clash fix

Posted Jul 14, 2017 7:59 UTC (Fri) by mjw (subscriber, #16740) [Link] (2 responses)

See Jeff Law's GCC RFC patch set: https://gcc.gnu.org/ml/gcc-patches/2017-07/msg00556.html

This series introduces -fstack-check=clash which is a variant of
-fstack-check designed to prevent "jumping the stack" as seen in the
stack-clash exploits.

Rethinking the Stack Clash fix

Posted Jul 14, 2017 21:51 UTC (Fri) by eru (subscriber, #2753) [Link] (1 responses)

Sounds complicated. The old MS-DOS compilers just compared SP - required size against the stack limit before allocation. What is wrong with that?

Rethinking the Stack Clash fix

Posted Jul 14, 2017 22:16 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link]

Additional comparison - it's not free.


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds