The cryptographic key is not the only data item that needs to be kept in the CPU cache in order to keep it from prying eyes/spraycans.
Key scheduling is an established paradigm in modern cryptographic ciphers: the encryption and decryption routines don't use the encryption key directly, but rather employ "round keys". These are derived from the encryption key (by a cipher-specific algorithm) and are than used in the encryption/decryption in the various rounds of the algorithm.
The AES standard defines that a 128 bit AES key is used to generate/derive 10 round keys of 128 bit each (for 192/256 bit AES keys 12/14 round keys are calculated respectively). One would expect that these round keys are calculated from the encryption key by some non-reversible hash-like-function. Unfortunately, this isn't true for AES: the encryption key is easily re-calculatable from any of the 10/12/14 round keys. Thus: these round keys need to be kept inside the CPU cache as well (at least for AES, which is used quite often).
Sounds easy in theory, but especially for Linux it's quite a challenge to find a nicely structured approach instead of just hacking something together.
A blog about the development of a general-purpose solution for mitigating cold-boot attacks on Full-Disk-Encryption solutions.