A kernel mode dynamic adaptation method for operating system containerization running based on eBPF

Abstract

The application discloses a kernel state dynamic adaptation method for containerized operation of an operating system based on eBPF, constructs a difference feature library based on the difference between a container system and a standard system, and generates a first list of system calls that need to be intercepted based on the difference feature library; in a host system, a first monitor in a kernel state and a first conversion service and a daemon service in a user state are constructed based on eBPF, the difference feature library is loaded and shared memory is created by the daemon service when the container is started; when a container application initiates a system call, the first monitor intercepts based on an identity and the first list, the conversion of a basic structure is completed in the kernel state, the conversion of a complex structure is triggered by the first conversion service to complete the conversion of the complex structure, and then the first monitor completes the system call, in addition, the first conversion service updates the difference feature library by analyzing kernel debugging information and address derivation, so that transparent, safe and efficient adaptation of system call parameters of the container application in a heterogeneous kernel environment is realized.

Description

TECHNICAL FIELD

[0001] The application belongs to the technical field of cross-platform compatibility, and particularly relates to a kernel state dynamic adaptation method for containerized operation of an operating system based on eBPF. BACKGROUND

[0002] Containerization relies on the native mechanism of the operating system kernel to achieve isolation and resource management. The container system running in the container usually has a system call interface difference with the host system running on the host. For example, Linux relies on POSIX standard system calls, Windows uses Win32 API and NT kernel objects, and the calling methods and parameter structures of the two are completely different, which causes the binary file in the container to be unable to run directly across the kernel. For example, the socket network call of the Linux container cannot be parsed on the Windows NT kernel. In addition, the function library and data structure alignment method of different systems are different, and even applications of the same architecture (x86_64) cannot be executed across systems. Even if the container system and the host system are based on the same kernel, there may still be incompatibility problems. For example, the kernel of the Hongmeng system is developed based on the Linux kernel, but in order to meet the needs of distributed capabilities, lightweight device adaptation, etc., the core data structure of the kernel is deeply customized. For example, in the file management module, the struct file of the Hongmeng system adds the distributed file identifier distributed_id and the extended flag field ohm_flags to the Linux host structure; in the process management module, the struct task_struct of the Hongmeng system extends the Hongmeng scheduling priority ohos_prio and the application capability identifier ability_id field; at the data structure level, the pointer offset of the struct hlist_node of the Hongmeng system is adjusted from 8 bytes to 4 bytes to adapt to the memory layout of the resource-constrained device. Therefore, when the container system runs on the host system, the difference in the kernel data structure of the two will cause the following core problems, that is, the system call parameter does not match, the pointer-intensive structure access conflicts, and the underlying hardware difference adaptation fails, etc.

[0003] The existing solution mainly modifies the kernel source code to achieve the compatible running of the container system and the host system, which increases the difficulty of compatible adaptation. Therefore, how to make the container system run stably in the host system without modifying the kernel source code is still a problem to be solved. SUMMARY

[0004] Therefore, the application provides a kernel state dynamic adaptation method for containerized operation of an operating system based on eBPF, which realizes the seamless compatibility of the container system and the host system without modifying the kernel source code.

[0005] The application provides a kernel state dynamic adaptation method for containerized operation of an operating system based on eBPF, and specifically comprises the following steps:

[0006] A difference feature library is established according to the difference between the target structure of the container system and the standard structure of the standard system, and a first list composed of system calls to be intercepted is established accordingly;

[0007] In the host system, a first monitor based on eBPF is deployed in the kernel state to intercept system calls initiated by the container application; a first conversion service based on eBPF is deployed in the user state to maintain the difference feature library; and a daemon service is deployed in the user state to load the difference feature library;

[0008] When the container application starts, the daemon service loads the difference feature library, creates a first shared memory and a second shared memory; the first conversion service generates an identity and stores it in the second shared memory; when the first monitor intercepts a system call, if the identity is in the first list, the system call data structure belonging to the target structure is intercepted to obtain the conversion data; if it is not in the first list, it is not processed;

[0009] When the conversion data is a basic structure, the first monitor performs conversion according to the difference feature library and saves the result to the first shared memory; when the conversion data is a complex structure, a data conversion event is triggered, the daemon service creates a first event FD to trigger the first conversion service to complete the conversion of the complex structure, and saves the result to the first shared memory; the first conversion service triggers a data conversion completion event, and the daemon service creates a second event FD to trigger the first monitor to read the source data and result data from the first shared memory;

[0010] The first monitor completes the system call and returns the result to the container application.

[0011] Further, the first conversion service dynamically establishes the offset between the target field and the host field according to the debugging information, and updates the difference feature library using the offset; for private fields not defined in the public header file, the offset of the private field is indirectly obtained by sequentially and individually performing address derivation through publicly accessible fields, and the difference feature library is then updated.

[0012] Further, the method of dynamically establishing the offset between the target field and the host field according to the debugging information, and updating the difference feature library using the offset, is implemented as follows: debugging information of the structure, including field offset and type, is extracted from the kernel images of the container system and the host system, and the information is saved in a text file; the offset of the target field and the host field is extracted by parsing the text file, and the offsets are classified according to the target structure and the host structure, and the difference feature library is then updated.

[0013] Furthermore, the identity identifier includes a process-private identifier and a group identifier for the container application.

[0014] Furthermore, the process-private flag is a flag set by the prctl system call when the container process starts, and the group flag is an identifier of the exclusive cgroup to which the host system adds the container application.

