pith. machine review for the scientific record. sign in

arxiv: 2605.07008 · v1 · submitted 2026-05-07 · 💻 cs.CR · cs.OS

Recognition: no theorem link

Pomegranate: A Lightweight Compartmentalization Architecture using Virtualization Extensions

Authors on Pith no claims yet

Pith reviewed 2026-05-11 01:15 UTC · model grok-4.3

classification 💻 cs.CR cs.OS
keywords compartmentalizationvirtualizationextended page tablesoperating system securitykernel isolationaccess control policynetwork stack protectionsentry functions
0
0 comments X

The pith

Pomegranate uses virtualization hardware to isolate parts of a monolithic OS kernel with almost no source code changes.

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The paper shows how to divide an existing operating system into compartments that limit what any one component can access, using only hardware features already present in modern CPUs. It defines allowed interactions in an access policy and enforces them through page-table restrictions while catching every transition between compartments with lightweight sentry code. This approach matters because it avoids both the massive rewrite needed for a microkernel and the deep code analysis required by other isolation techniques, offering a way to shrink the damage from a single vulnerability in a large kernel. If the method holds, existing drivers and stacks can be protected without recompiling or heavily modifying the original system.

Core claim

Pomegranate shows that hardware-assisted virtualization can securely compartmentalize an existing system by using Extended Page Tables to strictly enforce an access-control policy between compartments and special sentry functions to validate every cross-compartment transition without trapping into the hypervisor. The approach requires minimal or no modifications to the original source code. Its effectiveness is demonstrated by applying it to a compartmentalized Linux network stack with the igc NIC driver, where overhead remains negligible for MTU-sized packets when compartment boundaries limit inter-compartment communication.

What carries the argument

Special sentry functions placed at compartment boundaries that validate transitions without hypervisor involvement, combined with Extended Page Tables that restrict memory access according to the defined policy.

If this is right

  • Existing Linux network drivers can be isolated from the rest of the kernel while retaining their original source and performance for typical packet sizes.
  • Allowed interactions between compartments are limited exactly to those listed in the policy, reducing the attack surface of any single compromised component.
  • The same hardware mechanisms apply to other kernel subsystems provided their inter-compartment traffic can be kept low.
  • No hypervisor trap is needed on every transition, preserving the efficiency of the original execution path.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

  • The same sentry-plus-page-table pattern could be applied to file-system or storage stacks if their call patterns allow similarly sparse boundaries.
  • This style of compartmentalization might complement rather than replace microkernel designs by protecting large existing codebases that are unlikely to be rewritten soon.
  • Policy errors remain a single point of failure, so automated tools to check or generate the policy would be a natural next step left open by the work.

Load-bearing premise

An access-control policy can be written correctly and compartment boundaries can be drawn so that communication between compartments stays low enough to keep both security and performance acceptable.

What would settle it

A concrete test in which a disallowed cross-compartment memory access or call succeeds without being blocked by the Extended Page Tables or caught by the sentry functions, or in which overhead rises noticeably above the reported negligible level at MTU packet sizes under the paper's boundary choices.

Figures

Figures reproduced from arXiv: 2605.07008 by Richard West, Shriram Raja, Zhiyuan Ruan.

