Sysverify: Linux Syscall Reduction Framework

• Sysverify is a systematic framework that reduces Linux kernel attack surfaces by combining deep static analysis with dynamic runtime verification.
• It maps high-level API calls to low-level syscalls to generate precise Seccomp configurations, minimizing false positives and ensuring robust security.
• The framework disables over 240 syscalls per process, mitigates numerous CVEs, and incurs less than 1% performance overhead, making it ideal for containerized applications.

Sysverify is a systematic attack surface reduction framework designed to minimize the kernel’s exposed system call (“syscall”) set in Linux-based systems, specifically for applications and containers. Its principal function is to enable the automatic generation of highly precise Seccomp configurations that tightly restrict the set of syscalls available to target applications. Sysverify achieves this by combining deep static analysis with lightweight dynamic runtime verification, bridging the semantic gap between high-level APIs and low-level syscall invocations. This hybrid methodology avoids the over-approximation and false positives of static-only approaches and the incompleteness of dynamic-only tracing, providing a practical and secure means of shrinking the kernel attack surface while maintaining correctness and low performance overhead (Zhan et al., 4 Oct 2025).

1. Joint Static and Dynamic Analysis Methodology

Sysverify’s verification pipeline consists of two cooperative phases—a static analysis phase for syscall dependency extraction and a dynamic verification phase for precise run-time filtering.

• Static Analysis disassembles the application binary to construct a comprehensive call graph, capturing all direct calls and statically resolvable indirect calls to library functions. For indirect calls (involving function pointers, virtual tables, etc.), the system supplements binary analysis with source code inspection to enumerate “address-taken” functions and perform type-based alias analysis. Static backward data-flow analysis (from the syscall instruction back through the call chain) matches high-level library APIs to all possible underlying syscalls.
• Dynamic Verification is used to refine the statically over-approximated syscall list. During runtime, a kernel module intercepts suspicious or rarely-used syscalls (particularly those reachable via indirect calls). The module reconstructs the user-level function invocation path by reading the stack, leveraging return addresses and code segment information. This path is then compared to the whitelisted paths extracted during static analysis; only syscalls from validated execution pathways are allowed.

This joint methodology ensures that the set of permitted syscalls is both sound (no necessary syscalls are omitted) and minimal (no unnecessary or unreachable syscalls are allowed), thereby closing the gap between theoretical dependency analysis and empirical code coverage.

2. Semantic API-to-Syscall Mapping

A key feature of Sysverify is its bridge between high-level API usage and low-level syscall invocations:

• The system constructs a semantic mapping from library APIs (e.g., glibc and application-level routines) to syscalls by analyzing all possible execution paths—distinguishing between direct and indirect invocations.
• The static phase identifies all possible syscalls that could be triggered by any library call, including those manifested via macro expansions, aliasing, or embedded assembler routines (such as syscall()).
• Backward data-flow analysis resolves the actual syscall number for each code location by tracing the propagation of constants or register values into the syscall instruction. Syscall numbers are mapped using the canonical Linux syscall_64.tbl.

This fine-grained API-to-syscall mapping is essential for correct Seccomp configuration, as it enables precise whitelisting and prevents “silent” loss of application functionality due to overly restrictive syscall sets.

3. Dynamic Verification and Path Reconstruction

Sysverify employs a targeted and efficient dynamic verification module for runtime filtering of ambiguous or suspicious syscalls:

• Syscalls selected for verification are hooked in the kernel by altering the sys_call_table. When such a syscall is invoked, Sysverify checks the process’s identity (via CR3 register and Linux namespace fields) to ensure correct association with the intended application.
• The key technical step is the reconstruction of the function invocation chain from the user-space stack. The procedure (presented in the paper’s Algorithm 1) iterates over stack values, matches them to known function addresses, and reconstructs the execution path from the binary. If the reconstructed path matches one of the secure call chains found in the static analysis, the syscall is permitted; otherwise, it is denied and reported as potentially malicious.
• The combination of this runtime check with static API-to-syscall mapping prevents exploitation via indirect calls, return-oriented programming (ROP), or stack-forged control flow.

