This NX bit is a long waited hardware feature in the x86 platform. Sun Solaris developers needed a similar way of avoiding stack overflows due to arbitrary code execution. The solution was partially addressed in the Sun UltraSparc architecture with the introduction of an optional flag that could mark the stack as no executable [uwaterloo.ca]. Additionally even the unsuccessfull attempts to break this protection could be logged for further investigation.
At first this flag was disabled by default because it was not comply with SPARCv8 ABI so some (mainly bad coded) applications that relied on the execution of code inside the stack could not run as expected. Sun collaborated with its huge community of developers to address [sun.com]some collateral effects and once resolved Sun published the new SPARCv9 ABI reference guide in which the stack is no longer mapped as executable.
Currently 64-bit Solaris applications running on SPARC [sparc.org] don't need to worry about exploits that rely on malicious code execution due to stack overflows.
HW protection long time ago implemented on SPARC (Score:2)
At first this flag was disabled by default because it was not comply with SPARCv8 ABI so some (mainly bad coded) applications that relied on the execution of code inside the stack could not run as expected. Sun collaborated with its huge community of developers to address [sun.com]some collateral effects and once resolved Sun published the new SPARCv9 ABI reference guide in which the stack is no longer mapped as executable.
Currently 64-bit Solaris applications running on SPARC [sparc.org] don't need to worry about exploits that rely on malicious code execution due to stack overflows.
Re:HW protection long time ago implemented on SPAR (Score:2)