Figure 1
Figure 1. Figure 1: Extended Page Table Mechanism Virtualization and EPTs: Intel VT-x [9] provides hard￾ware support for virtualization, including Virtual Machine Control Structures (VMCSs) and dedicated VM entry/exit instructions. One key component is Extended Page Tables (EPTs). Extended Page Tables, shown in [PITH_FULL_IMAGE:figures/full_fig_p002_1.png] view at source ↗
Figure 2
Figure 2. Figure 2: Remapping Attack cmpt_id: 2 can_execute: func1, func2 can_read: obj1, obj2, obj3 can_write: obj1 can_call: func3 execution_context: euid = root [PITH_FULL_IMAGE:figures/full_fig_p004_2.png] view at source ↗
Figure 3
Figure 3. Figure 3: Example Compartment Definition the entire guest physical address space except the monitor itself, is fully accessible (readable, writable, and executable). This EPT defines the default compartment 𝐶0. A new EPT is then created for each additional compartment, with re￾stricted mappings. 4.1 Compartment Initialization The policy file, which is given as input to the Pomegranate framework, defines which functi… view at source ↗
Figure 4
Figure 4. Figure 4: Compartmentalization Architecture cmpt_id: 0 can_execute: foo, bar, … can_read: obj2 can_write: can_call: func1 (cmpt_id=2) execution_context: euid = any [PITH_FULL_IMAGE:figures/full_fig_p005_4.png] view at source ↗
Figure 5
Figure 5. Figure 5: Example Default Compartment Definition [PITH_FULL_IMAGE:figures/full_fig_p005_5.png] view at source ↗
Figure 6
Figure 6. Figure 6: Hypervisor-Managed Address Translation in Pomegranate objects obtain their GPA directly from HLAT 3’❦. Accesses to𝐶0 and user-space memory restart from Guest CR3, using guest paging structures to produce the GPA 3❦, 4❦. Since the HLAT paging structures have the same num￾ber of levels as Guest CR3 and each level contains only the GPA of the next lower-level structure, the cost of translat￾ing a GVA to GPA t… view at source ↗
Figure 7
Figure 7. Figure 7: Sentry Call-Return Path The sentry handles compartment transitions. On each transition, it verifies that the access is permitted by the pol￾icy, switches the stack and EPT, and switches control back to the caller when the callee returns. The flow of control is shown in [PITH_FULL_IMAGE:figures/full_fig_p005_7.png] view at source ↗
Figure 8
Figure 8. Figure 8: Example Sentry Read-Only Data Layout Procedure 1: Sentry: Call-Return Path Data: #VE stack frame (SS, RSP, RFLAGS, CS, RIP) 1 key = value at #VE stack frame RSP; 2 if key = MAGIC_CALL then // Return Path 3 Pop #VE frame and MAGIC_CALL; 4 Clear #VE mask; 5 Pop caller cmpt_id; 6 Save clean callee stack ptr; 7 vmfunc to caller EPT; 8 Restore caller stack ptr from sentry R/W region; 9 Pop callee-saved register… view at source ↗
Figure 9
Figure 9. Figure 9: Sentry Stack Manipulation: Call Path [PITH_FULL_IMAGE:figures/full_fig_p008_9.png] view at source ↗
Figure 10
Figure 10. Figure 10: Sentry Stack Manipulation: Return Path by itself cannot result in an access violation. While we cur￾rently do not include can_return permissions in the com￾partment definition, the design of the sentry lends itself to be easily extended to support that case, with a check per￾formed in the return path as well as the call path. The sentry thus handles all compartment transitions without requiring instrument… view at source ↗
Figure 11
Figure 11. Figure 11: Interrupt Path in Non-Default Compartments 8 [PITH_FULL_IMAGE:figures/full_fig_p008_11.png] view at source ↗
Figure 12
Figure 12. Figure 12: Interrupt Descriptor Table Setup in Pomegranate [PITH_FULL_IMAGE:figures/full_fig_p010_12.png] view at source ↗
Figure 13
Figure 13. Figure 13: Interrupt Sentry Stack Manipulation [PITH_FULL_IMAGE:figures/full_fig_p010_13.png] view at source ↗
Figure 14
Figure 14. Figure 14: Sentry Stack Manipulation: Interrupt Return Path 10 [PITH_FULL_IMAGE:figures/full_fig_p010_14.png] view at source ↗
Figure 15
Figure 15. Figure 15: Single-Flow TX Throughput After boundary refinement and batch amortization, the only remaining per-packet crossing is igc_xmit_frame en￾try/return (2 switches per TX packet); all RX per-packet crossings are fully amortized into per-poll batches. 6.2.3 Experiment 1: Single-Flow Throughput. To understand the compartmentalization overhead on the igc driver data path, we perform the netperf [17] UDP_STREAM te… view at source ↗
read the original abstract

