About timing my question is:

How can attack know the time of which certain instructions are performed by the victim?

And about the cache, how can attacker know which cache line is being accessed by the victim? Is this doable in "normal" PC? Actually, I think cache side-channel attack is performed through a time side-channel attack by understanding if an instruction has been executed or not by checking the cache fetching timing (the more time the more away is the cache (L2,L3) and the more unlikely is that the particular instruction was executed)...

but again the question is: how can an attacker observe this? How can attacker observe the cache access time of a particular process run by the victim?

1 Answer 1


There are various types of cache-based side channel attacks and they do work a bit differently depending on what exactly is being attacked. You haven't specified any particular scenario, so let's cover some "common" scenarios:

We need to start with defining an attacker model: What is our attacker exactly? For cache-based side channel attacks, we typically choose one of two different scenarios (there are also sub-variants for these scenarios which I will skip here):

  1. We have at least two processes running on the same operating system. One is the victim process, an innocent process doing honest work, possibly dealing with secrets. Then we have an attacker-controlled process running: The attacker can run arbitrary code in its process, but the attacker cannot directly access the victim's memory. The attacker tries to use cache information to extract information from the victim's process (e.g. the secret).
  2. We have at least two virtual machines running on the same hardware (thus sharing the same cache). This is for instance a cloud-attack scenario: If an attacker rents a VPS in some cloud, the physical machine will also host other honest victim virtual machines. The attacker hopes to extract secret information from the other virtual machines via the cache.

Next, to understand cache-based side channel attacks we need some understanding of how the cache works. This immediatly begs the question of what architecture we're working with (X86, ARM) and possibly even the manufacturer (e.g. the cache in Intel x86 works slightly different compared to AMD x86). Lets assume we're working with a generic high-performance x86 CPU as is likely found in your laptop or desktop computer. This CPU has three levels of caching: L1, L2 and L3 (also known as Last Level Cache, or LLC). All of these layers can be attacked via separate attacks. Let's assume an attack on the L3/LLC cache as an example.

An important distinction is that the L3 cache is shared between multiple CPU cores, while the L1/L2 caches are generally exclusive to a core. This is important when designing our attack - if we're going to attack a L1 cache, our attacker needs to run on the same CPU core as the victim, while this may be irrelevant if we're instead attacking L3 cache. Note that both scenarios can be feasible in practice: If the attacker needs to run on a particular core, it can for example try to utilize CPU affinity tools provided by the operating system to schedule itself on the same core as the victim. Or the attacker may simply restart its attack process until the operating system happens to schedule us on the right core.

Next, we need to look at how the cache addressing works. This is also level-specific: The X86 L3 is generally designed as a physically indexed physically tagged cache. I won't go into cache design details here, but we do need to know that this means that our attacker process needs to share physical memory with our victim (with virtual addresses being irrelevant). In that case, both the attacker's memory and the victim's memory map to the exact same cache line. Note that this does however also mean that the attacker can actually read the victim's memory and as such this implies that the victim's memory we're attacking isn't secret (but public and open to all). Still, this is a common attack flow when trying to figure out which instructions a victim executes as below.

So next question: How does our attacker share memory with our victim? This depends on the scenario from above. For scenario 1, our attacker can for instance utilize the fact that operating systems try to save memory: Assume our victim loads a shared library into its memory. If the attacker loads the same library into its memory, the operating system will map the (virtual) memory pages of the library's code sections onto the same physical memory. This is a common technique operating systems use to save RAM: Why load everything multiple times if you can just load it once? The same magic happens with files and other things that can be memory-mapped. As an attacker, we can utilize this to share code pages with our victim. For scenario 2 stuff gets a bit more exotic, but some hypervisors are known to "scan" physical memory from virtual machines and if they detect that two memory pages have identical content, they get combined into a single physical memory page. Again, this is done to save RAM, but it also enables an attacker to share memory with a victim, by guessing their (public) memory contents.

Once we've shared memory between attacker and victim we can commence the attack. I'm going to describe a Flush+Reload style attack here. This type of attack works by loading the relevant data (i.e. some instructions of a program) the attacker is interested in into its own memory. This will cause the data to be loaded into a L3 cache line. Immediatly afterwards, the attacker flushes this data from the cache line. This is typically done by utilizing x86's clflush instruction (though there are alternatives). Now the attacker simply waits for a few hundred microseconds and loads the data again into its own memory. Simulaneously, the attacker measures the time (for example via the rdtsc instruction) it takes to perform this load (technically we take the clock-time before and after the load. The difference between these times is the time the load took). If the time is "short", we know that the victim accessed this cache line. We know (with a certain probability, ignoring cache conflicts) that the cache line belonged to a certain set of instruction (e.g. from a shared library) so the attacker now knows that the victim has executed this code. If the time is "long" however, the attacker knows that the victim has not executed this code. These steps can be repeated in a tight loop to "wait" for the victim to access the code.

So, to recap all of the above:

How can attacker observe the cache access time of a particular process run by the victim?

The attacker measures its own access time for some data that maps onto the same cache line as the victim's data. Because the cache lines are shared between attacker and victim, the attacker's own access time reveals information about what the victim did (or did not do).

How can attack know the time of which certain instructions are performed by the victim?

The attacker loads the instructions of interest into its own virtual memory. Via the the help of the operating system or hypervisor the physical memory is now automatically shared between victim and attacker. The attacker now loads the instructions repeatedly into cache, measures the access time, then flushes the data from the cache. The access time reveals whether the victim accessed the instructions (i.e. executed them) or not.

Again, there are many more types of cache attacks and they all work a bit differently, but the general principle is the same or similar.

It gets more complicated when speculative execution (e.g. Spectre/Meltdown) is involved, because then the attacker can try to access memory that he/she doesn't have access to and observe microarchitectural changes (e.g. different cache state) nevertheless. This eliminates the need for the attacker to share memory with the victim, as the attacker simply accesses the victim's memory directly (without having the rights to do so). To understand these attacks fully we need to dive a lot deeper into speculative execution (straying away from the cache aspect) and I feel that I've already blown this answer enough.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .