[Dave: since Bill forwarded his reply to eros-arch, I'm copying you and cypherpunks on the reply.]
Background: Dave suggested language-level support for storage that must be zeroed when freed. Bill Frantz forwarded this to me in the context of paging-related optimizations and a possible exposure arising in EROS on this issue. So first, the OS *has* to know about the "zero on free" requirement, or it *cannot* do the right thing. This is an issue both for swap and for persistent data. In each case, blocks can be released without being explicitly zeroed. The EROS system provides a per-block "this block is zero" bit as part of the per-block metadata. This tremendously helps us avoid I/Os, but it creates an exposure to offline forensics that could be quite serious in the absence of other provisions. There are analogous issues in conventional file systems that do lazy storage clearing. I think it's useful to differentiate two bugs: exposure resulting from reallocation of uncleaned storage, and exposure to offline forensics through failure to clear the data. The first is just a bug, plain and simple. The second is part of a much larger problem. While cryptographic keys are arguably more sensitive than most other data, they are certainly not the *only* sensitive data, and it is impossible in general for applications to know which data are sensitive. Wiley Coyote probably wants his ACME A-Bomb plans encrypted, but might not care about the "HOWTO: Drop Big Rock on Roadrunner" document. Lacking any knowledge of content semantics, the word processor cannot tell which is which (a point I found difficulty making clear to the Air Force recently). In abstract, there appear to be four feasible design options: 1. Expose yourself to forensics! [Picture of disk drive in open trenchcoat will not appear in countries where such content would be considered lewd or suggestive]. That is, don't try to solve the problem at all. 2. Accept a limited window of vulnerability by using background zeroing during otherwise idle cycles. Problem is that the exposure at any given time is unknown. 3. Tell the OS what to do, e.g. by a new option M_MUSTZERO to mmap() or equivalent. The ELF object file format could very easily be extended in this way today by adding a new section type and teaching the dynamic loader about it -- the necessary directives are already in place in the compilers to support the .init section. Big problem: it's yet another exceptional condition that can go wrong. 4. Encrypt all *used* storage as it goes to disk, whereupon you don't need to worry about explicitly zeroing the deleted storage. The last, I think, is the right answer. On the whole, when my laptop is stolen I don't want anybody to get *anything* useful off of that drive. If they can't get anything useful, then in particular they cannot get my crypto keys and I'm done. Of course, this requires a per-device secure memory... shap
