I originally learned about it and other issues in a paper by the people (Schell &amp; Karger) that invented INFOSEC:<p><a href="https:&#x2F;&#x2F;www.acsac.org&#x2F;2002&#x2F;papers&#x2F;classic-multics.pdf" rel="nofollow">https:&#x2F;&#x2F;www.acsac.org&#x2F;2002&#x2F;papers&#x2F;classic-multics.pdf</a><p>Really old stuff. Relevant quote: &quot;Third, stacks on the Multics processors grew in the positive direction... if you actually accomplished a buffer overflow, you would be overwriting unused stack frames rather than your own return pointer, making exploitation much more difficult.&quot;<p>I can&#x27;t find the original paper showing the penalty on x86&#x2F;Linux. However, this one does the same thing for different reasons with many details:<p><a href="http:&#x2F;&#x2F;babaks.com&#x2F;files&#x2F;TechReport07-07.pdf" rel="nofollow">http:&#x2F;&#x2F;babaks.com&#x2F;files&#x2F;TechReport07-07.pdf</a><p>Key point: &quot;The direction of stack growth is not flexible in hardware and almost all processors only support one direction. For example, in Intel x86 processors, the stack always grows downward and all the stack manipulation instructions such as push and pop are designed for this natural growth.&quot;<p>So, on such an architecture, you can&#x27;t directly use the stack operations to do the job: must implement extra instructions without hardware acceleration. The stack on x86 is effed-up and insecure by design. If C&#x27;s stack is fixed, there&#x27;s still a mismatch between it and x86 ASM. Itanium at least provided stack protection among other security benefits.