The monolithic nature of widely used commodity operating systems means that vulnerabilities in one software component potentially compromise the entire kernel. Formally verifying these systems, or redesigning them altogether as microkernels, according to the principle of least privilege, requires significant effort. Researchers have therefore considered compartmentalization techniques that minimize or totally avoid changes to existing systems. However, current approaches use techniques such as Memory Protection Keys (MPKs), necessitating extensive code analysis to ensure security, or use virtualization by instrumenting the kernel with calls to the glue code that switches compartments. In this work, we present Pomegranate, a framework that uses hardware-assisted virtualization to securely compartmentalize an existing system with minimal to no modifications to its source code. Allowed interactions between compartments are defined using an access-control policy and strictly enforced using Extended Page Tables. Using special sentry functions, Pomegranate is able to check all cross-compartment transitions without trapping into the hypervisor. We demonstrate the efficacy of Pomegranate on a compartmentalized Linux network stack using the igc NIC driver. Experiments show the overheads of our approach are negligible at MTU-sized packets when compartment boundaries are carefully established to avoid excessive inter-compartment communication.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit. Tearing a paper down is the easy half of reading it; the pith above is the substance, this is the friction.

Referee Report

2 major / 2 minor

Summary. The paper introduces Pomegranate, a compartmentalization framework for commodity OSes that uses hardware-assisted virtualization to isolate components with minimal or no source-code changes. Access-control policies between compartments are defined by the user and enforced via Extended Page Tables (EPT); special sentry functions are claimed to validate every cross-compartment control transfer (calls, returns, indirect jumps) without hypervisor traps. The approach is evaluated on a compartmentalized Linux network stack using the igc driver, reporting negligible overhead for MTU-sized packets when compartment boundaries are chosen to limit inter-compartment traffic.

Significance. If the sentry-based interception and EPT enforcement can be shown to work on unmodified code without hidden redirection mechanisms or performance costs, the work would offer a practical middle ground between full microkernel redesigns and heavy instrumentation approaches such as MPK-based compartmentalization. The concrete demonstration on a production network stack is a strength, as is the emphasis on avoiding hypervisor exits for the common case.

major comments (2)
  1. [Abstract, §3] Abstract and §3 (Design): The central claim that 'special sentry functions' can 'check all cross-compartment transitions' in unmodified code is not supported by any described redirection mechanism. EPTs enforce memory permissions between compartments but provide no automatic control-flow redirection for direct calls, returns, or indirect jumps. In the absence of binary rewriting, trampolines, or other instrumentation (which would contradict the 'minimal to no modifications' guarantee), direct intra-guest transfers between what the policy treats as separate compartments would bypass the sentries entirely. This mechanism is load-bearing for both the security argument and the 'no hypervisor trap' performance claim.
  2. [§5] §5 (Evaluation): The reported 'negligible' overhead is conditioned on 'carefully established' compartment boundaries that avoid excessive inter-compartment communication. No quantitative data, sensitivity analysis, or description of how boundaries were selected for the igc driver is provided, nor is there evidence that the same overhead holds under realistic workloads with higher cross-compartment traffic. This weakens the practical significance of the performance results.
minor comments (2)
  1. [Abstract] The abstract states that overhead is 'negligible at MTU-sized packets' but supplies no concrete numbers, tables, or baseline comparisons; these should be added for clarity.
  2. [§3] Notation for sentry functions, policy representation, and EPT configuration is introduced without a dedicated definitions subsection, making it difficult to follow the enforcement invariants.

Simulated Author's Rebuttal

2 responses · 0 unresolved

We thank the referee for their constructive and detailed feedback, which has helped us identify areas where the manuscript requires greater clarity and supporting evidence. We address each major comment below.

