TenonOS: A Self-Generating LibOS-on-LibOS Framework for Time-Critical Embedded Operating Systems

TL;DR

TenonOS tackles the challenge of delivering time-critical functionality on resource-constrained embedded devices by rethinking OS and hypervisor separation as a LibOS-on-LibOS framework. It combines Mortise, a lightweight LibOS-based hypervisor, with Tenon, a real-time LibOS, and couples them with an LLM-driven orchestrator that dynamically assembles minimal runtimes from modular micro-libraries. The approach reduces the trusted computing base, lowers scheduling latency, and achieves a compact footprint while supporting mixed-criticality workloads and co-location with general-purpose OSes. Experimental results on ARM64 show about a 40% reduction in scheduling latency, a 361 KiB memory footprint, and sub-40 ms boot times, with near bare-metal real-time performance even when co-located with Linux.

Abstract

The growing complexity of embedded systems creates tension between rich functionality and strict resource and real-time constraints. Traditional monolithic operating system and hypervisor designs suffer from resource bloat and unpredictable scheduling, making them unsuitable for time-critical workloads where low latency and low jitter are essential. We propose TenonOS, a demand-driven, self-generating, lightweight operating system framework for time-critical embedded systems that rethinks both hypervisor and operating system architectures. TenonOS introduces a LibOS-on-LibOS model that decomposes hypervisor and operating system functionality into fine-grained, reusable micro-libraries. A generative orchestration engine dynamically composes these libraries to synthesize a customized runtime tailored to each application's criticality, timing requirements, and resource profile. TenonOS consists of two core components: Mortise, a minimalist micro-hypervisor, and Tenon, a real-time library operating system. Mortise provides lightweight isolation and removes the usual double-scheduler overhead in virtualized setups, while Tenon provides precise and deterministic task management. By generating only the necessary software stack per workload, TenonOS removes redundant layers, minimizes the trusted computing base, and maximizes responsiveness. Experiments show a 40.28 percent reduction in scheduling latency, an ultra-compact 361 KiB memory footprint, and strong adaptability.

Figures (10)

• Figure 1: Average architecture-specific code size per module for each operating system . Bars are grouped by module on a logarithmic scale, showing how much architecture adaptation effort each OS concentrates in different subsystems.
• Figure 2: Comparison of driver ecosystem size, architectural dependencies, and maintenance activity across different operating systems.
• Figure 3: The overall architecture of TenonOS. The left section illustrates a traditional monolithic OS-Hypervisor design. The middle section depicts the Librarization process, where system functionalities are modularized into a library pool comprising reusable components. The dynamic orchestration and composition mechanism allows rebuilding and generating TenonOS to adapt to heterogeneous hardware resources, forming a lightweight and agile LibOS on LibOS structure.
• Figure 4: Tenon extends UK-Libs (yellow) with kernel components (pink) such as a real-time scheduler, platform abstraction, and drivers, enabling real-time and networked applications across QEMU, Mortise, and bare-metal targets.
• Figure 5: Mortise architecture overview. Each vertical stack is a virtualized context managed by Mortise. The hypercall interface (yellow) provides guest and VMM access to privileged services like memory management and inter-VM communication. A shared driver layer (pink) mediates device access to physical hardware (blue)