The attack itself is based on Covert Channels: inadvertent information leaks that occur when two processes share a resource. They can show up whenever that is true. The way high-assurance systems tried to root them out was using a combination of manual and mathematical means. Kemmerer's Shared Resource Matrix (1983) more accessible because it's manual and straight-forward. Apply it to each layer & component of the system.
Far as hardware, there's a number of ways to mitigate stuff like this. One I only tried once was shutting off the cache or any other risk in CPU. Ouch. Conceptually easiest is to do Red-Black model where you run crypto and untrusted stuff on two different devices with interface that transfers fixed-rate, fixed-time w/ attention to error responses. That was military/NSA's trick. The next is SMP with separation kernels that keep trusted stuff on one CPU and untrusted on another again with fixed-size timing. Another is partitioned caches or caches with hard locks. They have prototypes, maybe production versions, but they're still new. Another I did was asynchronous, randomized execution for system tasks to mask timing. One researcher did the same thing even making a CPU for it.
So, there's your basic solutions to this problem that go way back. Decades, actually, if we're talking red-black or covert channel analysis. Cloud-style deployments will benefit from other techniques... maybe. Hard to tell as risk goes up. Hardware with multi-core, multi-thread, several layers of caching, and so on is not the ideal foundation for INFOSEC. That's just asking for leaks. I have no faith in long-term security of covert channel mitigations for such a setup. Although, one can design such CPU's to protect system integrity pretty well.
https://www.google.com/?gws_rd=ssl#q=covert+channel+intel+ca...
The attack itself is based on Covert Channels: inadvertent information leaks that occur when two processes share a resource. They can show up whenever that is true. The way high-assurance systems tried to root them out was using a combination of manual and mathematical means. Kemmerer's Shared Resource Matrix (1983) more accessible because it's manual and straight-forward. Apply it to each layer & component of the system.
http://www.cs.unm.edu/~crandall/491591spring10/kemmerer.pdf
Far as hardware, there's a number of ways to mitigate stuff like this. One I only tried once was shutting off the cache or any other risk in CPU. Ouch. Conceptually easiest is to do Red-Black model where you run crypto and untrusted stuff on two different devices with interface that transfers fixed-rate, fixed-time w/ attention to error responses. That was military/NSA's trick. The next is SMP with separation kernels that keep trusted stuff on one CPU and untrusted on another again with fixed-size timing. Another is partitioned caches or caches with hard locks. They have prototypes, maybe production versions, but they're still new. Another I did was asynchronous, randomized execution for system tasks to mask timing. One researcher did the same thing even making a CPU for it.
So, there's your basic solutions to this problem that go way back. Decades, actually, if we're talking red-black or covert channel analysis. Cloud-style deployments will benefit from other techniques... maybe. Hard to tell as risk goes up. Hardware with multi-core, multi-thread, several layers of caching, and so on is not the ideal foundation for INFOSEC. That's just asking for leaks. I have no faith in long-term security of covert channel mitigations for such a setup. Although, one can design such CPU's to protect system integrity pretty well.