On Thu, Nov 14, 2002 at 02:44:58AM -0800, Michael Wojcik composed: > Scrubbing is clearly no more than a best-effort attempt to make it more > difficult to retrieve sensitive data from memory. I think it's of dubious > value, frankly, and this thread has probably prompted more discussion than > it warrants. There is a portable way to prevent the dead-store-elimination > problem, but that's only one of scrubbing's many failings. This seems like a huge amount of pushing-on-a-rope, trying to do things which the compilers don't like to do, and really aren't supposed to do, as people are asking for semantic effects which aren't part of the language specs. A trivial observation: If the attacker can read your memory, you are in deep trouble. All scrubbing does is limit the window of observation for being just the time the data is live, instead of until the memory page is reallocated and blanked by the OS. A second observation: If you really want this behavior, replace/tweak malloc/free! Free, being a library routine, tend to be outside the scope of the compiler's optimizaion. If free blanks memory in the process, you now don't have to worry about scrubbing. You could add a malloc variant which says "block X should be scrubbed on freeing", if you needed more efficiency. The bigger concern is when the memory is paged to disk, and that record may have a much MUCH longer time window. But scrubbing has no real effect on this, this is an effect of VM memory management and memory-only pinning. -- Nicholas C. Weaver nweaver@cs.berkeley.edu