[0015] Furthermore, the method for intercepting system call data structures belonging to the target structure is as follows: when only the input data structure is the target structure in the difference feature library, the input data is obtained by using the entry interception method; when only the output data structure is the standard structure in the difference feature library, the output data is obtained by using the exit interception method; when both the input data structure and the output data structure exist in the difference feature library, the input data and the output data are obtained by using both the entry interception method and the exit interception method.

[0016] Furthermore, the first monitor performs the conversion according to the difference feature library in the following way: it performs type extension on the type difference field according to the difference feature library, performs offset read and write on the offset difference field according to the difference feature library, and temporarily stores the newly added field in the first shared memory according to the difference feature library.

[0017] Furthermore, the type expansion method is as follows: read source data from the file information structure of the source system using a security mechanism, determine the type requirements of the standard structure corresponding to the source data in the result system according to the difference feature library, convert the format of the source data into the format required by the result system to obtain the result data, and check whether the result data conforms to the legality rules of the result system. If it is legal, copy both the source data and the result data to the first shared memory; if it is not legal, record the error.

[0018] Furthermore, the first conversion service completes the conversion of complex structures in the following ways: First, it initializes the recursive environment, creates a hash table to record converted recursive nodes to avoid circular references, and creates a memory pool; then, it processes each recursive node through a recursive function, allocates memory in the memory pool for the recursive node corresponding to the result data, reads the recursive node data of the source data to complete the field mapping, records the current recursive node in the hash table, and if the termination condition is not met, it recursively processes the next recursive node; otherwise, it ends the recursive processing and obtains the result data.

[0019] Furthermore, the first shared memory includes an instruction area, a source data area, and a result data area.

[0020] Beneficial effects:

[0021] This invention constructs a difference feature library based on the differences between container systems and standard systems, and generates a first list of system calls to be intercepted accordingly. In the host system, a kernel-mode first monitor and a user-mode first conversion service and daemon service are constructed based on eBPF. The daemon service loads the difference feature library and creates shared memory when the container starts. When a container application initiates a system call, the first monitor determines the container to which it belongs based on its identity identifier, and then intercepts the call according to the first list. For basic structures, the conversion is completed directly in kernel mode. For complex structures, a data conversion event is triggered. The first conversion service completes the conversion of complex structures triggered by the event, and then the first monitor verifies the legality of the conversion result to complete the system call. In addition, the first conversion service updates the difference feature library by parsing kernel debugging information and address deduction, thereby achieving transparent, secure, and efficient adaptation of system call parameters for container applications in heterogeneous kernel environments. Attached Figure Description

[0022] Figure 1 This is a flowchart illustrating a kernel-mode dynamic adaptation method for operating system containerization based on eBPF, provided by the present invention. Detailed Implementation

[0023] The present invention will be described in detail below with reference to the accompanying drawings and embodiments.

[0024] This invention provides a kernel-mode dynamic adaptation method for operating system containerization based on eBPF. The core idea is as follows: A difference feature library is constructed based on the differences between container systems and standard systems, and a first list of system calls to be intercepted is generated accordingly. In the host system, a kernel-mode first monitor and a user-mode first conversion service and daemon service are constructed based on eBPF. The daemon service loads the difference feature library and creates shared memory when the container starts. When a container application initiates a system call, the first monitor determines the container it belongs to based on its identity identifier, and then intercepts the call according to the first list. For basic structures, the conversion is completed directly in kernel mode; for complex structures, a data conversion event is triggered. The first conversion service completes the conversion of complex structures triggered by the event, and then the first monitor verifies the legality of the conversion result to complete the system call. In addition, the first conversion service updates the difference feature library by parsing kernel debugging information and address deduction.

[0025] This invention provides a kernel-mode dynamic adaptation method for operating system containerization based on eBPF, the process of which is as follows: Figure 1 As shown, the specific steps include:

[0026] Step 1: Denote the containerized operating system as the container system, the operating system with a similar inheritance relationship to the container system as the standard system, and the operating system running on the host machine that is the same as or different from the standard system as the host system. Denote the modified kernel data structure in the container system compared to the standard system as the target structure, and the corresponding modified kernel data structure in the standard system as the standard structure. Record information such as structure name, header file, field name, field type, field offset, field length, alignment attribute, field name, field type, offset, length, access permissions, and nesting relationship. Analyze and determine the overall differences between the target structure and the standard structure as the structure difference, as well as the field differences that include fields, including added fields, deleted fields, fields with changed types, fields with changed offsets, field alignment differences, total structure length differences, structure alignment differences, and nesting structure differences.

[0027] A difference feature library is constructed based on the differences in structure and fields to realize the mapping between fields, pointers, alignment and byte order of the target structure and the standard structure. Based on the difference feature library, an interception list of container-related system calls that need to be intercepted is established, which is denoted as the first list.

[0028] Step 2: In the host system, in kernel mode, a system call monitor is built based on eBPF and designated as the first monitor. It is used to intercept system calls initiated by container applications. When the system call parameters are basic structures, the conversion is completed. When the parameters are complex structures, a data conversion event is triggered.

[0029] In user space, a transformation service built on eBPF is designated as the first transformation service. This service is used to maintain the difference feature library. After triggering the transformation of complex structures, it updates the first shared memory and triggers the transformation completion event.

