VirtualLock is not a security mechanism. It's a performance one.
There's no guarantee the
VirtualLocked pages won't be swapped out. Even if they aren't, they'd still get dumped on "hibernation".
The equivalent for
VirtualLock in POSIX is
mlock, which is implemented by Cygwin(*) and will be used by libgcrypt.
Beyond memory locking, security-hardening encompasses a whole bunch of things to consider.
We assume libgcrypt is written with security as a priority, which includes many best practices to avoid stack overflows, buffer overflows, major flaws in the PRNG, etc.
This includes doing a best-effort attempt at avoiding sensitive data from being left around easily accessible. Sensitive data should be kept in memory for as little time is possible, and during this short time protected as best as possible.
mlock as part of this effort, and it will use it on any target platform that has it.
If it's not available, it will print a warning and move on (best-effort). Except in platforms where it doesn't print a warning for various reasons.
The reasons for not printing the warning in windows (that horrible comment) are probably a leftover from older times, when cygwin didn't have an
mlock implementation, and Windows'
VirtualLock was a nop in all the non-nt versions. Notice that that
elsif is only reached if
HAVE_MLOCK is false. Check your
config.h file after running
./configure to verify yourself that it's set to true under Cygwin.
To summarize: to the best of libgcrypt's developers' knowledge, libgcrypt is properly hardened on all target platforms. If you have reasons to believe otherwise, you should probably file a bug to let them know.
*: Cygwin seems to actually bypass VirtualLock and use NtLockVirtualMemory directly.