VirtualLock no es un mecanismo de seguridad. Es un rendimiento.
No hay garantía de que las páginas VirtualLock ed no se intercambien. Incluso si no lo son, aún serían objeto de dumping en "hibernación".
El equivalente de VirtualLock en POSIX es mlock , implementado por Cygwin (*) y será usado por libgcrypt .
Más allá del bloqueo de memoria, el refuerzo de la seguridad abarca un montón de cosas a considerar.
Suponemos que libgcrypt está escrito con la seguridad como una prioridad, que incluye muchas prácticas recomendadas para evitar desbordamientos de pila, desbordamientos de búfer, fallas importantes en el PRNG , etc.
Esto incluye hacer un esfuerzo para evitar que los datos confidenciales queden fácilmente accesibles. Los datos confidenciales deben guardarse en la memoria por el menor tiempo posible, y durante este breve período de tiempo protegidos de la mejor manera posible.
libgcrypt usa mlock como parte de este esfuerzo, y lo usará en cualquier plataforma de destino que lo tenga.
Si no está disponible, imprimirá una advertencia y seguirá adelante (mejor esfuerzo). Excepto en plataformas donde no imprime una advertencia por varias razones.
Las razones para no imprimir la advertencia en Windows (ese horrible comentario) son probablemente remanentes de tiempos anteriores, cuando cygwin no tenía una implementación mlock , y el VirtualLock de Windows era nop en todos los casos. -nt versiones. Tenga en cuenta que ese elsif solo se alcanza si HAVE_MLOCK es falso. Verifique su archivo config.h después de ejecutar ./configure para verificar que está configurado como verdadero en Cygwin.
Para resumir: según el conocimiento de los desarrolladores de libgcrypt , libgcrypt está correctamente reforzado en todas las plataformas de destino. Si tiene razones para creer lo contrario, probablemente debería presentar un error para avisarles.
* : Cygwin parece en realidad omitir VirtualLock y usar NtLockVirtualMemory directamente.