This paper just came out: http://eprint.iacr.org/2013/448.pdf
It's quite exciting, really. In summary, by running another process which maps the gnupg executable and plays tricks to detect L3 cache fills, they can recover the private key used in a gnupg signature operation. This is a threat in any multi-user system. It's also a threat in a VM scenario if you have a page-sharing system. I think in Debian our responsibility is at least to try to fix the multi-user problem. The simplest way seems to be to avoid having crypto processes share their pages with other processes. I wrote a simple function which unshares all of the relevant file mappings: http://www.chiark.greenend.org.uk/ucgi/~ian/git/map-unshare.git/ It seems to work in the simple test program, for me, on i386. It's not threadsafe (and making it threadsafe would be quite tricky). It's also Linux-only, but I guess FreeBSD must have ways to do this. Is trying to plumb this into various crypto executables a reasonable approach ? Doing this to ssh, sshd, gpg, etc., would seem quite straightforward and probably reasonable from a performance point of view. (Single-user embedded systems should have a way to turn it off.) Web browsers might be a problem because you probably don't want to unshare the whole of the executable and libraries. Another possibility would be to try to provide a set of LD_PRELOAD-based hooks, thus providing a toolkit for retrofitting the page-unsharing without having to patch and rebuild everything of interest. Ian. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20978.41094.663790.937...@chiark.greenend.org.uk
