Project Overview
Reclaiming Control in a Vendor-Locked Ecosystem

This experiment explores increasing user control over a consumer laptop, through selecting a hypervisor, reconfiguring the boot chain, and establishing a minimal, inspectable security boundary between the vendor firmware and user-controlled code. Using an Open-Source Operating System, isolating the untrusted firmware from everything above the hypervisor to establish a verifiable root of control to be measured.

This project addresses a specific technical challenge: reconciling platform security models designed for cryptographic integrity attestation with the user’s growing concern to mitigate risks such as telemetry, opaque update mechanisms, and vendor-imposed obsolescence through inspection, modification, and control of the physical hardware.

Consider a modern vehicle’s Engine Control Unit (ECU) where the firmware is cryptographically signed by the manufacturer and verified at ignition. While the owner can perform mechanical maintenance—replacing fluids, filters, or spark plugs—the ECU’s operational logic remains sealed. Unauthorized firmware modifications trigger failsafes or disable core functionality. This design prioritizes system integrity over user modification.

A laptop operates under a similar, but more consequential, constraint. Like the ECU, its firmware is often locked by mechanisms such as Intel Boot Guard, which uses physical fuses to verify cryptographic signatures before execution. However, unlike the ECU, a general-purpose computer has a much greater attack surface and impact of compromise from processing and storing a vastly wider range of sensitive user data; credentials, communications, financial records, creative work. In modern computing, the integrity and inspectability of the hardware's foundational code is a growing critical security concern. When the firmware layer is immutable and unauditable, the entire software stack inherits its trust boundary, regardless of the operating system’s openness or patch status.

This isn't just a philosophical problem; the practical consequence is in exclusion. The user cannot replace or audit the firmware, even when the vendor ceases support. This creates a persistent attack surface. A compromised or outdated firmware image can subvert the OS, survive reinstalls, and evade userspace detection. Any attempt to install an open, auditable alternative like Coreboot would brick the machine, turning a functional laptop into an inert slab of silicon and plastic.

This log is an exploration of my process for engineering an intervention: after the untrusted vendor firmware completes hardware initialization, we load a Type-1 hypervisor that orchestrates direct control of the CPU, memory, and I/O. Now, trust is not assumed, it is established at the moment of successful handoff. The hypervisor’s integrity depends entirely on its ability to preempt and isolate the firmware before it can influence higher layers. A claim I will falsify by checking whether the IOMMU actually remaps DMA after the hand-off. Once the hardware control is demonstrated, the hypervisor becomes the new root of enforcement through a minimal, user-controlled layer where policies for isolation, measurement, and access can be defined and monitored for verification.

This is not a circumvention of security, but a reorientation to the locus of control. We accept the firmware’s role as an untrusted loader and architect a verified transition to a transparent execution environment. The goal is measurable control: when you cannot replace the foundation, you build a verified checkpoint at its boundary — reclaiming sovereignty one abstraction layer at a time.

A successful Sovereignty Stack must be;

[ Hardware ]
|
[ Vendor Firmware ] ← Cryptographically attested, immutable, unauditable
| (Untrusted loader; executes first)
|
[ Type-1 Hypervisor ] ← Seizes control; establishes verified execution boundary
| (Trust established upon successful hardware takeover)
|
[ Dom0: Debian ] ← Sovereign host, fully managed, minimal attack surface
|_________________
|                 |
[ DomU: Browser ] [ DomU: Work VM ] ← Contained, monitored, policy-enforced

The default configuration of modern laptops grants the OEM a degree of control that is inconsistent with traditional notions of hardware ownership. Even after payment, control remains with the Original Equipment Manufacturer (OEM). Firmware is cryptographically sealed. Telemetry is embedded. “End of support” means forced obsolescence — not for the hardware, but for the orginal transaction agreement and your right to use your property securely.

This project defines what true ownership looks like in technical terms. The Sovereignty Stack is proven with six measurable properties that, when satisfied, transform a consumer laptop from a black-box appliance into a sovereign computing platform.

Each property answers a simple question: What must be true for me to trust this machine with my data, my work, and my autonomy?

These are not arbitrary checkboxes. They are the minimum viable specification for a machine that respects its owner.

Each property is a line in the sand. Cross one, and ownership is compromised.

Each property will be tested, documented, and — where possible — automated. Failures will be analyzed. Workarounds will be published. Successes will be reproducible.

Because in 2025, ownership is not assumed.

It is proven.

The articles in this series document the procedures required to build a system that satisfies the sovereignty properties defined above. Presented in logical sequence, they serve as a practical demonstration of achieving measurable control over consumer hardware, from establishing a verified host to configuring hardware isolation.

• Materials, Glossary, Command Cheatsheet
• Source repo: https://github.com/calebc42/sovereignty-stack