I spent this past weekend in San Diego to check out Toorcon 10. The presentations varied greatly in quality but there were a number that were memorable. Alexander Sotirov presented "How To Impress Girls With Browser Memory Protection Bypasses" that Mark Dowd presented at Blackhat in Vegas. I found it every bit as cool at the convention center as at Caesar's Palace.
The one talk that really made me sit up and take notice was Jake Appelbaum's presentation on the cold boot attack. I had always assumed that it would be much more difficult. He bemoaned the fact that all the commercial disk encryption utilities keep their keys in memory. Unfortunately, they don't have much choice. They wouldn't be particularly useful if the user had to type his password every time data was written to or read from disk. The only way that I know of to avoid that is to offload the encryption to a tamper resistant device like the Fortezza. As a practical matter if someone can grab your laptop or desktop from you while I/O is happening, he doesn't really need to do anything fancy to find your key in memory. A threat model that I find more interesting, which I'm fairly certain none of the disk encryption utilities address, commercial or open source, is the "idle system theft." One walks away from his laptop with the screen locked and an attacker walks off with it. Being a FreeBSD developer, geli(8) is what I first think of for disk encryption. Its suspend option could address the key security issue (currently unfinished). In this case suspend is intended for a laptop suspend, all pending I/O gets blocked and the keys get zeroed in memory. The only currently complete solution is geli detach which requires that the file system be unmounted first ... not exactly practical to have happen every time the system is left idle. An issue that this doesn't address is that all data that has been accessed on disk recently is in memory in cleartext. What needs to happen is all dirty buffers get flushed to disk, all the vnodes on the mount have cached buffers freed and then those buffers are zeroed. There is currently no interface to FreeBSD file systems available for forcing that to happen.
I'm still debating about whether I care enough about this particular threat to take the time to address it. Other security issues like having an executable stack that always starts at the same address and deterministic library mappings seem like a bigger problem. The one upside to FreeBSD having fewer deployments is that script kiddies and tools like Metasploit, Canvas, and Core Impact basically ignore it.