1) This topic must be taken seriously. A standard technique for attacking a system is to request a bunch of memory or disk space, leave it uninitialized, and see what you've got.
2) As regards the "volatile" keyword, I agree with Perry. The two punchlines are: > if, for example, gcc did not honor [the "volatile" keyword], > the machine I am typing at right now would not work because > the device drivers would not work. > If they haven't implemented "volatile" right, why should > they implement the pragma correctly? 3) However, a discussion of compilers and keywords does not complete the analysis. A compiler is only part of a larger system. At the very least, we must pay attention to: -- compiler -- operating system -- hardware architecture -- hardware physics At the OS and hardware-architecture levels, note that a device driver accesses a "volatile" device register only after beseeching the OS to map the register to a certain address in the driver's logical address space. In contrast, for some address that points to ordinary storage, the OS and the hardware could (and probably do) make multiple copies: Swap space, main memory, L2 cache, L1 cache, et cetera. When you write to some address, you have no reason to assume that it will "write through" all the layers. Swap space is the extreme case: if you were swapped out previously, there will be images of your process on the swap device. If you clear the copy in main memory somehow, it is unlikely to have any effect on the images on the swap device. Even if you get swapped out again later (and there's no guarantee of that), you may well get swapped out to a different location on the swap device, so that the previous images remain. The analogy to device drivers is invalid unless you have arranged to obtain a chunk of memory that is uncacheable and unswappable. To say the same thing in other words: a compiler can only do so much. It can generate instructions to be executed by the hardware. Whether that instruction affects the real physical world in the way you desire is another question entirely. 4) In the effort to prevent the just-mentioned attack, a moderately-good operating system will expunge memory right before giving it to a new owner. It would be more secure (but vastly less efficient) to expunge it right after the previous owner is finished with it. To see this in more detail, consider swap space again: a piece of "used" swap space need not be expunged, unless you are fastidious about security, because the operating system knows that it will write there before it reads there. Clearing it immediately would be a waste of resources. Leaving it uncleared is potentially a security hole, because of the risk that some agent unknown to the operating system will (sooner or later) open the swap-space as a file and read everything. 5) We turn now to the hardware-physics layer. Suppose you really do manage to overwrite a disk file with zeros. That does not really guarantee that the data will be unrecoverable. As Richard Nixon found out the hard way, the recording head never follows exactly the same path, so there could be little patches of magnetism just to the left and/or just to the right of the track. An adversary with specialized equipment and specialized skills may be able to recover your data. 6) To reduce the just-mentioned threat, a good strategy is to overwrite the file with random numbers, not zeros. Then the adversary has a much harder time figuring out what is old data and what is new gibberish. (To do a really good job requires writing your valuable data always in the middle, and overwriting gibberish twice, once offset left and once offset right.) This is one of the reasons why you might need an industrial- strength "stretched random symbol generator": http://www.monmouth.com/~jsd/turbid/paper/turbid.htm#sec-srandom Note that the random-number trick can be used for main memory (not just disks) to ensure that the compiler + OS + hardware system doesn't optimize away a block of zeros. This actually happened to me once: I was doing some timing studies, and I wanted to force something out of cache by making it too big, so I allocated a large chunk of memory and set it to zero. But no matter how big I made it, it fit in cache. The system was using the memory map to give me unlimited copies of one small page of zeros (with the copy-on-write bit set). 7) Terminology: I use the word "expunge" to denote doing whatever is necessary to utterly destroy all copies of something. Clearing a memory location is sometimes far from sufficient. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
