# Beat the Heat: Syscall Attack Detection via Thermal Side Channel
## 2 Materials and Methods
### Methodology
#### 2.2.5 Methodology of the Experiments  
A trace of the experiment contains 600 calls of the Linux command with a sleeping time of 10 ms between each call. We decided to use the 10 ms of sleep for our experiments because it had the best results from the Pearson correlation point of view, in the previous work. Each trace was run 50 times and an average vector of temperatures was calculated for the final results. We increased the number traces run compared to the previous work, from 30 to 50, to improve the accuracy of the experiments, and doubled the number of the commands call in each script. We did not manage to further increase the number of samples because it would have required too much time for running.  
As already mentioned, we used three different desktop systems (i.e., _D-150_, _D-151_, and _D-152_) for our experiments, all placed in a controlled temperature environment. Unlike other studies (i.e., [1]), we did not fix the frequency of the desktops, nor did we disable the Intel Turbo Boost, which makes the experiments more similar to a real-life scenario.  
First, we started the experiments by measuring the baseline temperature of the systems (see Figure 3). The baseline was achieved by reading the temperature of all cores for 24 h, in rounds of 5 min reading once every 20 ms, with a 15 min pause. This part is important as one can see which is the idle temperature for each core. Additionally, we checked all the deanoms and processes that are running while the computer is in an idle state, for another 24 h, to verify their stability in running, and make sure they will not influence the experiments.  
Based on the baseline temperature of the systems and the architecture of the CPUs, we selected the cores on which the experiments are to be run. For each system, we selected two cores with a lower temperature and physical location on the die to be as far as possible from each other, such that the two running scripts do not influence each other. In Figure 4, the methodology of the experiments is presented, where it can be seen that, on the rightmost core, the temperature of the entire CPU is collected with the _readTemp_ script, and on the leftmost core, the _runCommands_ script runs. Running the scripts on a specific core was performed via _taskset_ command, which let one select the CPU affinity, more exactly, on which core the command is needed to be run [36].  
Second, we have run the same scenario as in the original paper, to reproduce the results. As we already mentioned, the _ls_ and _chtmod_ commands were used, which are both original and augmented versions.  
Next, after the results were reproduced, we continued to run the above mentioned scripts; however, this time, we started to introduce the noise. The experiments which included the noise were run using two different scenarios. The first scenario includes running the noise script on the same core as the core where the commands run, which leads to a higher noise on that specific core. The second scenario includes running the noise script without selecting a CPU affinity, and let the OS to choose where to run; in this way, we can have a different type of background noise.