Re: [Vol-users] Anti-forensic resilient memory acquisition

Michael, I see that you were able to find the relevant passage in the Intel Developers Manual (Vol. 3A, section 11.12.4). The passages which you quote do indeed state that the simultaneous mapping of a physical memory page with both cached and writecombined (WC) memory caching attributes is of "particular concern." The passage also provides one scenario of how data corruption may result from WC writes to physical pages that are also cached. What the passage does not say is that this is the ONLY circumstance under which memory corruption may occur. Indeed, it clearly states that mapping physical pages with incompatible cache attributes is a problem in general which "may lead to undefined operations that can result in a system failure." This interpretation is supported also by the recommended procedure which an operating system is to follow when remapping a physical page with incompatible cache attributes. The OS is supposed to render the original mapping not present and flush the TLB of any processor which "may have USED the mapping, even speculatively." (Emphasis added.) Reading from a physical memory page, moreover, modifies the internal state of the processor, including the TLB and, potentially, the L2 and L3 caches. The DMA controller, as the name implies, directly accesses physical memory independent of the CPU. DMA does not use virtual addresses or page tables or CPU caches. I fail to see the relevance of firewire memory acquisition to this discussion. The DMA controller does guarantee that the processor and various system buses have a coherent view of physical memory. However, memory coherence, as was previously state, does not prevent memory corruption. If memory corruption does occur the DMA controller will guarantee that the results are propagated to all of the system buses. The passage which you quote from MSDN concerning STATUS_CONFLICTING_ADDRESSES is true of some versions of Microsoft Windows and not of others. The memory manager has changed significantly over succeeding versions of Windows; and the changes are not always reflected in the product documentation. Windows 8.1 will require some significant changes in how memory is acquired, at least if the preview is any indication. My purpose in commenting on this aspect of your paper was not to suggest that the basic concept of rolling your own page table entry was without merit. Indeed, I stated that it was a very interesting idea that deserved further research. But it is also an idea with some fundamental problems given the current design of commercial x86/x64 processors. These problems are never going to be solved if you simply deny that they exist. People think that winpmem is a part of Volatility and that it therefore must be good. In fact, when I go to the link which you published (http://goo.gl/9VnnkY) "Volatility" is precisely what I see. There are many people on the list who lack the technical background to properly evaluate your code or understand its risks. I think we know that many people are going to take this code and run it on their production systems. I have to say that this code involves substantial risk, and that you must accept some responsibility for the potential consequences given that we know the public perceptions. The Order of Volatility also must accept some responsibility since it allows this code to be published under its banner without adequate warning of its experimental nature. Regards, George.