[0030] In user space, a daemon service is built based on eBPF to load the differential signature library when the container starts, create and maintain event file descriptors (FDs), and create shared memory accessible to both the first monitor and the first transformation service. This shared memory includes a first shared memory and a second shared memory. The first shared memory contains three areas: an instruction area, a source data area, and a result data area. The instruction area stores transformation instructions, the source data area stores the data structure to be transformed, and the result data area stores the transformed data structure. Both the source data area and the result data area can store the target structure and the host structure. The second shared memory is used to store the identity identifier of the container application. The host structure is a data structure transformed from the target structure that matches the host system.

[0031] The conversion instructions include instruction ID, operation type, structure type ID, data length, offset of source data in shared memory, offset of result data in shared memory, nesting depth, and status.

[0032] In this invention, a complex structure refers to a data structure that contains nested pointers or multi-level pointers. In contrast, a data structure that does not contain nested pointers or multi-level pointers is a basic structure.

[0033] Step 3: The first conversion service dynamically establishes the offset between the target field and the host field based on the debugging information, and uses this offset to update the difference feature library; for private fields not defined in the public header file, the offset of the private field is indirectly obtained by sequentially deducing the address of each publicly accessible field, and then the difference feature library is updated.

[0034] Specifically, the offset between target fields and host fields is dynamically established based on debugging information, and the difference feature library is updated. The specific method is as follows: the debugging information of the structure is extracted from the kernel image of the container system and the host system, including field offsets and types, and this information is saved in a text file; then the text file is parsed to extract the offsets of target fields and host fields, and after classifying these offsets according to the target structure and the host structure, the difference feature library is updated.

[0035] Furthermore, in this invention, the method for extracting structure debugging information from the kernel image is to use the pahole tool.

[0036] Furthermore, for private fields that cannot be deduced through public paths, a custom eBPF helper function can be registered in the kernel module to access the private field. The first conversion service then calls this function to enable the kernel module to access the private field in a trusted context.

[0037] To ensure the kernel stability of the host system during the conversion process and reduce the risk of system crashes or privilege escalation, the first conversion service maintains a process whitelist in this invention. The first conversion service only performs subsequent operations when the container application process is in the whitelist, and authorizes the first conversion service and the first monitor to perform operations.

[0038] Step 4: When the container application starts, the daemon service starts and loads the differential signature library to create the first shared memory and the second shared memory for the container application;

[0039] The first conversion service generates a dual identifier for the container application as an identity identifier, which includes the container application's process-private identifier and group identifier, and stores them in the second shared memory;

[0040] When the first monitor detects that a container application initiates a system call, it obtains the identity of the container application from the second shared memory to determine its container. If the container is in the first list, it intercepts the current system call, obtains the input data, output data, or input data and output data of the system call as data to be converted, and executes step 5; otherwise, it ignores the current system call, does not perform the interception operation, and continues to perform the listening operation.

[0041] To further improve interception efficiency, this invention determines different interception methods based on whether the input and output data structures of the system call are target structures in the difference feature library. Specifically, when only the input data structure is a target structure in the difference feature library, the entry interception method is used to obtain the input data; when only the output data structure is a standard structure in the difference feature library, the exit interception method is used to obtain the output data; when both the input and output data structures exist in the difference feature library, both the entry and exit interception methods are used to obtain the input and output data.

[0042] The entry interception method intercepts the input data of the system call, while the exit interception method intercepts the output data of the system call.

[0043] The process-private flag can be set by the first transformation service via the prctl system call when starting the container process. The group flag can be an identifier for the host system to add the container application to its own dedicated cgroup.

[0044] Step 5: The first monitor takes the data to be converted as the source data. If the source data is a basic structure, it performs type extension on the type difference field according to the difference feature library, performs precise offset read and write on the offset difference field according to the difference feature library, and temporarily stores the newly added field in the first shared memory according to the difference feature library, and then executes step 8; otherwise, it triggers a data conversion event and executes step 6.

[0045] Among them, the type difference field refers to the difference between the data types used to describe the same core attributes in the container system and the standard system. This includes different basic types, such as 32-bit unsigned integers and 64-bit signed integers; different definitions of structure members, such as mm->tag used in the container system for process identifiers, which has a different type or storage logic than that in the standard system; and differences in semantic mapping, such as the same attribute being represented by an enumeration type in the container system, while it is represented by an integer encoding in the standard system, and so on.

[0046] To further improve the reliability of the first monitor in infrastructure conversion, this invention checks the return value of all memory read and write operations performed by the first monitor during the data conversion process. If the return value indicates an error, the error is recorded in the kernel log, and the error value is downgraded before returning a normal value.

[0047] The system containing the source data is designated as the source system, and the system containing the result data is designated as the result system. To further improve the security of memory access during type extension, the first monitor in this invention performs type extension based on the difference feature library as follows: it reads the source data from the file information structure of the source system using a secure mechanism, determines the type requirements of the standard structure corresponding to the source data in the result system based on the difference feature library, converts the format of the source data to the format required by the result system to obtain the result data, and checks whether the result data conforms to the legality rules of the result system. If it is legal, both the source data and the result data are copied to the first shared memory, and the process ends; if it is illegal, the error is recorded and the process ends.

[0048] In this invention, the first monitor determines whether the source data is a complex structure by: when the nesting depth of the source data is greater than a threshold, contains circular references, or contains array pointers, then the source data is determined to be a complex structure.

