El problema con la mayoría de los sistemas operativos es que siguen una "convención de llamada" específica. Esta convención requiere poner parámetros de función en la pila, ya que es un derivado de la convención de llamada de estilo C. Usted debe usar esta convención para la compatibilidad de ABI (Interfaz Binaria de la Aplicación) con ese SO. Por lo tanto, sin el soporte del sistema operativo, solo podría usar esta función para las llamadas realizadas dentro de su aplicación.
Esto complicaría bastante a los compiladores y probablemente requeriría una buena cantidad de trabajo. En resumen, podría proteger sus propios programas si tuviera un compilador compatible con esta convención de llamadas, pero aún estaría a merced del sistema operativo cada vez que tuviera que hacer cosas como leer / escribir un archivo, etc. en una DLL, por ejemplo, no se puede arreglar cambiando la convención de llamadas.
En segundo lugar, hasta hace poco, con el advenimiento de la virtualización, realmente no era posible configurar un área separada como esta, porque la segmentación era costosa, y la virtualización de la memoria aún más. Hoy en día, esto prácticamente no sería un problema, pero como tenemos que lidiar con software histórico (por ejemplo, cosas escritas hace diez años que aún requieren los métodos de llamada convencionales), el sistema operativo se vería obligado a soportar ambos modelos por un período indefinido. de tiempo.
Si se escribiera un sistema operativo nuevo sin problemas de compatibilidad, ciertamente podría hacerlo, pero probablemente no sucederá, porque hay métodos más viables. El sistema operativo Singularity de Microsoft es completamente inmune a los desbordamientos de búfer (según ellos), porque el sistema operativo valida estáticamente que cada programa no puede portarse mal. Curiosamente, este sistema operativo no utiliza la "protección de memoria" que utilizan Windows, Linux, Mac OS, etc. Los programas se validan para el comportamiento correcto antes que se ejecutan, no como se ejecutan . Por supuesto, si un virus fuera capaz de este sistema, tendría un control ilimitado del sistema debido a la falta de protección a nivel de hardware.
En resumen, incluso sin una investigación seria sobre el tema, es claramente posible que este enfoque funcione, pero fuera de FOSS (software libre y de código abierto), no sería posible Este enfoque para trabajar desde un punto de vista financiero. Linux podría reescribirse desde el kernel hasta admitir el nuevo modelo, se desplegó un compilador para él, y luego todo el software podría volver a compilarse sin demasiado esfuerzo (nota: "demasiado" es relativo a, decir, Microsoft).
Microsoft, Apple, etc. no tienen este beneficio, porque el código ya está compilado por millones de desarrolladores diferentes, por lo que cualquier cosa que no se pueda actualizar se volvería obsoleta instantáneamente, o tendrían que escribir emuladores para apoyar el software antiguo. Básicamente, hasta que alguien presente un sistema operativo que tenga esta característica incorporada, con compiladores compatibles (como mínimo C y C ++, además de probablemente Cocoa y Win32 C ++), y ganen suficiente soporte para convertirse en un En contra de Linux, Microsoft y Mac OS, sería bastante difícil justificar el cambio a un nuevo modelo. Linux sería el más fácil de mover, aunque todo el software tendría que compilarse hasta que los RPM y otros tipos de paquetes sean compatibles con el nuevo modelo de llamada.
Finalmente, DEP (Prevención de ejecución de datos) soluciona el problema en la mayoría de los casos, lo que dificulta la ejecución de código que no debería. Esto también reduce la necesidad de cambiar a un nuevo modelo, aunque, como lo demuestra Singularity, el hardware podría ser mucho más rápido si no fuera forzado constantemente a protegerse contra los errores de los programadores y las vulnerabilidades que presentan.