Una recomendación común es mantener las claves de cifrado y otros pequeños secretos en la memoria mlock-ed.
Lamentablemente, los secretos en los registros aún se derramarán si se anula un subproceso. ¿Hay formas de asegurar que el kernel sobrescriba los datos derramados en lugar de dejarlos para que permanezcan o los kernels ya lo aseguran?
¿El kernel guarda registros en la misma ubicación cada vez? Estoy más interesado en Linux, aunque no me importaría algo portátil.
Hay varias cosas que pueden causar derrames en el registro, desde la prevención de subprocesos como mencionó a todo tipo de interrupciones. Actualmente no hay forma de evitar esto, a menos que se deshabiliten completamente las interrupciones (lo cual es difícil si se tienen en cuenta los NMI y los SMI) y la prevención. Esto solo se puede hacer en modo kernel, y hace que una computadora sea completamente inutilizable.
Creo que el problema es que no entiendes el propósito de mlock() . No está diseñado para mantener la información confidencial fuera de la RAM (después de todo, la memoria bloqueada sigue siendo memoria), pero para evitar que se cambie al disco, ya sea por razones de seguridad o de rendimiento. Los registros que se han enviado a la pila durante un cambio de contexto no están sujetos a ser intercambiados en primer lugar. Tan pronto como finaliza el cambio de contexto, los registros se restauran.
¿El kernel guarda registros en la misma ubicación cada vez?
Los registros se guardan en algunas ubicaciones, dependiendo del origen del cambio de contexto. En el archivo fuente del kernel arch/x86/entry/entry_64.S , general los registros de propósito se insertan en la pila, generalmente utilizando macros dedicados. Más tarde se restauran utilizando el pop. Las macros relevantes (como SAVE_C_REGS y RESTORE_C_REGS ) se definen en arch/x86/entry/calling.h .
Lea otras preguntas en las etiquetas linux