Modular Operating System Based on Unikernel and its Construction Method

Abstract

This application proposes a modular operating system based on Unikernel and its construction method, belonging to the field of computer operating system technology. The system includes: a central scheduling module, used to call various sub-modules through a unified interface, and send service requests to the called sub-modules according to the received service requests; at the same time, it updates the application according to the corresponding error codes returned by the sub-modules; sub-modules, used to represent the corresponding functions of the Unikernel operating system, respond to the call instructions of the unified interface, and provide corresponding functional services to the central scheduling module according to the service requests, and return the corresponding error codes after the request processing is completed; and a virtualization platform, used to load the Unikernel operating system image. This system breaks through the technical limitations of the traditional static solidification of Unikernel and effectively solves the pain points of high module coupling, difficulty in expansion and maintenance in the existing Unikernel system.

Description

Technical Field

[0001] This invention belongs to the field of computer operating system technology, specifically relating to a modular operating system based on Unikernel and its construction method. Background Technology

[0002] Unikernel is a dedicated operating system technology for modern scenarios such as cloud-native and edge computing. Its core design philosophy is to build a dedicated image for each application containing only the minimum kernel functionality required for its operation. It represents an important technological evolution from traditional shared kernel containers (Linux containers) to independent virtual machine kernels (Container per VM). In the Linux container architecture, multiple containers share the same host kernel. While this design has low resource overhead and fast startup speed, kernel-level sharing also leads to insufficient isolation. Once the kernel has vulnerabilities or is maliciously attacked, all containers running on it will face security risks. To solve the isolation problem, the industry proposed the Container per VM architecture, which allocates an independent virtual machine and kernel to each container, achieving hardware-level isolation through a hypervisor. Although this significantly improves security, each virtual machine contains a complete general-purpose kernel, resulting in a lot of redundancy. This not only leads to high resource consumption and slow startup speed but also negates the original lightweight advantage of containers.

[0003] Unikernel completely resolves this contradiction through its specialized kernel design. During compilation, it statically links the application with the minimum kernel functions it depends on (such as networking, file system, process scheduling, etc.) to generate a small, independent image. This achieves strong isolation at the virtual machine level while retaining the lightweight characteristics of containers. Its image size is typically only a few MB to tens of MB, and the startup time can be reduced to milliseconds. At the same time, due to the absence of redundant kernel functions, the potential attack surface is greatly reduced, which can significantly improve the security and resource utilization efficiency of the system in cloud computing, edge computing and other scenarios.

[0004] With the development of cloud computing, virtualization technology, and microservice architecture, operating systems are gradually evolving from general-purpose to customized systems tailored to specific application scenarios. Current mainstream operating systems typically employ monolithic or modular kernel architectures, integrating numerous general-purpose functional modules to adapt to diverse application needs. However, in specific application scenarios, these operating systems often only utilize a small portion of these functionalities, leaving the remaining modules unused during operation. This leads to increased system resource consumption, longer startup times, and an expanded attack surface.

[0005] To reduce system complexity and improve operational efficiency, existing technologies have proposed the Unikernel architecture. This architecture tightly integrates applications with operating system kernel functions, generating a single executable image by trimming unnecessary kernel components, thereby achieving lightweight operation. However, existing Unikernel solutions typically employ fixed or predefined kernel function combinations, resulting in high coupling between kernel function modules and a lack of unified module management and scheduling mechanisms, making it difficult to flexibly combine and extend different kernel function modules.

[0006] In existing technologies, the functional modules within a Unikernel often interact through direct calls or static dependencies, lacking a unified registration and scheduling management mechanism. This design approach is acceptable when the system is small, but as the system's functionality increases or customization is required for different application scenarios, it leads to reduced system maintainability and increased difficulty in functional expansion and module replacement.

[0007] For example, MirageOS (Madhavapeddy, ASPLOS 2013) uses a library-based operating system approach, building the Unikernel image by statically linking applications and required kernel functions, which has a significant advantage in reducing system size. However, this approach relies mainly on static binding relationships between kernel function modules, lacking a unified module registration and scheduling management mechanism. When system functions are expanded or modules are replaced, the entire build process needs to be readjusted, resulting in insufficient flexibility.

[0008] IncludeOS (Kleen et al., OSDI 2017) employs a single-address-space library operating system architecture, statically linking applications and kernel functions to build a minimalist Unikernel image, offering significant advantages in startup speed and resource consumption. However, this approach relies on statically bound module dependencies at compile time, lacking a unified dynamic registration and scheduling management mechanism. When expanding functionality or replacing modules, the entire system image must be recompiled and rebuilt, resulting in insufficient flexibility. Furthermore, its limited support for POSIX interfaces leads to high migration costs for existing applications, and the incomplete debugging and maintenance toolchain further restricts its deployment capabilities in complex scenarios.

[0009] Besides MirageOS and IncludeOS, other mainstream open-source Unikernel projects include Rumprun, OSv, and Nanos, each with its own focus on architecture and features.

[0010] Rumprun, built on the NetBSD kernel, boasts strong POSIX compatibility, enabling existing C / C++ applications to be directly compiled into Unikernel images. This significantly lowers the barrier to cloud-native transformation of legacy systems. It also supports multiple virtualization platforms such as KVM and Xen, and enjoys a high level of community maintenance. However, compared to fully statically built solutions, its image size is relatively large, and its performance is slightly inferior, making it more suitable for scenarios where performance requirements are not extreme but rapid deployment of lightweight traditional services is needed. OSv, on the other hand, focuses on adapting to high-level language applications. Its lightweight monolithic kernel, built on C++, supports dynamic module loading, allowing interpreted language applications such as Java and Python to run without significant modifications. It also integrates seamlessly with the Docker container toolchain, offering significantly greater flexibility in feature expansion than statically built solutions. However, the trade-off is that its image size and startup speed do not reach the extreme levels of MirageOS and IncludeOS, and its kernel architecture is relatively complex. It is more suitable for microservice scenarios requiring dynamic expansion of interpreted languages. Nanos, a minimalist Unikernel developed in C, is designed for single-process applications. It boasts a small image size, fast startup speed, and good compatibility with lightweight virtual machines such as Firecracker. However, its single-process design makes it unable to support multi-process applications, limits its functional expansion capabilities, and restricts its applicable scenarios.

[0011] Overall, existing open-source Unikernel solutions all have obvious technical shortcomings: they are either limited by statically bound module relationships, resulting in insufficient flexibility in functional expansion; they increase application migration costs due to limited support for POSIX interfaces; or they limit the breadth of applicable scenarios due to a single focus in their architectural design. There is still a lack of a construction method that can efficiently and modularly manage kernel functions and support on-demand combination and unified scheduling. This provides a clear direction for the innovative design of self-developed Unikernel solutions. Summary of the Invention

[0012] To address the shortcomings of existing technologies, this application proposes a modular operating system based on Unikernel and its construction method. By modularizing the functional modules of the operating system kernel and selectively combining the required kernel components and applications according to application needs, a single executable operating system image is generated during the construction phase, thereby achieving an efficient, lightweight, highly secure, and high-performance operating environment.

[0013] In a first aspect, the present invention provides a modular operating system based on Unikernel, comprising: a central scheduling module, multiple sub-modules, applications, and a virtualization platform;

[0014] The multiple sub-modules are respectively connected to the central scheduling module, and the central scheduling module is respectively connected to the application and the virtualization platform;

[0015] The application is used to initiate service requests to the central scheduling module;

[0016] The central scheduling module is used to call various sub-modules through a unified interface, and send service requests to the called sub-modules according to the received service requests; at the same time, it updates the application according to the corresponding error codes returned by the sub-modules.

[0017] The submodule is used to represent the corresponding function of the Unikernel operating system, respond to the call instructions of the unified interface, and provide the corresponding function service to the central scheduling module according to the service request, and return the corresponding error code after the request is processed.

[0018] The virtualization platform is used to load the Unikernel operating system image, which is a single operating system image statically linked together by a central scheduling module, invoked sub-modules, and corresponding applications.

[0019] The unified interface has a unique module type identifier corresponding to each sub-module;

[0020] The central scheduling module calls each sub-module through the module type identifier.

[0021] The module type identifier is a numerical identifier.

[0022] The interaction between the sub-modules is carried out through the central scheduling module.

[0023] The state update of the submodule adopts a lock-free data structure and version number mechanism, including: setting the state update of the submodule as a lock-free circular queue, updating the state of each submodule in the lock-free circular queue through atomic CAS instructions, and after the update is completed, the version number of the submodule's state is synchronously incremented.

[0024] The unified interface adopts the description specification of the interface description language, including: defining the service interface provided by each sub-module through the interface description language, and assigning itself a unique digital module type identifier.

[0025] The Unikernel operating system image is optimized by trimming redundant device drivers and pre-initializing core sub-modules. This includes: building a toolchain to analyze the core sub-modules that the Unikernel operating system image depends on based on the application's runtime requirements; retaining only the device drivers required by the dependent core sub-modules, trimming the device drivers of the non-dependent core sub-modules, and statically linking the filtered driver code with the sub-modules and the application to obtain the Unikernel operating system image.

[0026] The submodule is compiled into a non-writable binary image when generating the Unikernel operating system image. The submodule is stored in a read-only file system and is started in read-only mount mode when the corresponding submodule is called.

[0027] Before generating the Unikernel operating system image, each submodule uses a central scheduling module to digitally sign each submodule. When starting or loading the Unikernel operating system image, the signature of each submodule is actively verified. If the signature does not match the preset value, the corresponding submodule is refused to be loaded.

[0028] The central scheduling module is also used to update the sub-modules through the update packages of the corresponding sub-modules.

[0029] Secondly, the present invention also provides a method for constructing a modular operating system based on Unikernel, comprising:

[0030] The corresponding functions representing the Unikernel operating system are divided into sub-modules;

[0031] Each submodule connects to the central scheduling module and is assigned a unique module type identifier.

[0032] The central scheduling module, the called sub-modules, and the corresponding applications are statically linked into a Unikernel operating system image, which is then loaded using a virtualization platform.

[0033] The application sends a service request to the central scheduling module;

[0034] The central scheduling module calls each sub-module through a unified interface and sends service requests to the called sub-modules based on the received service requests.

[0035] The submodule responds to the call instructions of the unified interface and provides the corresponding service to the central scheduling module according to the service request, and returns the corresponding error code after the request is processed;

[0036] The central scheduling module updates the application based on the corresponding error codes returned by the sub-modules.

[0037] Beneficial effects:

[0038] This application proposes a modular operating system and its construction method based on Unikernel. It innovatively introduces a central scheduling module within the Unikernel architecture, fundamentally changing the existing kernel organization methods that rely primarily on static linking and direct calls through unified registration, state management, and scheduling control mechanisms. This design creates a dynamic and controllable kernel function organization and operation mechanism, breaking through the limitations of the static and fixed nature of traditional Unikernel. Through centralized scheduling and module state management mechanisms, this application effectively solves the pain points of high module coupling, expansion, and maintenance difficulties in existing Unikernel systems. It is not a simple replacement or combination of existing technologies, but rather the construction of a loosely coupled, highly cohesive modular kernel system, significantly improving system maintainability and scalability, demonstrating clear technological advancement. This application can be directly deployed on mainstream virtualization platforms without additional hardware support, and can quickly adapt to various scenarios such as cloud computing, edge computing, and microservices. Its lightweight image and on-demand tailoring features can significantly reduce resource consumption and improve deployment efficiency, possessing good engineering feasibility and practical value. This application compiles Unikernel's core functional modules (such as scheduling, memory management, and security monitoring) into a single binary image file, eliminating their existence as fragmented, modifiable files. This image is fixed upon release, protected by a triple-layered mechanism of digital signature verification and read-only mounting, ensuring the core code cannot be tampered with by third parties. Furthermore, the design prohibiting direct calls between modules reduces the attack surface, significantly improving the system's trustworthiness and security in complex scenarios. Attached Figure Description

[0039] Figure 1 A block diagram illustrating the principle of a modular operating system based on Unikernel according to an embodiment of the present invention;

[0040] Figure 2 A schematic diagram of the modular operating system based on Unikernel according to an embodiment of the present invention. Detailed Implementation

[0041] The specific implementation methods of this application will be further described in detail below with reference to the accompanying drawings and embodiments.

[0042] In the traditional Unikernel operating system architecture, it is difficult to introduce a unified central scheduling module for the following reasons:

[0043] (1) The inherent limitations of static compilation:

[0044] The Unikernel operating system's core design uses static linking at compile time, packaging applications and their dependent kernel functionalities into a single binary image. This design prioritizes extreme lightweightness and performance, but it also results in: tightly coupled direct call relationships between kernel components, with no reserved interfaces for dynamic scheduling. Modules cannot be dynamically loaded / unloaded at runtime, and cannot be centrally scheduled by a single module.

[0045] 2. The conflict between performance and isolation:

[0046] To achieve ultimate performance, traditional unikernel operating systems run all code at the same privilege level (Ring 0), without the user-mode / kernel-mode switching common in traditional operating systems. Forcibly introducing a central scheduling module would add extra scheduling overhead and context switching, contradicting the lightweight and high-performance design principles of unikernel operating systems. Furthermore, the direct inter-module call pattern makes isolation and access control difficult to achieve, and introducing a scheduling module would actually increase the attack surface.

[0047] 3. Lack of ecosystem and toolchain:

[0048] Existing Unikernel toolchains (such as Rumprun and IncludeOS) are designed around "monolithic images" and lack native support for modular scheduling. Modifying them would require deep modifications to the compiler, linker, and runtime libraries, resulting in extremely high development costs and compatibility risks.

[0049] This application proposes a modular operating system and its construction method based on Unikernel for application scenarios such as cloud computing, edge computing, and the Internet of Things. Specifically, this application achieves a lightweight, highly secure, and high-performance operating environment by modularizing the core functional modules of the operating system and tightly integrating them with applications.

[0050] Example 1:

[0051] This embodiment provides a modular operating system based on Unikernel, such as Figure 1 As shown, it includes: a central scheduling module, multiple sub-modules, applications, and a virtualization platform;

[0052] The multiple sub-modules are respectively connected to the central scheduling module, and the central scheduling module is respectively connected to the application and the virtualization platform;

[0053] The application is used to initiate service requests to the central scheduling module;

[0054] The central scheduling module is used to call various sub-modules through a unified interface, and send service requests to the called sub-modules according to the received service requests; at the same time, it updates the application according to the corresponding error codes returned by the sub-modules.

[0055] The submodule is used to represent the corresponding function of the Unikernel operating system, respond to the call instructions of the unified interface, and provide the corresponding function service to the central scheduling module according to the service request, and return the corresponding error code after the request is processed.

[0056] The virtualization platform is used to load the Unikernel operating system image, which is a single operating system image statically linked together by a central scheduling module, invoked sub-modules, and corresponding applications.

[0057] In this embodiment, the Unikernel operating system architecture includes a central scheduling module, multiple sub-modules, and support for a virtualization platform. The central scheduling module manages the registration, scheduling, and resource allocation of all sub-modules, ensuring efficient and flexible interaction between modules. Each sub-module contains independent functional units that can be flexibly selected and loaded at runtime according to application requirements. As the core of the entire system, the central scheduling module is responsible for module registration, scheduling, and resource allocation. The central module interacts with each sub-module and ensures dynamic loading and unloading of modules. Each sub-module represents a specific function of the operating system, including but not limited to: process management, memory management, network protocol stack, and file system. Sub-modules communicate with each other, providing service capabilities to the central scheduling module through a unified interface and returning corresponding error codes after request processing.

[0058] For example: Submodule A (such as the file module) needs to allocate memory (by calling uk_module_send_request) from the central module (module_core.c);

[0059] 1. Locate the target submodule (memory module);

[0060] 2. Verify the status of the target submodule;

[0061] 3. Forward the request to the memory module;

[0062] The central module forwards requests to submodule B (such as the memory module), performs memory allocation, and returns the result.

[0063] The central module (module_core.c) passes submodule B to submodule A;

[0064] Submodule A obtains the memory address and continues to execute the business logic.

[0065] In this embodiment, the functionality of the Unikernel operating system is divided into multiple sub-modules, each containing only the kernel functions relevant to the target application's operation. The system is built during the build phase, where the application and the required kernel modules are statically linked into a single operating system image. This image can be directly loaded at runtime, and the various sub-modules are scheduled through a central scheduling module. The key points of this modular design are:

[0066] Functional module independence: Each submodule is responsible for implementing a specific function of the operating system, and is independent, and can be loaded and unloaded independently.

[0067] On-demand assembly: Selectively loads the required kernel submodules based on the application's needs. Unselected submodules will not participate in the build, thus achieving a customized operating system image.

[0068] Low overhead and efficient scheduling: Interaction between submodules is carried out through a central scheduling module, avoiding the switching between user mode and kernel mode in traditional operating systems, thereby reducing system call overhead and improving execution efficiency.

[0069] Specifically, the operation process of a modular operating system based on Unikernel includes the following steps:

[0070] 1. System startup phase:

[0071] Load the Unikernel operating system image into the hardware environment provided by the virtualization platform to complete the initialization of the virtual CPU, memory, and basic devices.

[0072] 2. Module registration phase:

[0073] Each submodule (i.e., each kernel functional module) registers with the central scheduling module during system startup, and the central module establishes the type and status of each module.

[0074] 3. Application request triggering phase:

[0075] The application sends a service request to the central scheduling module through a unified interface. The request includes the target module type and request parameters.

[0076] 4. Module scheduling and execution phase:

[0077] The central scheduling module assigns a sub-module based on the request type and module running status, and then sends the request to the target module for execution. After processing, the sub-module returns a standardized error code and execution result.

[0078] 5. Result Return and Status Update Phase

[0079] The central scheduling module returns the execution results to the application and updates the status of the corresponding module based on the execution results.

[0080] The unified interface has a unique module type identifier corresponding to each sub-module;

[0081] The central scheduling module calls each sub-module through the module type identifier.

[0082] The module type identifier is a numerical identifier, such as... Figure 2 As shown, each submodule is for adding personnel, searching personnel information, displaying all personnel, editing personnel information, deleting personnel information, personnel information statistics, exporting personnel information, and importing specified lists. The central scheduling module inputs a numerical identifier through a unified interface, i.e., a number, for example, inputting 1, which will call the personnel adding submodule. This method is fast, easy to implement, and conforms to the lightweight design principle of the Unikernel operating system.

[0083] The interaction between the sub-modules is carried out through the central scheduling module.

[0084] The state update of the submodule adopts a lock-free data structure and version number mechanism, including: setting the state update of the submodule as a lock-free circular queue, updating the state of each submodule in the lock-free circular queue through atomic CAS instructions, and after the update is completed, the version number of the submodule's state is synchronously incremented.

[0085] Specifically, in this embodiment, a lock-free ring buffer and atomic variables are used to manage module states. Module state updates are completed through atomic CAS (Compare-and-Swap) instructions, eliminating the need for a global mutex lock. When multiple concurrent requests update the same module state simultaneously, atomic operations ensure the atomicity of the state update, avoiding the thread blocking and context switching overhead of traditional locking mechanisms. Each module's state data is associated with a monotonically increasing version number. The version number increments synchronously with each state update; when reading the state, the version number is also read simultaneously. If the version number remains unchanged before and after the read, it indicates that the read state is consistent. Simultaneously, the system periodically generates snapshots of the module states. In the event of concurrent conflicts or system anomalies, state recovery can be achieved using snapshots corresponding to historical version numbers.

[0086] The unified interface adopts the description specification of the interface description language, including: defining the service interface provided by each sub-module through the interface description language, and assigning itself a unique digital module type identifier.

[0087] In this embodiment, the unified interface is implemented using a module description specification based on Interface Description Language (IDL). Specifically, each submodule defines its external service interface (including input parameters, output parameters, and error code definitions) through IDL and assigns itself a unique numerical module type identifier. The central scheduling module uses this module type identifier to call, register, and manage different submodules on the unified interface. Simultaneously, this description specification supports dynamic parameter types and module extensions, allowing new modules to be loaded at runtime while maintaining backward compatibility. The difference from existing technologies lies in the degree of coupling: existing interfaces are mostly adaptation layers for direct inter-module calls, while the unified interface of this application is the sole entry point for interaction between the central scheduling module and submodules. All module interactions must be forwarded through the central scheduling, achieving complete decoupling between modules.

[0088] The Unikernel operating system image is optimized by trimming redundant device drivers and pre-initializing core sub-modules. This includes: building a toolchain to analyze the core sub-modules that the Unikernel operating system image depends on based on the application's runtime requirements; retaining only the device drivers required by the dependent core sub-modules, trimming the device drivers of the non-dependent core sub-modules, and statically linking the filtered driver code with the sub-modules and the application to obtain the Unikernel operating system image.

[0089] In this embodiment, the toolchain is built by analyzing the kernel sub-modules that the target application depends on based on its runtime requirements; only the device drivers required by the dependent sub-modules are retained. For example, if the target application is a network service, only the network device driver is retained, and irrelevant device drivers such as storage and audio are removed; the filtered driver code is statically linked with the sub-modules and the application to ensure that the final image contains only the necessary driver code.

[0090] The submodule is compiled into a non-writable binary image when generating the Unikernel operating system image. The submodule is stored in a read-only file system and is started in read-only mount mode when the corresponding submodule is called.

[0091] Before generating the Unikernel operating system image, each submodule uses a central scheduling module to digitally sign each submodule. When starting or loading the Unikernel operating system image, the signature of each submodule is actively verified. If the signature does not match the preset value, the corresponding submodule is refused to be loaded.

[0092] The central scheduling module is also used to update the sub-modules through the update packages of the corresponding sub-modules.

[0093] In this embodiment, the main technical challenges and corresponding design solutions in the engineering implementation of the above-mentioned operation process are as follows:

[0094] 1. Real-time performance and isolation of module scheduling:

[0095] The central scheduling module needs to complete request routing within microseconds while ensuring complete isolation of memory and execution context between different modules. This embodiment avoids the overhead of traditional inter-process communication by using a shared memory queue and a lightweight context switching mechanism, while leveraging the memory protection capabilities of hardware virtualization to prevent unauthorized access between modules.

[0096] In this embodiment, the shared memory queue and lightweight context switching mechanism, taking the execution flow suspension / wake-up triggered by the device module's GPIO interrupt as an example, fully demonstrate the interaction between the process module, the central module, and other sub-modules:

[0097] 1. Execution Flow Creation: The file module forwards the UK_CMD_PROC_CREATE request through the central module. The process module creates the gpio_work execution flow (the entry function is GPIO read operation), requests PCB and stack memory from the memory module through the central module, and adds the execution flow to the ready queue.

[0098] 2. Execution Flow Scheduling: The process module scheduler (proc_sched) selects the gpio_work execution flow and switches contexts.

[0099] (proc_switch_context) performs a GPIO read operation.

[0100] 3. Device I / O wait: When the device module detects no data on GPIO, it forwards the UK_CMD_PROC_SUSPEND request through the central module. The process module moves gpio_work to the suspend queue, and gpio_work voluntarily yields the CPU (proc_yield).

[0101] 4. Idle scheduling: The process module schedules idle processes to run (empty loop + low-power wait), and the CPU sleeps when there are no other ready execution flows.

[0102] 5. Interrupt-triggered wake-up: When a GPIO hardware interrupt is triggered, the device module's interrupt handling function forwards the UK_CMD_PROC_WAKEUP request through the central module, and the process module moves gpio_work to the ready queue.

[0103] 6. Resume execution: The process module scheduler will next select the gpio_work execution flow, restore the context, and continue to complete the GPIO read operation.

[0104] 7. Execution flow exit: After the GPIO operation is completed, gpio_work calls proc_exit to release the stack memory and PCB through the central module, and the process module updates the execution flow count.

[0105] In terms of process management:

[0106] Relationship with the Process Management Module: Suspension and Resumption of Execution Flow

[0107] This is the core logic for implementing "asynchronous I / O" and "non-blocking operations".

[0108] I / O wait suspension: When a process (execution flow) initiates a hardware read request and the data is not ready, the device module will issue a suspension;

[0109] The request (UK_CMD_PROC_SUSPEND) is handed over from the central module to the process module, which sets the current execution flow to a sleep state and yields the CPU.

[0110] Interrupt-triggered wake-up: When a hardware interrupt occurs (such as when the network card receives data), the interrupt handling function of the device module is triggered by the central module.

[0111] Send a wake-up command (UK_CMD_PROC_WAKEUP) so that the process module can add the previously suspended execution flow back to the ready queue.

[0112] Permission verification: The process module provides the PID and user permission information of the current requester, and the auxiliary device module determines whether the process has the right to operate specific hardware (such as sensitive GPIO pins).

[0113] 2. Module state consistency maintenance:

[0114] Under multiple concurrent requests, module state updates must satisfy atomicity and visibility. This embodiment uses a lock-free data structure and version number mechanism to ensure consistency of state updates without introducing a global lock, and also achieves fault recovery through state snapshots.

[0115] 3. Compatibility and scalability of the unified interface:

[0116] To adapt to different types of applications and kernel modules, the unified interface needs to support dynamic parameter types and module extensions. This embodiment designs a module description specification based on IDL (Interface Description Language), which allows new modules to be dynamically loaded at runtime while maintaining backward compatibility of the interface.

[0117] 4. Image loading and initialization efficiency during startup

[0118] The Unikernel operating system image needs to complete hardware initialization quickly in a virtualization environment. This embodiment reduces startup time to milliseconds by removing redundant device drivers and pre-initializing core components, meeting the rapid elastic scaling requirements of cloud-native scenarios.

[0119] In terms of the security protection design of the core module, this embodiment adopts a triple protection mechanism of "solidification + signature + read-only" to achieve the goal of preventing the core functions from being illegally modified by third parties.

[0120] While existing mainstream unikernel operating systems (such as MirageOS, HermitCore, Rumprun, etc.) do employ some security protection technologies, they do not form the systematic triple protection mechanism of "fixed + signed + read-only" described in this application.

[0121] 1. Curing (Mirror Curing):

[0122] Existing Unikernel operating systems generally use "static linking at compile time" to generate a single binary image, which is a fixed form, and the code cannot be dynamically loaded or modified after the image is released.

[0123] However, the existing solidification is a static feature at compile time, not the proactive security design of "actively compiling the core module into a non-writable image + reading-only mounting at the file system level" in this embodiment.

[0124] 2. Digital signature (integrity verification):

[0125] Most existing Unikernel operating systems rely on image signing and verification mechanisms provided by upper-layer virtualization platforms (such as Xen and KVM) or cloud service providers, and rarely integrate digital signature verification logic natively into their own kernel layers.

[0126] For example, the cloud platform performs hash verification on the uploaded Unikernel operating system image, but Unikernel itself does not actively verify the integrity of its own or sub-module signatures during startup or module loading.

[0127] 3. Read-only (Read-only storage):

[0128] Existing Unikernel operating systems typically run in memory, and the image file itself is read-only, but runtime file system access (such as temporary data writing) still relies on the storage abstraction provided by the host or hypervisor.

[0129] In this embodiment, a read-only file system such as squashfs is actively used to store the core module, and a read-only mount method is used at startup to completely block direct modification of the core code by third parties.

[0130] The existing Unikernel operating system faces significant technical challenges in achieving triple protection.

[0131] Under the existing Unikernel operating system architecture, the main technical barriers to fully implementing the "fixed + signed + read-only" triple protection are as follows:

[0132] 1. The contradiction between static linking and dynamic validation:

[0133] The existing Unikernel operating system is a monolithic image with "compile-time full linking," meaning all code is determined at compile time, and modules cannot be dynamically loaded at runtime. To achieve module-level signature verification, this full-linking model needs to be broken, and a module registration and loading mechanism needs to be introduced. However, this would undermine Unikernel's core advantages of being lightweight and high-performance.

[0134] 2. No limitations on file system design:

[0135] Many existing Unikernel operations (such as MirageOS) prioritize simplicity and do not natively support a complete file system abstraction. All data access is directly mapped to the block device provided by the hypervisor through library functions. This makes it extremely difficult to use a read-only file system storage core module such as squashfs and implement read-only mounting, requiring a deep modification of the underlying storage abstraction.

[0136] 3. Performance overhead of signature verification:

[0137] Performing digital signature verification (such as RSA, Rivest-Shamir-Adleman, asymmetric encryption algorithms based on the large number factorization problem, ECC, Elliptic Curve Cryptography) during the Unikernel operating system startup or module loading phase introduces significant computational overhead, contradicting Unikernel's goal of millisecond-level startup. The existing Unikernel toolchain does not optimize for signature verification; direct integration would lead to a substantial increase in startup time, rendering it uncompetitive.

[0138] 4. Lack of toolchain and ecosystem:

[0139] Existing Unikernel build toolchains (such as the OCaml compiler and Rust cargo tools) are designed around "monolithic images" and lack native support for modular signing and read-only file system packaging. To achieve triple protection, the entire toolchain needs to be deeply modified, resulting in extremely high development costs and compatibility risks.

[0140] The technical solution adopted in this embodiment includes:

[0141] 1. Core Module Solidification and Read-Only Storage: The core functional modules of the operating system are compiled into writable binary images and stored using a read-only file system such as SquashFS. During system startup, the core modules are loaded in read-only mode, completely preventing third parties from directly modifying the core code at the file system level.

[0142] 2. Digital Signatures and Integrity Verification: Before release, all core modules are digitally signed by a trusted central management system. During system startup or module loading, the module's signature information is automatically verified. If the signature does not match or the file hash value is abnormal, the system will refuse to load the module, thereby preventing the execution of tampered malicious modules.

[0143] 3. Updates to the core module of the trusted management and control system can only be performed through a trusted central module distribution channel, and the update package also carries a valid digital signature. Third parties cannot push or replace the core module through conventional channels, ensuring the trustworthiness of the core code throughout its entire lifecycle.

[0144] Compared to existing operating system solutions based on the Unikernel architecture, this application mainly improves upon the kernel function organization, module management mechanism, and system call handling methods. The specific innovations are as follows:

[0145] (1) A method of organizing Unikernel modules by function:

[0146] This embodiment divides the kernel functions in the Unikernel operating system according to their function types, and classifies the kernel function modules into different categories such as memory management modules, file management modules, device or driver management modules, and process or thread control modules.

[0147] By setting clear module type identifiers for different categories of kernel modules, the system can uniformly classify and manage various kernel function modules, avoiding the problems of mixed kernel functions and unclear structure in the existing Unikernel operating system.

[0148] (2) A module operation status control mechanism managed uniformly by a central module:

[0149] This embodiment sets the module running status for each kernel functional module to indicate whether the module has been initialized, can handle requests, or is in an abnormal state.

[0150] The operational status of all modules is maintained and managed uniformly by the central module. The central module can decide whether to hand over a request to that module for processing based on the current status of the module, thereby improving the stability of system operation and facilitating the control and handling of abnormal modules.

[0151] (3) A kernel module invocation and scheduling method based on a unified interface:

[0152] This embodiment defines a unified operation interface for all kernel function modules, and each module provides services to the central module by implementing this interface.

[0153] When scheduling modules, the central scheduling module only needs to interact with the modules through a unified interface without needing to understand the internal implementation of the modules. This achieves loose coupling between kernel modules under the Unikernel architecture, improving the system's flexibility and scalability.

[0154] (4) A kernel internal communication mechanism that forwards data through a central module:

