# Real-Time Detection for Cache Side Channel Attack using Performance Counter Monitor
## 4 Identifying New Performance Counters  
This section describes the experiment to obtain useful CPU counters for detecting cache side channel attacks such as Flush+Reload, Flush+Flush, and Prime+Probe. In our previous study, it was only shown that the Flush+Reload attack incurred a significant cache miss rate in the PCM [15]. The experiments in this study were performed on an Asus X99-E WS server computer with Ubuntu 16.04 LTS, an Intel Xeon(r) E5-2620 v4 processor, and a 32 GB DDR3 memory as the victim. As a spy, a MacBook Air with Mojave OS and an Intel Core i5-5250U 1.6 GHz processor and 8 GB DDR3 memory was used. Attacks proceeded via SSH remote access. Three cache side channel attacks were implemented by using Mastik [16], a cache side channel framework. Mastik makes it easy to execute various types of cache side channel attacks with a simple setup and compilation. A PCM tool that was provided by Intel was used as an open source [8]. Intel PCM offers many options; thus, CSV file options were used to extract the counter values, which created the graphs to easily see changes in the counter values due to the attacks. Since these cache side channel attacks can be easily mounted in various environments, it is necessary to observe the PCM counter value in various situations. Thus, experiments were performed with two scenarios. First, in a normal scenario, the attacks were tested without background applications. In the second scenario, the attacks were tested with several applications such as a video player, an office program (e.g., Libre Office Calc), and a web browser (e.g., Firefox) running in the background. During the experiments, all of the cache side channel attacks were executed for 15 s each in a normal scenario and the running application scenario. Prior to mounting the attacks, 15 s of wait time were provided for each scenario to clearly identify the change in the PCM counters. Through this experiment, five counters were discovered that significantly changed due to the three attacks. These counters include the IPC (Instruction Per Cycle), L3 cache miss, L2 cache miss, L1 cache miss, and the speculative and retired branch counters. Each attack had a slightly different effect on the counters, except the IPC (average number of instructions per cycle) value showed identical changes to all of the attacks. Figure 1 shows the changes of the IPC value when the attack was executed in each scenario in the experiment. In both scenarios, the IPC value was greatly reduced when the attacks were executed. The reason for greatly changing the IPC value was that the memory access had different characteristicsfor the three attacks. The Flush+Reload attack resulted in frequent main memory accesses in the process of spy flushing and reloading the cache line, which consumed many cycles. The Prime+Probe attack occurred mostly for main memory access at other logical cores that shared the cache set in the process that spy filled and probed its own data. Unlike the other two attacks, the Flush+Flush attack did not have access to the main memory; however, it took many cycles to continuously flush the cache line [2]. Figure 2 shows the change in the L1, L2, and L3 cache misses when the attack was executed. In both scenarios, three cache misses were significantly increased when the Flush+Reload and Prime+Probe attacks were performed. However, the increment in the cache misses counter value was different for both attacks. In the case of the Flush+Reload attack, it was observed that the three cache misses were increased by approximately two million. On the other hand, in the case of the Prime+Probe attack, the L1 and L2 cache misses were increased by approximately 50 million; however, the L3 cache miss did not increase. It was observed that there was no change when the Flush+Flush attack was performed. The reasons for these changes were considered. For the case of Flush+Reload, it caused the cache misses to be increased when the spy continued to flush and reload the cache line while waiting for the victim's access.