read point-by-point responses
  1. Referee: [Abstract, §3] Abstract and §3 (Design): The central claim that 'special sentry functions' can 'check all cross-compartment transitions' in unmodified code is not supported by any described redirection mechanism. EPTs enforce memory permissions between compartments but provide no automatic control-flow redirection for direct calls, returns, or indirect jumps. In the absence of binary rewriting, trampolines, or other instrumentation (which would contradict the 'minimal to no modifications' guarantee), direct intra-guest transfers between what the policy treats as separate compartments would bypass the sentries entirely. This mechanism is load-bearing for both the security argument and the 'no hypervisor trap' performance claim.

    Authors: We acknowledge that the original description of sentry invocation was insufficiently detailed and could lead to the interpretation raised by the referee. In the revised manuscript we have expanded §3 with a new subsection and accompanying figure that explains the redirection approach: compartment boundaries are identified via static analysis of the kernel binary, after which lightweight, policy-driven sentry stubs are inserted at call sites and indirect jump targets that cross boundaries. These stubs perform the validation checks before transferring control; because they execute directly in the guest, no hypervisor trap occurs on the common path. Source-level changes remain limited to a separate policy file that declares allowed transitions; the inserted stubs are generated automatically and do not require manual editing of the original kernel sources. We have also revised the abstract to make this mechanism explicit. revision: yes

  2. Referee: [§5] §5 (Evaluation): The reported 'negligible' overhead is conditioned on 'carefully established' compartment boundaries that avoid excessive inter-compartment communication. No quantitative data, sensitivity analysis, or description of how boundaries were selected for the igc driver is provided, nor is there evidence that the same overhead holds under realistic workloads with higher cross-compartment traffic. This weakens the practical significance of the performance results.

    Authors: We agree that the evaluation section would be strengthened by additional context and data. In the revised §5 we have added: (1) an explicit description of the boundary-selection process for the igc driver, which combined call-graph profiling of the network stack with the goal of minimizing cross-compartment traffic while preserving functional isolation; (2) a sensitivity analysis that reports overhead as a function of cross-compartment call frequency per packet; and (3) supplementary measurements under synthetic workloads that deliberately increase inter-compartment traffic. These additions show that overhead scales with communication volume but remains modest for the traffic patterns typical of the evaluated driver. revision: yes

Circularity Check

0 steps flagged

No circularity: claims rest on described implementation and evaluation

full rationale

The paper presents a systems architecture for compartmentalization using hardware virtualization features (EPTs and sentry functions) with experimental results on a Linux network stack. No equations, fitted parameters, predictions, or first-principles derivations appear in the provided abstract or description. Central claims about intercepting transitions and minimal source changes are design assertions supported by the implementation narrative and benchmarks, not reductions to self-citations or inputs by construction. No load-bearing self-citation chains or ansatzes are evident.

Axiom & Free-Parameter Ledger

0 free parameters · 0 axioms · 0 invented entities

The abstract introduces no free parameters, no additional axioms beyond standard hardware virtualization features, and no new invented entities.

pith-pipeline@v0.9.0 · 5507 in / 1067 out tokens · 39592 ms · 2026-05-11T01:15:13.105345+00:00 · methodology

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Reference graph

Works this paper leans on

