Memoria virtual sin MMU

Ciertamente es posible , pero es posible que tengas que redefinir qué es la "memoria".

Para hacer esto transparente a una tarea o proceso, lo más probable es que tenga que emular cada operación, esencialmente creando una máquina virtual bastante lenta. El núcleo (administrador de la máquina virtual) puede verificar cada llamada y devolver los datos desde la RAM o el disco, o evitar el acceso ilegal.

Se puede usar un diseño más cooperativo, pero es más intrusivo. Cada tarea o proceso puede solicitar utilizar un determinado bloque de memoria y prometer no tocarlo antes y después de que se haya otorgado / liberado la solicitud. Esto no puede detectar un acceso ilegal, pero puede permitir que se ejecuten varias tareas en un espacio de memoria limitado, asumiendo que el kernel puede copiar manualmente la memoria en algún lugar cuando una tarea no la necesita actualmente. La memoria se puede copiar hacia y desde el disco durante un cambio de contexto, si es necesario.

Ninguno de estos son realmente prácticos, por supuesto. Para responder a la pregunta sobre por qué no es posible, solo recuerde que sin una MMU, una tarea puede sobrescribir cualquier memoria, y el núcleo no tiene idea de dónde se escribió una tarea o dónde se va a leer.

Es posible escribir una pieza de software que emule una CPU con una MMU y usarla para ejecutar programas. AFAIK, las CPU modernas tendrán un emulador de este tipo creado por el fabricante de la CPU. Creo que algunos emuladores están disponibles como productos comerciales.

Escribiría su sistema operativo para usar el hardware emulado y ejecutaría los programas binarios existentes. Esto puede ser bastante lento, SWAG 5-50x más lento.

Un sistema que puede ofrecer un mejor rendimiento no emula todas las instrucciones en el software, sino que traduce instrucciones binarias del programa para la CPU emulada a la máquina real, una vez o según sea necesario. Esto puede dar un rendimiento significativamente mayor.

Un ejemplo, que también tiene otras capacidades, es QEMU con una explicación útil en Wikipedia QEMU

Si el objetivo es solo proteger el programa entre sí (y no ejecutar programas que no se ajusten a la RAM), existen enfoques que convierten los programas binarios en programas binarios "seguros" que se ejecutan "de forma segura" en el mismo Hardware como el programa binario original fue el objetivo. Un ejemplo de esto es Cliente nativo de Google (también conocido como NaCl) . Si está interesado en probarlo, hay versiones especialmente creadas de Chrome que tienen la capacidad de ejecutar múltiples programas binarios dentro de Chrome usando NaCl.

Si es aceptable restringir el conjunto de programas a aquellos donde el código fuente está disponible, puede haber más opciones.

Aunque no están diseñados para la tarea general de implementar la memoria virtual, otros ejemplos de programas en ejecución que se protegen mutuamente se muestran en la máquina virtual de Java y la máquina virtual .NET. Las primeras implementaciones fueron intérpretes, interpretando cada instrucción de nuevo. Luego popularizaron la compilación 'Justo a tiempo' (JIT). JIT dio mejoras masivas en el rendimiento en ciertos casos comunes, según la regla 80/20; más del 80% del tiempo de ejecución se gasta en menos del 20% del código. Por lo tanto, la sobrecarga de la traducción se compensa con el rendimiento mucho mayor de las instrucciones traducidas.

Concretamente, es posible que pueda optimizar, por ejemplo, nunca desalojando la memoria de datos, solo la memoria del programa. Eso podría permitir que el sistema traduzca las instrucciones emuladas en instrucciones seguras de acceso a datos reales, al mismo tiempo que comprueba cada llamada de función para una salida de página emulada.

Todas estas técnicas sacrifican el rendimiento, y algunas solo pueden aplicarse a subconjuntos del comportamiento de la memoria virtual. Todo depende de la cantidad de gastos generales que está dispuesto a pagar, o de qué otras restricciones puede aceptar.