It is, but keep in mind that on general-purpose computers running AES, if you can extract secrets from virtual memory, you are already in a position to wiretap the AES process directly.
A cold-boot attack as detailed in [0] makes it vastly easier to extract secrets from physical memory than to wiretap the AES process, especially if you're not in possession of a privileged user account or a route into kernel space.
I don't know how to respond to the argument that it's "vastly easier" to chill a bank of RAM with inverted compressed air cans or liquid nitrogen and then extract its entire contents than it is to just use a debugger to watch a program run. I guess "No, I don't agree." suffices.
When you don't have the privilege level to connect a debugger to the process or the secrets are in kernel space, it's probably easier to just reboot with a cold-boot kit attached via USB than to attempt some form of escalation exploit.
Inverted air cans or liquid nitrogen are entirely unnecessary in most uses of a cold-boot attack - they're only a requirement if the machine has some form of boot protection and it's desired to transfer the memory modules for some sort of offline forensic analysis.
As an additional plus, the tools which the authors of the linked paper have written for identifying key data in memory dumps are simpler to use than tracing the execution flow of even a simple application using a debugger. I'd probably use their approach even with full debug access, as obfuscating control flow around functions handling key data seems to be a more common practice than keeping said data obfuscated in memory.
How is that possible? Virtual memory is written out to the hard disk, so presumably, anyone with physical access to the drive could read off anything that might be stored there. You wouldn't need admin rights to the box the way you would to force aes to run in gdb, right?