[0049] Step 6: After the daemon service detects a data transformation event, it creates a first event file (FD) for it and sends the first event FD to the first transformation service. Upon receiving the first event FD, the first transformation service first initializes the recursive environment, creates a hash table to record transformed recursive nodes to avoid circular references, and creates a memory pool. Then, it processes each recursive node one by one through a recursive function, allocates memory in the memory pool for the recursive node corresponding to the result data, reads the recursive node data of the source data to complete the field mapping, records the current recursive node in the hash table, and if the termination condition is not met, it recursively processes the next recursive node; otherwise, it ends the recursive processing, saves the transformed result data to the first shared memory, and triggers a data transformation completion event.

[0050] Step 7: After the daemon service detects the data transformation completion event, it creates a second event FD for it and sends the second event FD to the first monitor; after the first monitor receives the second event FD, it executes step 8.

[0051] Step 8: The first monitor reads the source data and result data from the first shared memory, calculates the hash value of the source data, copies it to the LRU cache with the structure type and hash value as the key and the result data as the value, completes the execution of the system call, and returns the execution result to the container application.

[0052] Example:

[0053] This embodiment uses OpenHarmony as the container system and Linux as the host system as an example. It employs a kernel-mode dynamic adaptation method for operating system containerization based on eBPF provided by this invention, resolving the system call compatibility issue between OpenHarmony and standard Linux due to differences in kernel data structures. The specific process includes:

[0054] S1. Automated extraction and modeling of kernel data structure differences.

[0055] Static analysis techniques are used to extract the differences in incompatible data structures between OpenHarmony and Linux source code, and a structured model is established to provide a precise basis for subsequent conversion. This process must cover all kernel data structures modified by OpenHarmony to ensure the completeness and accuracy of the features.

[0056] S1.1 Source Code Analysis and Structure Extraction.

[0057] S1.1.1 Target Structure Filtering: By analyzing the kernel / linux directory of the OpenHarmony source code repository (taking version 5.0 as an example), all modified data structures are filtered out, including but not limited to:

[0058] File system related: struct file (fs.h), struct inode (inode.h), struct dirent (dirent.h);

[0059] Process management related: struct task_struct (sched.h), struct signal_struct (signal.h);

[0060] Network-related: struct sock (sock.h), struct sk_buff (skbuff.h).

[0061] S1.1.2 Cross-version structure acquisition: Obtain the corresponding data structure definitions from the Linux source code repository (versions 5.4, 5.10, and 5.15) to ensure coverage of mainstream kernel versions.

[0062] S1.1.3, Structured Storage: The libclang library of the Clang toolchain is used to parse the structure definition, extract the following information, and store it in the SQLite database:

[0063] Basic attributes: structure name, header file, total length, alignment requirements (e.g., __attribute__((aligned(8))));

[0064] Field details: field name, field type (e.g., int, struct*), offset (calculated using offsetof), length, access permissions (e.g., static, private);

[0065] Nested relationship: If the field is a pointer type, record the name of the structure it points to (e.g., struct ohm_list_node* points to struct ohm_list_node).

[0066] S1.2, Differential Feature Analysis and Modeling.

[0067] S1.2.1 Field-level difference analysis: By comparing the structure fields of OpenHarmony and Linux, difference features are generated:

[0068] New fields: Mark fields unique to OpenHarmony, such as the distributed_fd of the struct file (type int, offset 32 ​​bytes).

[0069] Deleted fields: Mark fields that exist in Linux but have been deleted by OpenHarmony, such as the se (scheduling entity) of struct task_struct;

[0070] Type change: Modification of record field type, such as changing f_pos of struct file from Linux loff_t (64-bit) to OpenHarmony __u32 (32-bit);

[0071] Offset Changes: Calculate the offset differences for fields with the same semantic meaning, such as f_flags, which is offset by 16 bytes in Linux and 8 bytes in OpenHarmony.

[0072] S1.2.2, Structural-level difference analysis:

[0073] Total length differences: For example, the length of the struct file in OpenHarmony is 48 bytes, while in Linux it is 64 bytes;

[0074] Alignment differences: For example, struct inodes are aligned to 8 bytes in OpenHarmony and to 16 bytes in Linux;

[0075] Differences in nested structures: For example, the linked list pointer of struct dirent is changed from struct tdirent* to struct ohm_list_node*.

[0076] S1.2.3 Feature Model Construction: Convert the differential features into a machine-parseable JSON format.

[0077] S1.3, Version Adaptation Index Construction.

[0078] For different Linux versions (5.4, 5.10, 5.15, or even newer versions), establish a version index for structural features and record the offset changes of the same structure in different versions (e.g., structfile.f_pos is offset by 12 bytes in 5.4 and by 16 bytes in 5.15).

[0079] Develop a version identification tool that automatically determines the currently running Linux version by reading / proc / version and the kernel symbol table, providing a version matching basis for subsequent conversions.

[0080] Automated difference extraction based on Clang AST enables batch comparison of hundreds of data structures with a difference recognition accuracy of 99.9%, avoiding errors from manual analysis; the multi-dimensional difference feature model not only includes field-level differences, but also covers global features such as structure length, alignment, and nesting relationships, providing a comprehensive basis for conversion; the version-adaptive index supports cross-Linux version compatibility, solving the problem of strong dependency of eBPF programs on kernel versions.

[0081] Design and implementation of S2, eBPF-user-space collaborative transformation architecture.

[0082] By constructing a layered transformation architecture, the data structure transformation task is reasonably distributed between the eBPF kernel space and user space, breaking through the access restrictions and functional boundaries of eBPF and achieving efficient transformation of complex structures.

[0083] S2.1 Layered architecture design.

[0084] S2.1.1 Kernel-mode layer (eBPF program): Responsible for lightweight translation and system call interception, including:

