Why HarmonyOS Microkernel Can Run Linux and Emulate Linux Containers

Microkernel Architecture

HarmonyOS uses a microkernel: only essential services such as process/thread scheduling, memory management, and basic inter‑process communication (IPC) run in kernel mode. Most system services—including device drivers and network stacks—run in user mode, isolating risky components.

Kernel mode : high‑frequency core services (process/thread management, memory management, basic IPC).

User mode : higher‑level services (device drivers, network protocol stacks).

This contrasts with Linux’s monolithic kernel, where core services reside in kernel space.

IPC Frequency and Optimisation

Mobile phones perform about 41,000 IPC calls per second; automotive systems about 7,000 per second (paper data).

Because user‑mode services communicate with the kernel very often, high‑performance IPC is critical. HarmonyOS reduces IPC overhead by:

Using RPC‑like synchronous calls in selected scenarios that bypass full scheduling and switch only stack and instruction pointers.

Introducing an intermediate isolation class (IC1) between kernel mode (IC0) and user mode (IC2); trusted, performance‑critical services run in IC1, lowering IPC cost.

Distributed IPC / RPC

The kernel implements a system call archsyscall dedicated to microkernel features, including IPC and RPC. Access to core kernel resources (e.g., ACTV and ACTVPOOL) is controlled by a capability‑based mechanism.

Distributed IPC/RPC is treated as a first‑class kernel feature, enabling cross‑device remote calls and forming the basis for a distributed Binder scenario.

Linux Compatibility

Compatibility is achieved through three core mechanisms: POSIX, an ABI shim, and the Hardware Driver Framework (HDF).

POSIX Layer

POSIX APIs are provided by the Kernel Abstraction Layer (KAL) and a lightweight musl libc. KAL abstracts the underlying kernel (LiteOS, Linux, or the HarmonyOS microkernel) and presents a uniform set of kernel capabilities.

Supported interfaces cover process/thread management, memory management, file system operations, network communication, and peripheral management.

When an application calls read(), write(), or fork(), KAL translates the request into an IPC message to the corresponding microkernel service. For example, a file‑open request becomes an IPC call to the microkernel’s file system service; thread creation becomes an IPC call to the process/thread manager.

Thus POSIX compatibility is realized jointly by user‑mode musl libc (API) and kernel‑mode KAL (bridge to microkernel services).

ABI Shim Layer

The ABI shim intercepts Linux system calls (e.g., int 0x80 or syscall) and redirects them to HarmonyOS’s IPC mechanisms. It performs two steps:

Mapping : map a Linux syscall to an internal HarmonyOS function identifier.

Reconstruction : re‑implement the syscall semantics using microkernel services and primitives.

The shim also handles signal delivery, process memory layout, and ELF loading, allowing pre‑compiled Linux binaries to run without recompilation.

Implementation uses a mechanism called lsyscall, which carries out the mapping and reconstruction inside kernel space (IC0).

Hardware Driver Framework (HDF)

HDF abstracts hardware drivers so that the same driver code can run on different kernels (HarmonyOS microkernel, Linux, LiteOS). It provides a user‑mode driver container that loads Linux ecosystem drivers into user space, preserving functionality while isolating them from the kernel.

HDF manages driver loading, lifecycle, and communication with the rest of the system; the container offers an isolated space that simulates parts of a Linux kernel environment.

Call Flow for a Linux Application

POSIX layer ( musl libc + KAL) translates the API call into microkernel service requests.

ABI shim maps the Linux syscall to internal identifiers and reconstructs its behavior via IPC.

HDF supplies compatible drivers for any required hardware interaction.

This pipeline enables Linux binaries and containers (e.g., iSulad) to run on top of the microkernel.

Design Comparisons

Kernel type : HarmonyOS – microkernel (hybrid); Linux – monolithic.

Main design goals : HarmonyOS – security, modularity, distributed operation, real‑time; Linux – generality, high performance, openness.

Core architecture : HarmonyOS – most services in user mode, some core managers in kernel mode; Linux – all core services in kernel mode.

IPC mechanism : HarmonyOS – high‑performance local and distributed IPC/RPC; Linux – pipes, sockets, System V IPC, etc.

Default scheduler : HarmonyOS – deterministic latency engine; Linux – Completely Fair Scheduler (CFS) plus FIFO, RR, Deadline.

Additional Compatibility Path

Huawei’s ExaGear binary translator can dynamically translate x86 instructions to ARM, providing another way to run x86 Linux applications on ARM‑based HarmonyOS devices.