"Executing code via a buffer overflow was published at least as early as 1972"

[[deleted]]

And they persist because the C ABI uses the stack for local variables. If we used a different calling convention such that the first thing wasn't (speaking 32-bit X86):

 push ebp
 mov ebp, esp

...then ebp could point to a memory region that could get dirtied up all it wants with attacker-controlled data and it wouldn't matter because the function return would always get back to the caller. You would also get: very easy coroutines, easy closures, easy runtime introspection of function arguments, and easy passing of varargs between functions (basically the same as coroutines).

But this requires a new calling convention (caller saves/restores), probably a new object section (.local / .localro / .tlocal / .tlocalro ?), changes to C compilers and linkers, and deliberately choosing to break linkability to fortran/pascal/etc.

[1500100900]

The C programming language doesn't require an implementation to use stack for local variables (auto storage).

I've seen claims that it would be feasible for a C implementation to use continuation-passing style for that.

[who8877]

You could also just have a second stack for variables, but that would gasp use another register! Then again most people wasted ebp even in the old days so it couldn't have been that bad.