[0085] Intercept system calls (such as open, read, getdents64) of the OpenHarmony process.

[0086] Handle basic field conversions (such as type conversion of f_pos);

[0087] Identify complex structures (including nested structures with multiple levels of pointers) and send a conversion request to user space.

[0088] S2.1.2 User-level layer (conversion service): Responsible for complex conversions and rule management, including:

[0089] Maintain the difference feature library and version index;

[0090] Handle complex structure transformations that eBPF cannot perform (such as recursive transformations of linked lists);

[0091] Manage translation cache and shared memory.

[0092] S2.1.3, Communication Layer: Achieves efficient interaction between kernel mode and user mode through shared memory and event notification mechanisms, including:

[0093] Shared memory area: stores translation instructions, source data, and target data;

[0094] Event fd: Used for eBPF to send a transformation request to user space, and for user space to send the transformation result to eBPF.

[0095] S2.2, Design of shared memory and communication protocol.

[0096] S2.2.1 Shared Memory Area Creation: User space creates shared memory with a size of 4MB using the mmap system call, and sets the MAP_SHARED|MAP_ANONYMOUS flags to ensure that it can be accessed by both eBPF and user-space processes. The shared memory is divided into three regions:

[0097] Instruction area (128KB): Stores conversion instructions;

[0098] Source data area (2MB): Stores OpenHarmony structured data to be converted;

[0099] Target data area (2MB): Stores the converted Linux structure data or the reverse conversion result.

[0100] S2.2.2 Conversion Instruction Structure: Defines a standardized instruction format that supports different types of conversion operations.

[0101] S2.2.3 Event Notification Mechanism: Two event file descriptors are created in user space: req_fd (eBPF request to user space) and resp_fd (user space response to eBPF). eBPF writes events to req_fd via bpf_event_output, triggering user space processing; after user space completes the conversion, it writes events to resp_fd, notifying eBPF to read the results.

[0102] S2.3 Deployment of User-Mode Transformation Service.

[0103] S2.3.1 Develop the user-space daemon process ohm_transformd, responsible for:

[0104] Load the difference feature library and version index at startup;

[0105] Create shared memory and event file descriptors, and write their addresses to the eBPF mapping (struct bpf_map_def) via bpf_map_update_elem for eBPF access;

[0106] Listen for the req_fd event and receive eBPF conversion requests;

[0107] After the transformation is complete, the result is written to shared memory and eBPF is notified via resp_fd.

[0108] S2.3.2 Implement a service self-start and fault recovery mechanism to ensure that ohm_transformd starts with the system and automatically restarts after a crash.

[0109] The layered translation architecture shifts 70% of complex translation tasks to user space, breaking through the instruction set and stack space limitations of eBPF; the standardized communication protocol and shared memory design enable efficient data exchange between kernel space and user space, with single communication latency controlled within 5μs.

[0110] S3, eBPF-based system call interception and infrastructure transformation.

[0111] By identifying the entire process from OpenHarmony processes to intercepting critical system calls and then safely completing the basic structure transformation, and by refining process marking, interception point selection, and field transformation logic, we ensure efficient adaptation of basic data structures (without complex nested pointers) while avoiding kernel access risks.

[0112] S3.1, Dual Tagging and Precise Identification of OpenHarmony Processes.

[0113] To prevent a single tag from being tampered with or misjudged, a dual identification mechanism of prctl tag + cgroup grouping is adopted to ensure that the conversion operation is performed only on the target process.

[0114] S3.1.1, Double marking at process startup.

[0115] prctl private flag: When the user-mode transformation service (ohm_transformd) starts the OpenHarmony process (such as ability_manager), it sets the process private flag through the prctl system call, assigning the task_struct->mm->tag field to the OpenHarmony exclusive identifier (such as 0xOHM_500, corresponding to version 5.0).

[0116] cgroup grouping flags: OpenHarmony processes are simultaneously added to a dedicated cgroup (e.g., / sys / fs / cgroup / ohm / ), grouped using `echo $pid > / sys / fs / cgroup / ohm / cgroup.procs`. The cgroup flag is used for verification purposes, preventing malicious modification of prctl flags.

[0117] S3.1.2, dual verification logic of the eBPF layer.

[0118] Before intercepting system calls, the eBPF program first verifies the group to which the process belongs through cgroup, and then confirms its identity through prctl marking. This dual verification ensures a 100% accuracy rate in identification.

[0119] S3.2 Precise selection and deployment of system call interception points.

[0120] Based on the core system call dependencies of the OpenHarmony program, the call types that need to be intercepted (such as file operations, process management, and network communication) are selected, and tracepoints are chosen as the interception points. This method is more stable than kprobe and has no kernel version dependency.

[0121] S3.2.1, Core System Call Interception List.

[0122] Based on the system service dependencies of OpenHarmony 5.0, determine the list of system calls that need to be intercepted, including but not limited to:

[0123] System call categories Calls to intercept Intercepted results File operations openat / read / write / getdents64 Convert struct file / struct dirent Process management fork / execve / wait4 Convert struct task_struct Network communication socket / bind / recvfrom Convert struct sock / struct sk_buff

[0124] S3.2.2 Deployment logic of eBPF interceptor.

[0125] Entry interception (sys_enter_): Intercepts system calls before they are executed and transforms the structure of parameters passed to OpenHarmony (such as the flags parameter of openat and the dirent buffer of getdents64). Taking sys_enter_getdents64 as an example, the input struct ohm_dirent buffer needs to be transformed after interception.

