¿Un sistema operativo que no confía en su RAM?

Los datos en el caché L1 no permanecerán solo en el caché L1; El hardware lo copiará a la RAM principal de forma transparente y casi inmediatamente. Al menos así operan las CPU modernas. Si desea mantener los datos confidenciales fuera de la RAM, debe mantenerlos solo en los registros. Los cambios de contexto también serán un problema, ya que vaciarán automáticamente los registros a un espacio RAM designado.

Si bien teóricamente es posible operar solo en registros y realizar el cifrado y descifrado en la CPU, será difícil hacerlo correctamente (el cifrado de acceso aleatorio con actualizaciones es difícil de diseñar sin puntos débiles) y es muy costoso (Más o menos tendrías que implementar una máquina virtual, donde cada código de operación conlleva algún descifrado, por lo que debes esperar una desaceleración de un factor 50 como mínimo).

El proyecto TRESOR parece tener un alcance mucho más limitado; no quiere proteger a datos genéricos de fugas a la RAM, solo a claves de cifrado . Que, en mi opinión, se pierde el punto. Cifras los datos porque los datos son confidenciales y deben mantenerse confidenciales. La clave de cifrado es un objetivo de alto valor porque concentra el secreto, pero ciertamente no es el objetivo único .

  

... mantenga toda [la] RAM encriptada, almacenando la clave en la CPU [?]

Sí, podría escribir un kernel que almacenó la clave en un registro de CPU. Los procesadores SSE (básicamente cualquier arquitectura de Intel en ejecución) tienen registros "XMM" de 128 bits en los que se puede almacenar la clave, y los últimos chips de Intel pueden hacer AES basado en hardware. Un registro, una tecla, una instrucción de CPU.

Perdería un registro multipropósito y tendría que cambiar al modo kernel muy a menudo (asesino de rendimiento masivo) o dar a cada aplicación su propia clave que está cifrada con la clave del kernel, pero funcionaría. La trampa perversa es que un cambio de contexto generalmente coloca los valores de registro en la RAM. La clave y cualquier otra cosa en el kernel deben ser eliminadas porque cualquier aplicación puede usar todos los registros de propósito general.

Lo que realmente se necesita es un registro persistente que sea direccionable solo por el anillo 0. Sé que existen como registros de control , pero no estaba seguro de ningún propósito general, los que están por ahí para tomarlos. Luego miré el enlace de d33tah a TRESOR y resulta que alguien realmente lo implementó. Lea sobre las advertencias y tal.

Algunos usuarios de Google me señalaron a enlace : usarlo con un archivo de intercambio cifrado parece una solución.