[0155] This embodiment stipulates that different kernel functional modules do not directly call each other. When a module needs services from other modules, the relevant requests are uniformly forwarded and scheduled by the central module.

[0156] The central scheduling module processes the request based on the module type and its running status, and returns the corresponding result. This approach reduces the direct dependencies between modules and makes the overall kernel structure clearer.

[0157] (5) Construct a unified error code-driven kernel execution result feedback mechanism:

[0158] This embodiment introduces a unified error code mechanism within the Unikernel kernel to describe the execution results of system call requests and internal module operations.

[0159] When processing requests forwarded by the central module, each kernel functional submodule returns an execution result using a uniformly defined error code to indicate whether the request was successful and the specific reason for failure. Upon receiving the error code from the submodule, the central module does not repackage or transform the error code; instead, it returns the error code to the software layer along the system call path.

[0160] The unified error code mechanism enables standardized expression of system call processing results among various functional modules within the kernel, avoiding the complexity and debugging difficulties caused by different modules using different error return methods in existing technologies. This is beneficial for improving the reliability, maintainability, and debuggability of the system.

[0161] (6) A Unikernel kernel module registration method that supports on-demand expansion:

[0162] This embodiment uses a module registration method to manage kernel function modules. Newly added modules only need to be added to the system through a unified registration process to participate in system operation, without requiring modifications to the existing kernel core structure. This method enables the Unikernel operating system to flexibly select and tailor kernel function modules according to actual application needs, improving the system's adaptability and scalability.

[0163] In this embodiment, the modular operating system construction method based on Unikernel provided by the present invention is suitable for application scenarios with high requirements for system resource consumption, startup efficiency and security. It can be widely used in cloud service providers, edge computing platforms and information systems with high requirements for system security, such as finance, government affairs and industrial control.

[0164] In cloud computing and microservice deployment scenarios, this invention can be integrated into existing cloud platforms or microservice deployment frameworks as a lightweight operating system construction method. Based on the functional requirements of different applications or service instances, kernel functional modules can be selected and combined as needed to quickly generate a Unikernel operating system image highly compatible with the application. By reducing unnecessary kernel functional modules, the boot system retains only the minimum set of functions required for application operation, thereby effectively reducing system resource consumption, shortening system startup time, reducing the system attack surface, and improving overall operating efficiency and security.

[0165] In edge computing and IoT scenarios, the modular operating system image based on Unikernel built in this embodiment is small in size and has few dependencies, making it suitable for deployment on resource-constrained computing nodes. It can improve the deployment density and operational stability of edge nodes and meet the application requirements of low latency and high reliability.

[0166] In terms of technology transfer, this embodiment can serve as a foundational operating system construction technology, and can be promoted and applied through technology licensing, integration with cloud platforms or virtualization platforms, or as a dedicated operating system solution. The relevant technological achievements can be embedded into existing cloud management systems, microservice platforms, or secure computing platforms, providing customized operating system runtime environments for different application scenarios, demonstrating good engineering feasibility and promising prospects for industrialization.

[0167] To describe the specific implementation process of this application in more detail, some examples are listed below:

[0168] Example 1 is built on the cloud computing platform Unikernel operating system:

[0169] In this example, the target application is a data processing application within a cloud computing platform. The technical solution described in this embodiment selects modules such as process scheduling, memory management, and network protocol stack from the operating system library, and compiles them together with the application to generate a single Unikernel operating system image. This image can be directly deployed and run on a KVM (Kernel-based Virtual Machine) virtualization platform, providing efficient and low-resource-consumption data processing services for the cloud computing platform.

[0170] Example 2: Minimum attack surface for high-security scenarios using the Unikernel operating system.

[0171] In this example, the target application is a system service with high security requirements, such as an identity authentication service or a key management service. When building the Unikernel operating system image, only sub-modules directly related to security services are selected, including memory management modules, encryption algorithm modules, and minimal communication modules, without introducing file system modules or other unnecessary functional modules.

[0172] Each submodule completes its registration during the construction phase. The central module only schedules registered modules, and unregistered modules cannot be called, thus structurally preventing unauthorized modules from accessing the system.

[0173] Because the system contains only a very small number of functional modules, the attack surface is significantly reduced, improving overall security. Furthermore, the Unikernel operating system image runs within a KVM virtual machine, further enhancing system isolation.

[0174] Example 3: Modular deployment of Unikernel for microservice architecture:

[0175] In this example, the target application is a microservice application in a cloud computing environment. Considering the "single function, independent deployment" characteristics of microservices, this invention constructs a corresponding Unikernel operating system image for each microservice unit. Each image contains only sub-modules directly related to the function of that microservice.

[0176] For example, for the log processing microservice, only the file management module, memory management module, and basic scheduling module are selected; for the authentication service microservice, the security module, network module, and memory management module are selected.

[0177] Each submodule must first register with the central module, and all interactions between modules are scheduled by the central module. Different microservice instances communicate through the network mechanism provided by the virtualization platform, while their respective operating system kernels are isolated from each other.

[0178] This embodiment achieves microservice-level operating system minimization, effectively reducing system resource consumption and improving the overall deployment density and security of the system.

[0179] Example 2:

[0180] This embodiment also provides a method for building a modular operating system based on Unikernel, including:

[0181] Step S1: Divide the corresponding functions representing the Unikernel operating system into sub-modules;

[0182] Step S2: Each submodule connects to the central scheduling module and assigns a unique module type identifier to each module;