[0126] Exit interception (sys_exit_): Intercepts the system call after it is executed and converts the result structure returned by the Linux kernel (such as struct iovec returned by read, struct sock pointer returned by socket).

[0127] S3.3, Safe conversion and error handling of basic structures.

[0128] The basic structure refers to a structure without nested pointers or containing only a single level of pointers (such as the basic fields of struct ohm_file and struct ohm_stat). The conversion process must ensure memory access safety and handle differences in field types and offsets.

[0129] S3.3.1 Field classification and conversion logic.

[0130] Based on the difference feature library, the basic fields are divided into three categories, and conversion logic is designed for each category:

[0131] Type difference fields: For example, OpenHarmony's struct ohm_file.f_pos is __u32 (32-bit), while Linux's struct file.f_pos is loff_t (64-bit), requiring type extension conversion.

[0132] Offset difference fields: For example, OpenHarmony's struct ohm_file.flags has an offset of 4 bytes, while Linux's struct file.f_flags has an offset of 16 bytes. They need to be read and written precisely according to the offset.

[0133] New fields: such as struct ohm_file.distributed_fd (offset 32 ​​bytes) in OpenHarmony. Linux does not have a corresponding field, so it needs to be temporarily stored in shared memory for use by subsequent distributed logic, and is not written to the Linux structure.

[0134] S3.3.2 Error handling and logging.

[0135] All memory read and write operations (bpf_probe_read_kernel / bpf_probe_write_user) check the return value. If it is not 0, an error is recorded in the kernel log (via bpf_printk). For illegal values ​​(such as a negative f_pos), a downgrade process is performed, returning the default value (such as 0) to avoid kernel crashes.

[0136] Double tagging (prctl+cgroup) solves the security issues of single tagging, achieving 100% process identification accuracy; tracepoint-based interception point selection avoids kernel version dependencies of kprobe, improving compatibility by 50%; field classification and conversion + error handling mechanism ensure the security of infrastructure conversion, reducing the error rate to below 0.1%.

[0137] S4. Cooperative conversion and pointer tracking of complex nested structures.

[0138] For complex structures containing multiple levels of pointers (such as struct ohm_dirent linked lists and struct ohm_dentry hash trees), a collaborative process is designed from eBPF preprocessing to user-space recursive conversion and then to eBPF result application, which overcomes the limitations of eBPF stack space and instruction set, while avoiding memory access conflicts.

[0139] S4.1 Identification and preprocessing of complex structures.

[0140] The eBPF layer is responsible for identifying complex structures, extracting basic data, and generating transformation requests, laying the foundation for user-space processing.

[0141] S4.1.1 Criteria for determining complex structures.

[0142] Based on the nested_ptr field in the differential feature library, a structure is determined to be complex if it meets any of the following conditions:

[0143] Nesting depth ≥ 2 (e.g., struct ohm_dirent->ohm_next->ohm_next);

[0144] Includes circular references (such as the tail node of a linked list pointing to the head node);

[0145] Includes array pointers (such as struct ohm_file files[]).

[0146] S4.1.2, Preprocessing operations of the eBPF layer.

[0147] Taking the struct ohm_dirent linked list of OpenHarmony (the actual definition comes from kernel / linux / fs / dirent.h) as an example, the eBPF layer performs the following preprocessing.

[0148] S4.2, User-mode recursive conversion and handling of circular references.

[0149] The user-mode transformation service (ohm_transformd) receives the transformation request from eBPF and performs recursive transformations, focusing on resolving nested pointers and circular references.

[0150] S4.2.1, the core process of recursive transformation.

[0151] Taking the conversion of the struct ohm_dirent linked list as an example, the user-space recursive process is as follows:

[0152] Initialize the recursive environment: Create a hash table visited (to record the addresses of transformed nodes and avoid circular references) and a memory pool (to pre-allocate struct dirent nodes and reduce the overhead of dynamic allocation).

[0153] Memory pool management: A memory pool of 1024 struct dirent nodes is pre-allocated and uniformly reclaimed after conversion to avoid memory leaks;

[0154] Circular reference handling: The address of each struct ohm_dirent is recorded in the visited hash table. If the same address is encountered again, d_next is directly set to point to the converted struct dirent, and the recursion is terminated.

[0155] S4.2.2 Organizing and returning the conversion results.

[0156] After the recursion is complete, the user-space service writes the complete struct dirent linked list into the target data area of ​​the shared memory;

[0157] Update the conversion instruction status to complete (status=2) and notify eBPF via the resp_fd event.

[0158] S4.3, eBPF layer result application and caching.

[0159] After receiving the conversion results from user space, the eBPF program applies them to system call parameters and caches frequently used conversion results to improve subsequent efficiency.

[0160] S4.3.1 Application of the conversion results.

[0161] Taking sys_enter_getdents64 as an example, eBPF replaces the original struct ohm_dirent buffer with the user-space converted struct dirent linked list.

[0162] S4.3.2 Implementation of conversion cache.

[0163] Design an LRU cache (capacity 128), with the cache key being "structure type + source data hash value" and the cache value being the transformed target data; subsequent requests with the same structure will prioritize hitting the cache, without needing to trigger user-space coordination again, achieving a hit rate of over 65%.

[0164] The recursive conversion and memory pool mechanism supports nested structure conversions up to 8 levels deep, covering 99% of complex structure scenarios in OpenHarmony; the visited hash table solves the circular reference problem, avoids recursive infinite loops, and improves conversion stability to 99.5%; the LRU cache reduces the overhead of repeated coordination, and reduces the time consumption of high-frequency structure conversions by 40%.

