VirtualLock non è un meccanismo di sicurezza. È uno spettacolo.
Non è garantito che le pagine VirtualLock ed non vengano sostituite. Anche se non lo fossero, verrebbero comunque scaricati in "ibernazione".
L'equivalente per VirtualLock in POSIX è mlock , che è implementato da Cygwin (*) e sarà usato da libgcrypt .
Al di là del blocco della memoria, l'indurimento della sicurezza comprende un sacco di cose da considerare.
Supponiamo che libgcrypt sia scritto con priorità di sicurezza, che include molte best practice per evitare overflow dello stack, overflow del buffer, principali difetti nel PRNG , ecc.
Questo include un tentativo di sforzo ottimale per evitare che i dati sensibili vengano lasciati in giro facilmente accessibili. I dati sensibili devono essere conservati in memoria per il minor tempo possibile e in questo breve periodo protetti nel miglior modo possibile.
libgcrypt usa mlock come parte di questo sforzo, e lo userà su qualsiasi piattaforma di destinazione che lo abbia.
Se non è disponibile, stamperà un avviso e passerà (best-effort). Tranne che nelle piattaforme in cui non viene stampato un avviso per vari motivi.
Le ragioni per non stampare l'avviso in Windows (quel commento orribile) sono probabilmente un avanzo dei vecchi tempi, quando cygwin non aveva un'implementazione mlock , e Windows ' VirtualLock era un nop in tutti i non -nt versioni. Si noti che elsif viene raggiunto solo se HAVE_MLOCK è falso. Controlla il tuo file config.h dopo aver eseguito ./configure per verificare che sia impostato su true in Cygwin.
Per riassumere: al meglio della conoscenza degli sviluppatori di libgcrypt , libgcrypt è correttamente rafforzato su tutte le piattaforme di destinazione. Se hai motivi per credere altrimenti, dovresti probabilmente presentare un bug per farglielo sapere.
* : Cygwin sembra effettivamente bypassare VirtualLock e utilizzare direttamente NtLockVirtualMemory.