# JITScanner: Just-in-Time Executable Page Check in the Linux Operating System +
## 3 The JITScanner System
### Architectural Hints  
The objectives of our system are two-fold: we want to perform a comprehensive analysis of every executable page that can be exploited by an execution flow of a program, while minimizing at the same time the intrusiveness. To achieve these objectives, our system employs a multi-faceted approach, the scheme of which is summarized in Figure 2.  
The architecture of our solution exploits both a kernel-level layer and a user-level layer. The kernel-level layer, which is fully implemented as a Linux Kernel Module (LKM), performs two critical actions:  
1. It intercepts the first access to an executable page (or an updated executable page--this is the case of WX pages), which is carried out via an instruction fetch by the CPU;
2. While handling the interception of the instruction fetch, and after the kernel materialized the target page in RAM, we perform critical checks on the page content which might lead to the forced termination of the application. The verification process described in point (2) occurs within the same thread that initiated the access (for instruction fetch) to the executable page. Consequently, it operates synchronously concerning the application's execution. To ensure swift handling of this scenario, allowing the thread to quickly resume executing user-level code if the application termination is not prompted, our architecture integrates modules responsible for conducting these critical checks directly at the kernel level. However, in typical situations, it is essential to restrict the number of checks per  
Figure 1: Common existing solutions (top picture) vs. JITScanner (bottom picture). formed synchronously. For instance, a common scenario might involve merely verifying if the page content includes the embedding of shellcode. Limiting the synchronous checks helps maintain efficient and responsive execution of the application by balancing the critical verification tasks without impeding the performance of the user-level code. To still enable a more ample check of the page content, we exploit the user-level part of the architecture. It involves a program that receives input from the kernel in the form of a tuple: \(<\mathit{page\_content},\mathit{offset},\mathit{process\_id},\mathit{thread\_id}>\). The \(offset\) denotes the position (linear address) of the first fetched instruction within the page. This program conducts a more comprehensive check of the page content asynchronously concerning the thread that initiated the page access. This approach allows for a broader examination to detect potential malicious signatures within the executable page, carried out off the critical path of the original application's execution. This checking program can be configured to take action, such as blocking the application (e.g., via the kill() system call), if it identifies any security-critical aspect during the asynchronous check. Moreover, the \(\mathit{page\_content}\) included in the tuple represents a snapshot of the executable page captured at the time of the intercepted instruction fetch. This snapshot capability enables the analysis of the complete history of the content of any WX (Write-Execute) page over time, a feature not facilitated by solutions such as in [21]. This historical analysis provides a more comprehensive view of changes occurring within WX pages, enhancing the detection and understanding of potential security threats. The combination of an initial synchronous check at the kernel level followed by a subsequent asynchronous check at the user level provides configurability based on the criticality of the hosted services within the system. For services of lower criticality, the synchronous check can be omitted entirely. This prioritizes application performance, allowing the application to continue functioning without delay, even if the asynchronous check later identifies a malicious signature in an executable page that the application has already accessed. This modular approach offers flexibility and adaptability.