# JITScanner: Just-in-Time Executable Page Check in the Linux Operating System +
## 4 Assessment
### Performance  
The second test we conducted was focused on performance evaluation. In particular, we carried out two distinct experiments in our study. Initially, we measured the performance of our solution when using conventional applications. Subsequently, we assessed the slowdown introduced by our solution for applications employing Just-in-Time (JIT) compilation, which make (important) usage of WX pages.  
For the first test, we executed multiple trials of several classic Linux command-line utilities, both with and without the presence of our LKM, and with and without the synchronous kernel-level check. Each data point reports the average execution time over 2000 samples. The results are shown in Figure 4. Additionally, the slowdown caused by our module without the synchronous check is reported in Table 5. Our findings indicate a slowdown in the range of 7% to 13%, which we can consider acceptable.  
For our second test, we selected three programming languages that are compatible with Just-in-Time (JIT) compilation, i.e., Lua, PHP, and Ruby, and used them to run a set of commonly utilized tests from the Debian benchmark game [29]. Furthermore, to establish a performance baseline, we included the C language as a reference point. To mitigate excessive variability in our measurements, we configured the benchmark parameters to execute computationally non-trivial workloads, each with an execution time of approximately one second. Subsequently, similar to what done for the previous test, we conducted 500 iterations of the benchmarks under the following conditions: with and without the incorporation of our LKM, and with and without the synchronous level check of the page content.  
The results of these experiments are presented in Figure 5 and the performance slowdowns are reported in Table 6. Our observations are as follows:  
1. In the absence of the synchronous check, no test exhibited a slowdown exceeding 5%, and in some instances, no discernible slowdown was observed at all;  
\begin{table}
\begin{tabular}{l c c c c} \hline  & **Sign. in Plain** & **Sign. in Packed** & **Total Samples** & **Signature Retention** \\ \hline \hline \multirow{2}{*}{ClamAV} & \multirow{2}{*}{515} & \multirow{2}{*}{0} & \multirow{2}{*}{515} & \multirow{2}{*}{0\%} \\  & & & & \\ \hline JITScanner & & & & \\ \end{tabular}
\end{table}
Table 4: Signature retention of JITScanner and ClamAV.  
Figure 4: Execution time of common command-line utilities.  
With the synchronous check enabled, the majority of tests experienced a slowdown of less than 10%, with some exceptions noted for the PHP language-based tests.  
With these results and taking into account the possibility to disable the synchronous check, which, in certain scenarios, may have a greater impact on the slowdown, our architecture introduces a negligible performance overhead on JIT-based applications.  
Additionally, it should be noted that our performance evaluation results refer to a kind of worst-case scenario for our system, as we tested it on very short-lived applications. In these cases, the cost of the initial security check on a page may not be fully offset by its subsequent accesses for instruction fetch. The slowdown is, therefore, expected to be less pronounced in applications where the longer overall execution time will mitigate the impact of the initial page check.  
Figure 5: Execution time of JIT benchmarks.  
\begin{table}
\begin{tabular}{l l} \hline \hline
**Application Name** & **Slowdown** \\ \hline cat & 7.46\% \\ ls & 10.57\% \\ touch & 9.95\% \\ diff & 13.90\% \\ stat & 11.06\% \\ \hline \hline \end{tabular}
\end{table}
Table 5: Slowdown of common command-line applications with no synchronous page check.