[0183] Step S3: The central scheduling module, the called sub-modules, and the corresponding applications are statically linked into a Unikernel operating system image, and the Unikernel operating system image is loaded using a virtualization platform.

[0184] Step S4: The application sends a service request to the central scheduling module;

[0185] Step S5: The central scheduling module calls each sub-module through a unified interface and sends service requests to the called sub-modules according to the received service requests;

[0186] Step S6: The submodule responds to the call command of the unified interface and provides the corresponding service to the central scheduling module according to the service request, and returns the corresponding error code after the request is processed;

[0187] Step S7: The central scheduling module updates the application based on the corresponding error code returned by the sub-module.

[0188] Through the above improvements, this application has the following advantages:

[0189] High architectural flexibility: The introduction of the central scheduling module enables kernel functional modules to be dynamically registered and scheduled, breaking through the limitations of traditional static linking in the Unikernel.

[0190] Excellent resource utilization: The image contains only the minimum kernel functions required by the application, reducing redundancy, lowering resource consumption, and improving operating efficiency.

[0191] Strong security protection capabilities: Triple anti-tampering mechanisms and isolation design reduce the risk of malicious attacks and illegal tampering from the bottom layer.

[0192] Good maintainability: The loosely coupled modular design allows for system expansion and module upgrades without refactoring the core logic, significantly reducing maintenance costs.

[0193] The various embodiments in this application are described in a progressive manner. The same or similar parts between the various embodiments can be referred to each other. Each embodiment focuses on describing the differences from other embodiments.

[0194] The scope of protection of this application is not limited to the embodiments described above. Obviously, those skilled in the art can make various modifications and variations to this disclosure without departing from the scope and spirit of this disclosure. If such modifications and variations fall within the scope of equivalent technology of this disclosure, then the intent of this disclosure also includes such modifications and variations.

Claims

1. Modular operating system based on Unikernel, characterized in that, include: Central scheduling module, multiple sub-modules, applications, and virtualization platform; The multiple sub-modules are respectively connected to the central scheduling module, and the central scheduling module is respectively connected to the application and the virtualization platform; The application is used to initiate service requests to the central scheduling module; The central scheduling module is used to call various sub-modules through a unified interface, and send service requests to the called sub-modules according to the received service requests; at the same time, it updates the application according to the corresponding error codes returned by the sub-modules. The submodule is used to represent the corresponding function of the Unikernel operating system, respond to the call instructions of the unified interface, and provide the corresponding function service to the central scheduling module according to the service request, and return the corresponding error code after the request is processed. The virtualization platform is used to load the Unikernel operating system image, which is a single operating system image statically linked together by a central scheduling module, invoked sub-modules, and corresponding applications.

2. The Unikernel-based modular operating system of claim 1, wherein, The unified interface has a unique module type identifier corresponding to each sub-module; The central scheduling module calls each sub-module through the module type identifier.

3. The Unikernel-based modular operating system of claim 1, wherein, The module type identifier is a numerical identifier.

4. The Unikernel-based modular operating system of claim 1, wherein, The interaction between the sub-modules is carried out through the central scheduling module.

5. The Unikernel-based modular operating system of claim 1, wherein, The state update of the submodule adopts a lock-free data structure and version number mechanism, including: setting the state update of the submodule as a lock-free circular queue, updating the state of each submodule in the lock-free circular queue through atomic CAS instructions, and after the update is completed, the version number of the submodule's state is synchronously incremented.

6. The modular operating system based on Unikernel according to claim 1, characterized in that, The unified interface adopts the description specification of the interface description language, including: defining the service interface provided by each sub-module through the interface description language, and assigning itself a unique digital module type identifier.

7. The modular operating system based on Unikernel according to claim 1, characterized in that, The Unikernel operating system image is optimized by trimming redundant device drivers and pre-initializing core sub-modules. This includes: building a toolchain to analyze the core sub-modules that the Unikernel operating system image depends on based on the application's runtime requirements; retaining only the device drivers required by the dependent core sub-modules, trimming the device drivers of the non-dependent core sub-modules, and statically linking the filtered driver code with the sub-modules and the application to obtain the Unikernel operating system image.

8. The modular operating system based on Unikernel according to claim 1, characterized in that, The submodule is compiled into a non-writable binary image when generating the Unikernel operating system image. The submodule is stored in a read-only file system and is started in read-only mount mode when the corresponding submodule is called.

9. The modular operating system based on Unikernel according to claim 1, characterized in that, Before generating the Unikernel operating system image, each submodule uses a central scheduling module to digitally sign each submodule. When starting or loading the Unikernel operating system image, the signature of each submodule is actively verified. If the signature does not match the preset value, the corresponding submodule is refused to be loaded.

10. A method for constructing a modular operating system based on Unikernel, characterized in that, include: The corresponding functions representing the Unikernel operating system are divided into sub-modules; Each submodule connects to the central scheduling module and is assigned a unique module type identifier. The central scheduling module, the called sub-modules, and the corresponding applications are statically linked into a Unikernel operating system image, which is then loaded using a virtualization platform. The application sends a service request to the central scheduling module; The central scheduling module calls each sub-module through a unified interface and sends service requests to the called sub-modules based on the received service requests. The submodule responds to the call instructions of the unified interface and provides the corresponding service to the central scheduling module according to the service request, and returns the corresponding error code after the request is processed; The central scheduling module updates the application based on the corresponding error codes returned by the sub-modules.

Images