I've previously suggested this approach to minimize this risk:
One way to minimize the impact of "unintentional" cache flushes (unintentional from our point of view) is to repeat the cache freezing procedure periodically in order to reverse the effects of "unintentional" cache flushes (wbinvd).My new idea would eliminate this risk all together. However, I haven't actually verified yet, whether this idea can actually be implemented. Keep this in mind while reading the next paragraphs. It is also important to understand the difference between physical/linear and virtual memory addresses; if you don't know what they are then you should read this before you read on.
The idea is actually quite simple: keep the data in the cache on physical/linear addresses which aren't backed by RAM on the system. This would guarantee that the data won't leave the CPU cache, even if a cache flush is triggered (a GP would be raised).
What I haven't verified, is whether it is actually possible to set up this scenario. The setup procedure might look something like this:
- load the data into CPU registers
- overwrite the data in RAM
- change the virtual-to-linear mapping for that virtual address to a non-existant physical/linear address (by modifying the appropriate page-table entry)
- switch the CPU cache into frozen mode
- move the data from the CPU registers into the CPU cache
One last note: obviously, if one has 4GB of RAM then there would be no invalid linear addresses - PAE might be a possibility, but that's a problem for much later.