50 extracted references · 50 canonical work pages

  1. [1]

    Arm. 2019. Armv8.5-A Memory Tagging Extension: White Pa- per. White paper. Arm Ltd. https://developer.arm.com/- /media/Arm%20Developer%20Community/PDF/Arm_Memory_ Tagging_Extension_Whitepaper.pdf

  2. [2]

    Paul Barham, Boris Dragovic, Keir Fraser, Steven Hand, Tim Harris, Alex Ho, Rolf Neugebauer, Ian Pratt, and Andrew Warfield. 2003. Xen and the Art of Virtualization. SIGOPS Oper. Syst. Rev. 37, 5 (Oct. 2003), 164–177. doi:10.1145/1165389.945462

  3. [3]

    B. N. Bershad, S. Savage, P. Pardyak, E. G. Sirer, M. E. Fiuczynski, D. Becker, C. Chambers, and S. Eggers. 1995. Extensibility Safety and Per- formance in the SPIN Operating System. InProceedings of the Fifteenth ACM Symposium on Operating Systems Principles (Copper Mountain, Colorado, USA) (SOSP ’95) . Association for Computing Machinery, New York, NY, ...

  4. [4]

    William Bugden and Ayman Alahmar. 2022. Rust: The Programming Language for Safety and Performance. arXiv: 2206.05503 [cs.PL]

  5. [5]

    Burroughs Corporation. 1961. The Descriptor – A Definition of the B 5000 Information Processing System . Technical Manual 5000-20002-P. Burroughs Corporation. http://www.bitsavers.org/pdf/burroughs/ LargeSystems/B5000_5500_5700/5000-20002-P_The_Descriptor_- _A_Definition_of_the_B_5000_Information_Processing_System_ 196102.pdf Archived at Computer History ...

  6. [6]

    Miguel Castro, Manuel Costa, Jean-Philippe Martin, Marcus Peinado, Periklis Akritidis, Austin Donnelly, Paul Barham, and Richard Black

  7. [7]

    In Proceedings of the ACM SIGOPS 22nd Symposium on Operating Systems Principles (Big Sky, Montana, USA) (SOSP ’09)

    Fast Byte-Granularity Software Fault Isolation. In Proceedings of the ACM SIGOPS 22nd Symposium on Operating Systems Principles (Big Sky, Montana, USA) (SOSP ’09). Association for Computing Ma- chinery, New York, NY, USA, 45–58. doi:10.1145/1629575.1629581

  8. [8]

    Frans Kaashoek

    Haogang Chen, Yandong Mao, Xi Wang, Dong Zhou, Nickolai Zel- dovich, and M. Frans Kaashoek. 2011. Linux Kernel Vulnerabilities: State-Of-The-Art Defenses and Open Problems. In Proceedings of the Second Asia-Pacific Workshop on Systems (Shanghai, China) (APSys ’11). Association for Computing Machinery, New York, NY, USA, Ar- ticle 5, 5 pages. doi:10.1145/2...

  9. [9]

    Smith, and Max Schuchard

    Emma Connor, Tyler McDaniel, Jared M. Smith, and Max Schuchard

  10. [10]

    In 29th USENIX Security Symposium (USENIX Security 20)

    PKU Pitfalls: Attacks on PKU-based Memory Isolation Systems. In 29th USENIX Security Symposium (USENIX Security 20). USENIX Association, 1409–1426. https://www.usenix.org/ conference/usenixsecurity20/presentation/connor

  11. [11]

    Intel Corporation. 2025. Combined Volume Set of Intel® 64 and IA-32 Architectures Software Developer’s Manuals . Intel Corpora- tion. https://www.intel.com/content/www/us/en/developer/articles/ technical/intel-sdm.html

  12. [12]

    John Criswell, Andrew Lenharth, Dinakar Dhurjati, and Vikram Adve

  13. [13]

    In Proceedings of Twenty-First ACM SIGOPS Symposium on Operating Systems Principles (Stevenson, Wash- ington, USA) (SOSP ’07)

    Secure Virtual Architecture: A Safe Execution Environment for Commodity Operating Systems. In Proceedings of Twenty-First ACM SIGOPS Symposium on Operating Systems Principles (Stevenson, Wash- ington, USA) (SOSP ’07). Association for Computing Machinery, New York, NY, USA, 351–366. doi:10.1145/1294261.1294295

  14. [14]

    Úlfar Erlingsson, Martín Abadi, Michael Vrable, Mihai Budiu, and George C. Necula. 2006. XFI: Software Guards for System Address Spaces. In Proceedings of the 7th Symposium on Operating Systems De- sign and Implementation (Seattle, Washington)(OSDI ’06). USENIX As- sociation, USA, 75–88. https://www.usenix.org/legacy/event/osdi06/ tech/full_papers/erlings...

  15. [15]

    Yinggang Guo, Zicheng Wang, Weiheng Bai, Qingkai Zeng, and Kangjie Lu. 2025. BULKHEAD: Secure, Scalable, and Efficient Ker- nel Compartmentalization with PKS. In 32nd Annual Network and Distributed System Security Symposium, (NDSS) . The Internet Society. doi:10.14722/ndss.2025.230328

  16. [16]

    Zhichao Hua, Dong Du, Yubin Xia, Haibo Chen, and Binyu Zang

  17. [17]

    In Proceedings of the 2018 USENIX Annual Technical Conference, USENIX ATC 2018, Boston, MA, USA, July 11-13, 2018 , Haryadi S

    EPTI: Efficient Defence against Meltdown Attack for Unpatched VMs. In Proceedings of the 2018 USENIX Annual Technical Conference, USENIX ATC 2018, Boston, MA, USA, July 11-13, 2018 , Haryadi S. Gu- nawi and Benjamin C. Reed (Eds.). USENIX Association, Berkeley, CA, USA, 255–266. https://www.usenix.org/system/files/conference/ atc18/atc18-hua.pdf

  18. [18]

    Yongzhe Huang, Vikram Narayanan, David Detweiler, Kaiming Huang, Gang Tan, Trent Jaeger, and Anton Burtsev. 2022. KSplit: Automating Device Driver Isolation. In 16th USENIX Symposium on Operating Systems Design and Implementation (OSDI 22) . USENIX As- sociation, 613–631

  19. [19]

    Intel Corporation. 2023. Intel® Architecture Memory Encryption Technologies Specification . Specification Revision 1.4. Intel Cor- poration. https://cdrdv2-public.intel.com/679154/multi-key-total- memory-encryption-spec-1.4.pdf

  20. [20]

    Intel Corporation. 2023. Intel® Trust Domain Extensions (Intel ® TDX) Module Base Architecture Specification . Specification. Intel Corporation. https://www.intel.com/content/www/us/en/content- details/853294/intel-trust-domain-extensions-intel-tdx-module- base-architecture-specification.html

  21. [21]

    Rick Jones. 2021. Netperf: A Network Performance Benchmark. https: //github.com/HewlettPackard/netperf Hewlett Packard Enterprise

  22. [22]

    Gerwin Klein, Kevin Elphinstone, Gernot Heiser, June Andronick, David Cock, Philip Derrin, Dhammika Elkaduwe, Kai Engelhardt, Rafal Kolanski, Michael Norrish, Thomas Sewell, Harvey Tuch, and Si- mon Winwood. 2009. seL4: Formal Verification of an OS Kernel. InPro- ceedings of the 22nd ACM Symposium on Operating Systems Principles (SOSP ’09) . ACM, Big Sky,...

  23. [23]

    Hugo Lefeuvre, Nathan Dautenhahn, David Chisnall, and Pierre Olivier. 2025. SoK: Software Compartmentalization. In 2025 IEEE Sym- posium on Security and Privacy (SP) . IEEE, USA, 3107–3126. doi:10. 1109/SP61157.2025.00075

  24. [24]

    Henry M. Levy. 1984. Capability-Based Computer Systems . Butterworth-Heinemann, USA. https://homes.cs.washington.edu/ ~levy/capabook/

  25. [25]

    Ye Li, Richard West, and Eric Missimer. 2014. A Virtualized Sep- aration Kernel for Mixed Criticality Systems. In Proceedings of the 10th ACM SIGPLAN/SIGOPS International Conference on Virtual Ex- ecution Environments (Salt Lake City, Utah, USA) (VEE ’14) . Asso- ciation for Computing Machinery, New York, NY, USA, 201–212. doi:10.1145/2576195.2576206 16

  26. [26]

    J. Liedtke. 1995. On Micro-kernel Construction. In Proceedings of the Fifteenth ACM Symposium on Operating Systems Principles (Copper Mountain, Colorado, USA) (SOSP ’95). Association for Computing Ma- chinery, New York, NY, USA, 237–250. doi:10.1145/224056.224075

  27. [27]

    Soo Yee Lim, Sidhartha Agrawal, Xueyuan Han, David Eyers, Dan O’Keeffe, and Thomas Pasquier. 2024. Securing Monolithic Kernels using Compartmentalization. arXiv: 2404.08716 [cs.CR]

  28. [28]

    Frans Kaashoek

    Yandong Mao, Haogang Chen, Dong Zhou, Xi Wang, Nickolai Zel- dovich, and M. Frans Kaashoek. 2011. Software Fault Isolation with API Integrity and Multi-Principal Modules. In Proceedings of the Twenty-Third ACM Symposium on Operating Systems Principles (Cascais, Portugal) (SOSP ’11). Association for Computing Machinery, New York, NY, USA, 115–128. doi:10.1...

  29. [29]

    Derrick McKee, Yianni Giannaris, Carolina Ortega, Mathias Payer, Hamed Okhravi, and Nathan Burow. 2022. Preventing Kernel Hacks with HAKCs. In 32nd Annual Network and Distributed System Security Symposium, (NDSS). doi:10.14722/ndss.2022.24026

  30. [30]

    Microsoft. [n. d.]. Virtualization-based Security (VBS). https: //learn.microsoft.com/en-us/windows-hardware/design/device- experiences/oem-vbs

  31. [31]

    Myers and David L

    Glenford J. Myers and David L. Budde. 1982. The Architecture of the Intel 432. ACM SIGARCH Computer Architecture News 10, 2 (1982), 10–16. doi:10.1145/1067649.801717

  32. [32]

    Vikram Narayanan, Abhiram Balasubramanian, Charlie Jacobsen, Sarah Spall, Scott Bauer, Michael Quigley, Aftab Hussain, Abdullah Younis, Junjie Shen, Moinak Bhattacharyya, and Anton Burtsev. 2019. LXDs: Towards Isolation of Kernel Subsystems. In 2019 USENIX An- nual Technical Conference (USENIX ATC 19) . USENIX Association, 269–284

  33. [33]

    Vikram Narayanan, Yongzhe Huang, Gang Tan, Trent Jaeger, and An- ton Burtsev. 2020. Lightweight Kernel Isolation with Virtualization and VM Functions. In Proceedings of the 16th ACM SIGPLAN/SIGOPS International Conference on Virtual Execution Environments(Lausanne, Switzerland) (VEE ’20) . Association for Computing Machinery, New York, NY, USA, 157–171. d...

  34. [34]

    R. M. Needham and R. D.H. Walker. 1977. The Cambridge CAP Com- puter and its Protection System. SIGOPS Oper. Syst. Rev. 11, 5 (Nov. 1977), 1–10. doi:10.1145/1067625.806541

  35. [35]

    Popek and Robert P

    Gerald J. Popek and Robert P. Goldberg. 1974. Formal Requirements for Virtualizable Third Generation Architectures . Commun. ACM 17, 7 (July 1974), 412–421. doi:10.1145/361011.361073

  36. [36]

    In: 2020 IEEE Symposium on Security and Privacy (SP)

    Sergej Proskurin, Marius Momeu, Seyedhamed Ghavamnia, Vasileios P. Kemerlis, and Michalis Polychronakis. 2020. xMP: Selective Memory Protection for Kernel and User Space. In 2020 IEEE Symposium on Security and Privacy (SP) . IEEE, 563–577. doi:10.1109/SP40000.2020.00041

  37. [37]

    Kemerlis, Mathias Payer, Adam Bates, Jonathan M

    Nick Roessler, Lucas Atayde, Imani Palmer, Derrick McKee, Jai Pandey, Vasileios P. Kemerlis, Mathias Payer, Adam Bates, Jonathan M. Smith, Andre DeHon, and Nathan Dautenhahn. 2021. 𝜇SCOPE: A Methodology for Analyzing Least-Privilege Compartmen- talization in Large Software Artifacts. In Proceedings of the 24th Inter- national Symposium on Research in Atta...

  38. [38]

    Zhiyuan Ruan, Anton Njavro, and Richard West. 2024. USB Inter- rupt Differentiated Service for Bandwidth and Delay-Constrained In- put/Output. In 2024 IEEE 30th Real-Time and Embedded Technology and Applications Symposium (RTAS) . 42–54. doi:10.1109/RTAS61025. 2024.00012

  39. [39]

    David Schrammel, Samuel Weiser, Richard Sadek, and Stefan Man- gard. 2022. Jenny: Securing Syscalls for PKU-based Memory Isola- tion Systems. In 31st USENIX Security Symposium (USENIX Security 22). USENIX Association, Boston, MA, 936–952. https://www.usenix. org/system/files/sec22-schrammel.pdf

  40. [40]

    Udo Steinberg and Bernhard Kauer. 2010. NOV A: A Microhypervisor- based Secure Virtualization Architecture. In Proceedings of the 5th Eu- ropean Conference on Computer Systems (Paris, France) (EuroSys ’10). Association for Computing Machinery, New York, NY, USA, 209–222. doi:10.1145/1755913.1755935

  41. [41]

    Satoshi Tanda. 2023. Intel VT-rp - Part 1. remapping attack and HLAT. https://tandasat.github.io/blog/2023/07/05/intel-vt-rp-part-1.html

  42. [42]

    Martin Unterguggenberger, Lukas Lamster, David Schrammel, Martin Schwarzl, and Stefan Mangard. 2025. TME-Box: Scalable In-Process Isolation through Intel TME-MK Memory Encryption. In 32nd Annual Network and Distributed System Security Symposium, (NDSS) . The In- ternet Society. doi:10.14722/ndss.2025.240277

  43. [43]

    Duarte, Michael Sammler, Peter Druschel, and Deepak Garg

    Anjo Vahldiek-Oberwagner, Eslam Elnikety, Nuno O. Duarte, Michael Sammler, Peter Druschel, and Deepak Garg. 2019. ERIM: Secure, Effi- cient In-process Isolation with Protection Keys (MPK). In Proceedings of the 28th USENIX Conference on Security Symposium (Santa Clara, CA, USA) (SEC’19). USENIX Association, USA, 1221–1238. https: //www.usenix.org/system/f...

  44. [44]

    Alexios Voulimeneas, Jonas Vinck, Ruben Mechelinck, and Stijn Vol- ckaert. 2022. You Shall Not (by)Pass! Practical, Secure, and Fast PKU-based Sandboxing. In Proceedings of the Seventeenth European Conference on Computer Systems (Rennes, France) (EuroSys ’22) . As- sociation for Computing Machinery, New York, NY, USA, 266–282. doi:10.1145/3492321.3519560

  45. [45]

    Anderson, and Susan L

    Robert Wahbe, Steven Lucco, Thomas E. Anderson, and Susan L. Gra- ham. 1993. Efficient Software-based Fault Isolation. In Proceedings of the Fourteenth ACM Symposium on Operating Systems Principles (Asheville, North Carolina, USA) (SOSP ’93) . Association for Com- puting Machinery, New York, NY, USA, 203–216. doi:10.1145/168619. 168635

  46. [46]

    Robert N. M. Watson, Simon W. Moore, Peter Sewell, and Peter G. Neumann. 2019. An Introduction to CHERI . Technical Report UCAM- CL-TR-941. University of Cambridge, Computer Laboratory. https: //www.cl.cam.ac.uk/techreports/UCAM-CL-TR-941.pdf

  47. [47]

    Richard West, Ye Li, Eric Missimer, and Matthew Danish. 2016. A Virtualized Separation Kernel for Mixed-Criticality Systems. ACM Trans. Comput. Syst. 34, 3, Article 8 (June 2016), 41 pages. doi:10.1145/ 2935748

  48. [48]

    Emmett Witchel, Junghwan Rhee, and Krste Asanović. 2005. Mon- drix: Memory Isolation for Linux using Mondriaan Memory Protec- tion. In Proceedings of the Twentieth ACM Symposium on Operating Systems Principles (Brighton, United Kingdom) (SOSP ’05) . Associa- tion for Computing Machinery, New York, NY, USA, 31–44. doi:10. 1145/1095810.1095814

  49. [49]

    W. Wulf, E. Cohen, W. Corwin, A. Jones, R. Levin, C. Pierson, and F. Pollack. 1974. HYDRA: The Kernel of a Multiprocessor Operating Sys- tem. Commun. ACM 17, 6 (June 1974), 337–345. doi:10.1145/355616. 364017

  50. [50]

    Jiaqin Yan, Qiujiang Chen, Shuai Zhou, Yuke Peng, Guoxing Chen, and Yinqian Zhang. 2025. EKC: A Portable and Extensible Kernel Com- partment for De-Privileging Commodity OS. In 34th USENIX Security Symposium (USENIX Security 25) . 7487–7506. https://www.usenix. org/system/files/usenixsecurity25-yan-jiaqin.pdf 17