[0165] S5, kernel version adaptation and security restriction bypass mechanism.

[0166] To address eBPF's kernel version dependencies and private structure access restrictions, a three-layer solution is adopted, from dynamic offset calculation to indirect access to public symbols and then to secure access control, to achieve cross-version compatibility and kernel security.

[0167] S5.1 adopts dynamic offset calculation, breaking through kernel version dependency.

[0168] By parsing kernel debugging information and symbol tables, the offsets of structure fields in different Linux versions can be dynamically obtained, avoiding version incompatibility caused by hard-coded offsets.

[0169] S5.1.1 Extraction and parsing of kernel debugging information.

[0170] Tool dependency: Use the pahole (Poke a Hole) tool from the dwarves toolset to extract debugging information (including field offsets and types) from the kernel structure. For example, extract the offset of the struct file in Linux 5.15 and extract the debugging information of the struct file from the kernel image.

[0171] Parsing logic: The user-space service parses the text output by pahole and extracts the field offsets. For example, the offset information of f_pos in struct_file_5.15.txt is loff_t f_pos; / 16 8 / (offset 16 bytes, length 8 bytes).

[0172] S5.1.2 Dynamic injection and use of offsets.

[0173] Offset injection: User-space services write the parsed offsets (categorized by structure type) into the eBPF map (offset_map).

[0174] Using dynamic offsets in eBPF: eBPF programs read offsets from the offset_map instead of hard-coded values, ensuring cross-version compatibility.

[0175] S5.2, Indirect access via public symbols, breaking through the restrictions of private structures.

[0176] For kernel private structure fields (such as struct file->f_op and struct task_struct->real_parent), the offset of the private field is deduced by the address of the public field, thus enabling indirect access.

[0177] S5.2.1, Public symbol derivation logic.

[0178] Taking accessing `struct file->f_op` (a private field) as an example, the address of `f_op` is deduced through the public field `struct file->f_path.dentry->d_inode->i_fop` (a public field). The specific steps are as follows:

[0179] Given the offsets of public fields, obtain the offsets of the following public fields using pahole (taking Linux 5.15 as an example):

[0180] struct file->f_path: offset 0 bytes;

[0181] struct path->dentry: offset 0 bytes;

[0182] struct dentry->d_inode: offset 8 bytes;

[0183] struct inode->i_fop: Offset 32 ​​bytes.

[0184] S5.2.2 Custom eBPF helper functions (optional extension).

[0185] For private fields that cannot be deduced from public fields, custom eBPF helper functions (requires kernel module support) can be developed to encapsulate the private field access logic.

[0186] S5.3 Secure access control ensures kernel stability.

[0187] Design a multi-layered security mechanism to limit the scope of operation of eBPF programs and prevent unauthorized access from causing kernel crashes or privilege escalation.

[0188] S5.3.1 Process whitelist and operation authorization.

[0189] The process whitelist is maintained by the user-space service, which maintains a whitelist of PIDs for OpenHarmony processes. eBPF programs are only allowed to perform structure transformations on processes that are on the list.

[0190] Operation authorization: Define a list of operations that can be executed in eBPF (e.g., only allow reading and writing struct file / struct dirent, prohibit modification of struct task_struct->cred), and reject operations that are not in the list.

[0191] S5.3.2 Memory boundary check and audit.

[0192] Memory validity verification: Before reading or writing memory, the return value of bpf_probe_read_kernel is used to determine whether the address is valid, avoiding access to null pointers or illegal addresses; Operation auditing: All structure conversion operations are recorded to / var / log / ohm_ebpf_audit.log. The log format includes: [time] PID=xxx Structure type=xxx Value before conversion=xxx Value after conversion=xxx, supporting post-event troubleshooting.

[0193] Based on pahole dynamic offset calculation, cross-version compatibility is achieved for Linux 5.4+, eliminating the need to develop separate eBPF programs for each version; the public symbol indirect access method breaks through the restrictions of private structures and does not require disabling kernel security mechanisms (such as CONFIG_BPF_STRICT_MODE); hierarchical security control (whitelist + boundary checks + auditing) ensures kernel stability and eliminates the risk of crashes or privilege escalation.

[0194] S6. Verification and dynamic optimization of conversion results.

[0195] By verifying the correctness of the conversion results in real time and optimizing the conversion strategy based on feedback data, the reliability and performance of the system can be improved.

[0196] S6.1, Conversion Result Verification Mechanism.

[0197] Field consistency check: The user-space service performs consistency verification on key fields before and after the conversion. For example, the value of f_pos of structfile should be within a reasonable range (non-negative number) after conversion, and the pid of struct task_struct should remain unchanged.

[0198] Kernel behavior verification verifies the correctness of the conversion by comparing the return values ​​of system calls (such as the number of bytes read and the file descriptor opened) in the native OpenHarmony environment and the adapted environment.

[0199] In exception handling, when verification fails, the user-space service records an error log (including structure data, conversion rules, and kernel version) and triggers a retry mechanism (up to 3 times). If it still fails, an error is returned to the application.

[0200] S6.2, Feedback-based performance optimization.

[0201] Transformation Cache Pool: User-space services maintain a transformation cache pool, storing recently transformed structures (such as struct file, struct dirent). Cache entries include the source data hash, target data, and timestamp. When the same structure is encountered again, the cached result is returned directly, achieving a hit rate of over 65%.

