Driver Responsibility Decisions
Four decisions that define how hardware vendors and the Nexus ecosystem share responsibility for driver software — and what happens when that responsibility is abandoned.
See also: Kernel Decisions for the ION Ring and NPL driver interface, Hypervisor Decisions for pledge enforcement and cell isolation, Packaging Decisions for the NPL package type.
D1: Vendor-Signed Driver Accountability
Status: Accepted
Context
Linux accumulates ~30M lines of kernel code. A significant portion is vendor-contributed drivers of varying quality. The authencesn crypto template vulnerability (CVE-2026-31431, "Copy Fail") demonstrated that a single logic flaw in an obscure kernel subsystem can compromise every process, container, and tenant on the system. Linux's monolithic architecture, shared page cache, and setuid privilege model made a 4-byte write into a root exploit that works across all distributions since 2017.
The fundamental problem: vendors sell hardware but the community absorbs the cost of writing, maintaining, and debugging drivers. When a vendor stops producing a chip, the driver rots. When a vendor ships a buggy driver, the kernel team carries the security burden. There is no accountability mechanism.
NexusOS takes a different position: you sell the hardware, you support the software that makes it work. But this requires solving the vendor's legitimate concern — protecting proprietary register maps, timing sequences, and microcode from competitors.
Decision
Hardware vendors are responsible for publishing and maintaining NPL driver packages for any hardware they sell for use with NexusOS:
- Vendors ship drivers as NPL (Nip Library) packages via Hinge
- Hinge provenance cryptographically verifies the driver came from the vendor, without requiring the vendor to disclose source code or IP
- NIP content-addressing verifies the driver hasn't been tampered with in transit
- Vendors retain their proprietary IP (register maps, timing sequences, microcode) inside the binary NPL package
- The ecosystem gets verifiable supply chain accountability without demanding source disclosure
Alternatives Rejected
| Option | Why Not |
|---|---|
| Linux model (community writes drivers) | Vendors free-ride on volunteer labor; no accountability for bugs; abandoned hardware becomes security liability |
| Windows model (vendor drivers, opaque) | No supply chain verification; driver signing is corporate-controlled, not cryptographic |
| Android model (HAL modules, GPL evasion) | Legal gray area; GPL circumvention through ABI boundaries; still no provenance chain |
| Full open-source requirement (OpenBSD) | Vendors refuse; hardware support stays limited; ignores legitimate IP protection needs |
Consequences
- Verifiable supply chain: Every driver's origin is cryptographically proven via Hinge
- Vendor IP protected: Binary NPL packages keep proprietary details opaque while proving authenticity
- Security accountability: When a driver has a vulnerability, the responsible vendor is identifiable
- Vendors must publish: This is a market access requirement, not a suggestion — no NPL driver, no Nexus certification (once Nexus has market position)
- Adoption challenge: Early-stage Nexus has no leverage to mandate vendor participation; must bootstrap with self-written drivers (Phase 1: Graft)
D2: RISC-V as Stable ISA
Status: Accepted
Context
A stable driver ABI requires a stable instruction set architecture underneath. If the ISA can change at a vendor's discretion, the "stable ABI" promise rests on sand. x86_64 is controlled by Intel/AMD duopoly. ARM64 is controlled by ARM Ltd, who can revoke licenses. Neither is compatible with NexusOS sovereignty.
Decision
RISC-V is the primary target ISA for NexusOS driver compatibility:
- ISA stability is governed by RISC-V International (standards body, not a corporation)
- Extensions are standardized through public processes — not unilateral vendor decisions
- Hardware vendors implement RISC-V cores and write NPL drivers against the stable ABI
- Binary compatibility across chip vendors (SiFive, StarFive, Tenstorrent, Xuantie) comes from ISA governance, not vendor goodwill
The driver ABI boundary sits at the NPL interface, not at the ISA. Two stable layers:
- ISA stable → binary compatibility across chip implementations (RISC-V International governance)
- NPL ABI stable → driver compatibility across NexusOS kernel versions (SysTable frozen ABI, K3)
ARM64 and x86_64 remain supported as secondary targets, but the vendor driver responsibility model is strongest on RISC-V where the ISA cannot be weaponized by a single company.
Alternatives Rejected
| Option | Why Not |
|---|---|
| x86_64 primary | Intel/AMD control the ISA; stability depends on corporate promise; sovereignty violation |
| ARM64 primary | ARM Ltd controls the ISA; license revocation risk; not open governance |
| Multi-ISA equal priority | Dilutes vendor driver commitments; no single stable target to mandate |
| Custom ISA | Years of compiler/tooling work; no existing hardware ecosystem |
Consequences
- ISA stability externalized: RISC-V International governs extensions, not NexusOS
- Vendor portability: NPL drivers work across any RISC-V implementation
- Sovereignty preserved: No single company controls the hardware-software interface
- Extension governance: New extensions (vector crypto, PMP enhancements) go through RISC-V International, not through NexusOS
- Secondary targets weaker: ARM64 and x86_64 don't get the full vendor-responsibility model (ISA controlled by corporations)
- RISC-V ecosystem maturity: Some peripheral and accelerator support lags behind ARM64/x86_64; gaps filled by graft (Phase 1)
D3: Driver Abandonment — Use It or Lose It
Status: Accepted
Context
Hardware vendors discontinue products. The chip stops shipping. The engineering team moves on. But the driver remains — running in production on millions of devices, accumulating security vulnerabilities, with nobody maintaining it. Linux handles this through volunteer maintainer adoption, which works until it doesn't (countable examples of unmaintained kernel drivers with known CVEs, zero active maintainers).
Decision
When a vendor abandons a hardware product, the driver enters a controlled transition to community stewardship:
Abandonment triggers (any one suffices):
- Vendor formally announces end-of-life for the hardware
- Vendor has not published a driver update in 24 months
- Vendor ceases business operations (bankruptcy, acquisition with product cancellation)
- Vendor publicly states they will no longer support NexusOS
Transition process:
- Notice period (90 days): Vendor is notified. May reassert support commitment.
- Provenance transfer: Hinge lineage is preserved — community fork inherits the vendor's original provenance chain
- Community stewardship: Driver enters the Nexus NPL commons. Any contributor may publish patches, signed with their own Hinge identity
- IP release: The original vendor's binary-only restriction is lifted. Community may decompile, reverse-engineer, and publish source for the abandoned driver without legal liability
The principle: If you profit from selling hardware, you maintain the software. If you stop, the community takes over. Use it or lose it.
Alternatives Rejected
| Option | Why Not |
|---|---|
| Linux model (volunteer adoption) | No formal process; unmaintained drivers accumulate silently; security rot |
| Perpetual binary-only (Android HAL) | Abandoned hardware becomes unmaintainable black box; security nightmare |
| Mandatory open-source from day one | Vendors refuse; reduces hardware support; ignores IP protection needs |
| Time-based expiry (auto-open after N years) | Too rigid; active products shouldn't face arbitrary deadlines |
Consequences
- No orphaned drivers: Every NPL driver has a responsible party — vendor or community
- Security continuity: Abandoned drivers get patches, not CVE accumulation
- Vendor incentive alignment: Vendors who keep selling keep controlling their IP
- Legal framework needed: IP release on abandonment requires clear license terms (Libertaria license must include abandonment clause)
- Dispute risk: Vendors may dispute abandonment status; requires adjudication mechanism
- EU regulation alignment: European ECOdesign and Right-to-Repair regulations move in this direction; NexusOS is ahead of legislation
D4: Pledge Containment for Vendor Drivers
Status: Accepted
Context
If vendors ship binary-only drivers, the ecosystem must assume those drivers may contain bugs — or may be actively malicious. The Copy Fail vulnerability demonstrated that a single flawed kernel component can compromise the entire system. NexusOS must ensure that a compromised vendor driver cannot do more damage than a buggy one.
Decision
All vendor NPL drivers run under mandatory pledge containment:
- Hard pledges (RumKV hardware): Driver's cell is restricted via Stage-2 page tables and IOMMU. A driver pledged for disk I/O cannot access the network controller, even if the driver binary is fully compromised
- Soft pledges (Rumpk software): Driver fibers are restricted to declared capabilities. Unauthorized capability requests result in fiber termination
- One-way ratchet: Drivers can only tighten their pledges, never loosen them. A compromised driver that attempts to re-enable restricted access gets terminated
- Blast radius = pledge scope: A malicious driver can only affect the resources it pledged access to. It cannot touch other cells, other drivers, or the kernel itself
This means a vendor driver has the same blast radius whether it is buggy or malicious. The containment doesn't care about intent — only behavior.
Alternatives Rejected
| Option | Why Not |
|---|---|
| Trust-based (Linux kernel modules) | Root-equivalent privilege; one bug compromises entire system |
| Code signing only | Proves origin, not behavior; signed malicious code is still malicious |
| Formal verification requirement | Impractical for vendor drivers; vendors won't submit to verification |
| Sandbox with runtime policy | Complex; policy engine becomes new attack surface |
Consequences
- Vendor driver trust is not required: The system is safe even if the driver is hostile
- Same containment for bugs and malice: Intent doesn't matter, only behavior
- Pledge granularity matters: Overly broad pledges weaken containment; driver manifests must specify minimum necessary access
- Debugging harder: Pledge violations terminate silently; vendor debugging requires pledge-aware tooling
- Performance floor: IOMMU and Stage-2 enforcement adds negligible overhead (hardware-accelerated on modern RISC-V/ARM)
Implementing document: LVDA-1.0