There is currently quite a bit of talk about cache side channel attacks within Intel and other processors. Attacks of this type read data out of the cache, force data into the cache, or force unbounded actions to take place. These actions lead to data leakage: leakage that is not easy to detect and has the potential to leak across many different styles of containers and controls. However, while such leakage is possible, it is far easier to leak within a container between objects in that container than between containers. Nevertheless, it still is a possibility. This implies a high risk, if it happens in a system that contains sensitive information.
All systems contain sensitive information such as passwords and usernames. This means that all systems are at risk. The most prevalent sets of attacks I have seen are those that read the cache from within a browser. The most successful attacks are those that attack the same process in which they run. A browser’s windows all run within the same process, but in different sandboxes. If a site is in one sandbox, and I am forced to run arbitrary code due to another series of attacks, then there is a potential to read data from within the same sandbox. It might also be possible to read data across sandboxes. This is the attack that has many worried. People have threat modeled the attack and proposed mitigations and controls on what can run within a sandbox.
The key to the attack is to run arbitrary code. Why is this an issue? There are many layers of cache and some areas of memory that can provide juicier data. In Figure 1, we see a typical cache layout and arrows pointing to what is attacked for Spectre and Meltdown. These are only the most recent attacks. There are others that attack L2 Cache and, with some processors, even L3 Cache. The more the cache is shared, the more it is a target.
What about trusted execution environments (TEEs)? Are they at risk? Yes, they are. In the case of Intel SGX, there is already a cache attack. In many ways, it looks like a Spectre attack, but it is trying to get SGX to load memory into the data cache (D Cache in figures) that is then read by the attacker. What makes this successful is that the TEEs currently available use the D Cache as where they place decrypted data from within the TEE (per Figure 2).
There are other TEEs out there. Some use different processes, Intel VT, and other sandbox technologies. All these do is change where the TEE executes. They all write to the same cache after data is unencrypted, thereby leaking incredibly valuable data. One solution to TEE cache leakage is to use a new cache and call it a secure cache (S Cache in Figure 3) that the processor can only access. You could even use the S Cache for a secure form of Intel VT sandbox.
The approach this would take is that the unencrypted data would leave the TEE and enter the S Cache. At the same time, the instruction cache (I Cache) would be told to read so much data out of the S Cache and not the D Cache. Yes, this would add another cache to the die, yet the only element in the processor that could read the S Cache is the CPU. This cache would not be exposed for read by anything above it.
The key to protecting your cache is to currently know what data is running within your processors, update firmware, and be vigilant. Spectre forced three changes on everyone:
- Kernel changes within each operating system to prevent access to kernel memory by users (kernel page-table isolation)
- Application mitigations about running arbitrary code (e.g., a browser)
- New firmware from all vendors to allow disabling speculative execution
Even with these mitigations, cache attacks will continue. Eventually, one may just cross container (i.e., VM) boundaries. However, for now, there are only so many things we can do to protect ourselves. Yes, you must patch. It is very hard not to perform all kernel patches as well as be picky about firmware, but this is the direction we must take. Perhaps Intel and others will start to consider an S Cache for use by TEE. However, all that would do is protect those things that are juicy, as they are already encrypted.
Where are you on cache attack mitigations? Are you worried about these attacks? How have they impacted your business?