[0202] Hotspot rule preloading: By statistically analyzing the transformation frequency, high-frequency structures (such as struct file) and high-frequency fields (such as f_pos) are identified, and their transformation rules are preloaded into the eBPF LRU mapping to reduce rule query time;

[0203] Dynamic resource adjustment: The shared memory size and number of conversion threads are dynamically adjusted according to system load (such as CPU utilization and memory usage), and resources are increased under high load to ensure conversion performance.

[0204] S6.3, The rule base is dynamically updated.

[0205] Online upgrade mechanism: Supports rule base updates triggered by the SIGUSR1 signal of ohm_transformd, without requiring a service or eBPF program restart;

[0206] Automatic version adaptation learning: When a new Linux version is detected, the difference analysis in step 1 is automatically executed to generate new conversion rules and add them to the feature library, thereby automating version adaptation.

[0207] The multi-level verification mechanism reduces the conversion error rate to below 0.3%, ensuring the consistency of system call behavior; the intelligent caching and preloading strategy improves conversion performance by 30%, keeping the average conversion time within 10μs.

[0208] In summary, the above are merely preferred embodiments of the present invention and are not intended to limit the scope of protection of the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A kernel-mode dynamic adaptation method for operating system containerization based on eBPF, characterized in that, Specifically, the following steps are included: A difference feature library is established based on the differences between the target structure of the container system and the standard structure of the standard system, and a first list consisting of system calls that need to be intercepted is then created accordingly. In the host system, the first monitor based on eBPF is deployed in kernel space to intercept system calls initiated by container applications; the first transformation service based on eBPF is deployed in user space to maintain the difference feature library; and a daemon service is deployed in user space to load the difference feature library. When the container application starts, the daemon service loads the difference feature library and creates the first shared memory and the second shared memory; the first transformation service generates an identity identifier and stores it in the second shared memory; when the first monitor intercepts a system call, if the identity identifier is in the first list, it intercepts the system call data structure belonging to the target structure and obtains the data to be transformed. If it is not in the first list, it will not be processed; When the data to be transformed is a basic structure, the first monitor performs the transformation according to the difference feature library and saves the result to the first shared memory; when the data to be transformed is a complex structure, a data transformation event is triggered, the daemon service creates a first event FD to trigger the first transformation service to complete the transformation of the complex structure, save the result to the first shared memory, the first transformation service triggers a data transformation completion event, the daemon service creates a second event FD to trigger the first monitor to read the source data and result data from the first shared memory; The first monitor completes the system call and returns the result to the container application.

2. The kernel-mode dynamic adaptation method according to claim 1, characterized in that, The first conversion service dynamically establishes the offset between the target field and the host field based on the debugging information, and uses this offset to update the difference feature library. For private fields not defined in the public header file, the offset of the private field is indirectly obtained by sequentially deriving the address of each publicly accessible field, and then the difference feature library is updated.

3. The kernel-mode dynamic adaptation method according to claim 2, characterized in that, The method of dynamically establishing the offset between the target field and the host field based on the debugging information and using the offset to update the difference feature library is as follows: extract the debugging information of the structure from the kernel image of the container system and the host system, including the field offset and type, and save this information in a text file; parse the text file to extract the offset of the target field and the host field, and then update the difference feature library after classifying these offsets according to the target structure and the host structure.

4. The kernel-mode dynamic adaptation method according to claim 1, characterized in that, The identity identifier includes the process-private identifier and group identifier of the container application.

5. The kernel-mode dynamic adaptation method according to claim 4, characterized in that, The process-private flag is a flag set by the prctl system call when the container process starts, and the group flag is an identifier for the exclusive cgroup to which the host system adds the container application.

6. The kernel-mode dynamic adaptation method according to claim 1, characterized in that, The method for intercepting system call data structures belonging to the target structure is as follows: when only the input data structure is the target structure in the difference feature library, the input data is obtained by using the entry interception method; when only the output data structure is the standard structure in the difference feature library, the output data is obtained by using the exit interception method; when both the input data structure and the output data structure exist in the difference feature library, the input data and the output data are obtained by using both the entry interception method and the exit interception method.

7. The kernel-mode dynamic adaptation method according to claim 1, characterized in that, The first monitor performs the conversion according to the difference feature library in the following way: for the type difference field, it performs type extension according to the difference feature library; for the offset difference field, it performs offset read and write according to the difference feature library; and for the newly added field, it temporarily stores it in the first shared memory according to the difference feature library.

8. The kernel-mode dynamic adaptation method according to claim 7, characterized in that, The type expansion method is as follows: read source data from the file information structure of the source system using a security mechanism, determine the type requirements of the standard structure corresponding to the source data in the result system according to the difference feature library, convert the format of the source data to the format required by the result system to obtain the result data, and check whether the result data conforms to the legality rules of the result system. If it is legal, copy both the source data and the result data to the first shared memory; if it is not legal, record the error.

9. The kernel-mode dynamic adaptation method according to claim 1, characterized in that, The first conversion service completes the conversion of complex structures in the following ways: First, initialize the recursive environment, create a hash table to record the converted recursive nodes to avoid circular references, and create a memory pool; then process each recursive node through a recursive function, allocate memory in the memory pool for the recursive nodes corresponding to the result data, read the recursive node data of the source data to complete the field mapping, record the current recursive node in the hash table, and if the termination condition is not met, recursively process the next recursive node. Otherwise, terminate the recursive process and obtain the result data.

10. The kernel-mode dynamic adaptation method according to claim 1, characterized in that, The first shared memory includes an instruction area, a source data area, and a result data area.

Images