XOAR – Breaking the Monolithic Design of the TCB

XOAR is a modified version of the Xen hypervisor, designed to improve system security by breaking the monolithic design of the Trusted Computing Base (TCB).

• It follows the microkernel design principles to reduce the size of critical components and expose less surface to security attacks.
• XOAR assumes the system is professionally managed, and only authorized administrators have access.

---

The Problem with Traditional Xen

In traditional Xen-based systems:

• The TCB is monolithic, meaning all system services and drivers run together.
• A bug in any component, especially during booting or in guest VMs, can affect the entire system.
• Risk from guest VM attacks, initialization code bugs, and privilege abuse was high.

---

XOAR Design Goals

XOAR aims to:

1. Maintain Xen’s existing functionality and interfaces.
2. Ensure tight control of privileges – every module gets only the access it needs.
3. Minimize component interfaces – fewer ways for attackers to exploit.
4. Eliminate unnecessary sharing – or make it explicit and logged.
5. Limit runtime exposure – reduce the time components are active.
6. Allow secure audit logging.

These goals help break the monolithic TCB design, increasing isolation, modularity, and security.

---

Types of Components in XOAR

XOAR classifies system components into four types:

Type	Components	Purpose
1. Permanent	XenStore-State	Maintains system state persistently.
2. Self-destructing	PCIBack, Bootstrapper	Used only during booting, destroyed before guest VMs start.
3. Restarted on Request	XenStore-Logic, Toolstack, Builder	Start only when needed (e.g., to manage or start VMs).
4. Restarted on Timer	BlkBack, NetBack	Provide storage and network access, restarted periodically.

---

Working of Components (with Examples)

• Builder: Launches guest VMs. Very small (13,000 lines of code).
• XenStore-Logic: Manages VM metadata and configuration.
• QEMU: Emulates hardware devices for guest VMs.
• BlkBack & NetBack: Provide storage and network device access using udev rules.

Only XenStore-State is permanently active. Others either self-destruct or restart on request or timer to limit attack surface.

---

Component Sharing in XOAR

• Guest VMs do not share everything like in traditional Xen.
• They only share XenStore components.
• Every VM has private copies of BlkBack, NetBack, and Toolstack.

This reduces the risk of one VM affecting another.

---

Audit Logging and Snapshots

• Every operation like VM creation, deletion, or restart is logged in an append-only audit log stored on a secure remote server.
• Instead of rebooting, XOAR uses snapshots:
  • Components are snapshotted after initialization.
  • Uses Copy-on-Write (COW) to minimize performance impact.
  • This ensures a clean, known-good state before interaction with VMs.

---

Benefits of XOAR

Benefit	Explanation
🧩 Modularity	Isolates components to reduce attack scope.
🔐 Security	Least privilege, controlled access, no unnecessary sharing.
🧠 Auditing	Logs all VM activity securely.
🚀 Performance Control	Uses snapshots instead of reboot to reduce delay.
🔁 Component Lifecycle	Critical components run only when required, then destroyed.