Table: Dynamic Verification Steps

Step	Description	Notes
Hook syscall	Modify sys_call_table for target syscall(s)	Low overhead
Verify process ID	Check CR3 and namespace fields	Targeted to monitored process
Read user stack	Extract stack frames in user-space	Walk backward from stackptr
Reconstruct call path	Map return addresses to function addresses	Match to whitelist
Compare to whitelist	Permit if match, deny otherwise	Enforce path integrity

4. Performance and Security Impact

Sysverify demonstrates both strong security guarantees and low operational overhead:

• Attack Surface Reduction: On average, the approach disables over 240 syscalls per process/container, reducing the attack surface far below the default Docker baseline (which typically only restricts ~50 syscalls).
• Mitigating Vulnerabilities: By shrinking the syscall set available to applications, the framework proactively mitigates a wide range of known CVEs (average mitigation of 71 CVEs per application, including critical exploits such as CVE-2017-7308 and CVE-2017-5123).
• Performance: The system incurs less than 1% overhead even for intercepted syscalls, as confirmed by LMBench micro-benchmarks. The design deliberately applies dynamic verification only for rarely-invoked or indirect syscalls, further minimizing performance impact.
• Security: Precise path verification with stack canary protections and custom library builds defends against stack forging and sophisticated control flow attacks.

5. Technical Details and Formal Aspects

Sysverify’s technical innovations are underpinned by concrete algorithmic and formal details:

• Alias Analysis and Indirect Calls: For source-level indirect call resolution, the system employs type-based alias analysis (avoiding traditional points-to analysis due to prohibitive O(n³) complexity). Matching of call-site arity and types allows derivation of candidate implementation functions.
• Syscall Number Extraction: Syscall numbers are ana-lyzed via backward data-flow tracking, whether constants or register-derived values, to faithfully enumerate possible syscall invocations.
• Algorithmic Path Reconstruction: Algorithm 1 (in the paper and LaTeX) describes stack-based extraction of execution paths. The process iteratively inspects stack values, maps them to valid function addresses, and assembles a linearized call chain for verification.
• Seccomp Enforcement and Linux Integration: The system generates Seccomp profiles that block unused syscalls by default while supporting dynamic policy updates driven by runtime findings.

6. Limitations and Future Directions

While Sysverify offers robust and practical syscall limitation, it has defined limitations and avenues for improvement:

• Ecosystem Generality: The framework is currently optimized for Docker and C/C++ program binaries. Extending support to VM-based containers (e.g., Kata Containers, gVisor) and to applications in other programming languages is future work.
• Stack Reconstruction Fragility: Persistent adversaries with full user-space compromise could attempt to forge stack frames despite canary protections. Further hardening, potentially with hardware support or additional invariants, is required.
• Static Analysis Precision: While avoidance of points-to analysis provides scalability, type-based resolution may miss certain dynamically-dispatched targets. Incorporating more precise techniques or domain-specific modifications for language runtimes could increase accuracy.
• Automation and Adaptivity: Integrating automatic invariant inference and policy synthesis based directly on observed binaries and dynamic traces is identified as an open research direction.

7. Impact on Container and Application Security Practices

Sysverify’s systematic combination of static, source-level, and runtime techniques marks a distinct advance over prior attack surface reduction approaches:

• The resultant configurations are both practical (deployable with negligible performance cost) and secure (effectively immunizing applications against a large class of kernel bugs).
• The methodology fits seamlessly in DevSecOps and continuous deployment settings for container-based isolation, providing a scalable model for hardening at a system level.
• Its hybrid analysis techniques—capable of mapping complex API usage patterns to concrete syscall dependencies—set a template for future mechanisms aiming at automatic security policy enforcement in diverse software systems.

In conclusion, Sysverify defines a concrete, practically realizable model for syscall attack surface minimization by fusing in-depth static analysis with select, efficient dynamic verification. Its architectural design, technical details, and security rationale are corroborated by substantial empirical evaluations and by its capacity to mitigate CVEs with minimal operational overhead (Zhan et al., 4 Oct 2025).