Security isolation method for edge computing nodes of Internet of Things

Abstract

The invention relates to the technical field of computer security, in particular to a security isolation method for an edge computing node of the Internet of Things, which comprises the following steps of: identifying a trust domain in the edge computing node of the Internet of Things, defining a sensitive data source, and generating a sensitive data identifier set, and based on the sensitive data identifier set, planning minimum central processing unit time and maximum memory bandwidth for each isolation domain to form an isolation domain resource limit, and establishing initial security isolation configuration. According to the method, the identification mechanism based on the sensitive data identification set is introduced into the edge computing node of the Internet of Things, the definition of the trust domain can be realized, and the resource limit is constructed in combination with the minimum central processing unit time and the maximum memory bandwidth of each isolation domain, so that the basic distribution mode of computing resources is restrained, and the computing efficiency is improved. And resources are prevented from being occupied by high-frequency low-priority tasks. After a data entry is positioned on a system level and stain marks are applied according to sensitive attributes, sensitive data images have identifiable features on a memory level.

Description

Technical Field

[0001] The present invention relates to the field of computer security technology, and particularly to a security isolation method for Internet of Things (IoT) edge computing nodes. Background Art

[0002] The security isolation method for IoT edge computing nodes refers to a method in the IoT architecture that, for complex scenarios such as multi-tenant data streams, multi-task processing, and resource competition in edge computing nodes, uses an isolation mechanism to distinguish and process data and computing activities with different trust levels, avoiding risks such as sensitive data leakage, unauthorized access, and interference.

[0003] Existing technologies usually perform holistic isolation processing on multi-tenant data streams and task execution behaviors in edge computing nodes, mainly relying on static policies to complete the division of isolation boundaries. In the face of scenarios such as dynamic data migration, changing processing frequencies, and complex resource competition, it is easy to cause isolation policy failures or resource configuration mismatches. Since there is no mechanism for real-time identification of sensitive data and its propagation paths, it is difficult to accurately determine whether it is an illegal behavior when data is exchanged between different trust domains, thereby increasing the risk of sensitive information leakage. For example, in high-frequency data acquisition scenarios, when multiple tasks compete for the same interface bandwidth, the existing methods cannot identify which task is a high-sensitivity task, so it is arranged to execute with a low priority, resulting in too long processing delays or even data caches being overwritten. Therefore, improvements are needed. Summary of the Invention

[0004] The purpose of the present invention is to solve the deficiencies existing in the prior art and propose a security isolation method for IoT edge computing nodes.

[0005] To achieve the above purpose, the present invention adopts the following technical solution. A security isolation method for IoT edge computing nodes includes the following steps: Identify trust domains and define sensitive data sources in the IoT edge computing node, generate a sensitive data identification set, plan the minimum central processing unit time and maximum memory bandwidth for each isolation domain based on the sensitive data identification set to form an isolation domain resource quota, and establish an initial security isolation configuration; Invoke the regulations of the sensitive data identification set in the initial security isolation configuration, locate the data items entering the system from a specified entry at the operating system kernel layer, obtain a list of data entry points to be marked, and apply a taint mark to the data items based on the list of data entry points to be marked to obtain a marked sensitive data image; Track the replication and computation path of the marked sensitive data image in the memory of the IoT edge computing node, record the state of transmission between different trust domains, form a real-time data flow taint state, and judge the behavior of data flowing out of the trust domain or writing into the taint sink based on the real-time data flow taint state and checkpoints and purification rules, and generate data access audit records; Refer to the isolation domain resource limit in the initial security isolation configuration to allocate the central processing unit time of the isolation domain, obtain the current domain resource occupancy value, adjust the computing resource supply of the isolation domain based on the current domain resource occupancy value and combine the data access audit record, and establish the adjusted isolation domain operating parameters.

[0006] Preferably, the steps of obtaining the initial security isolation configuration are: Traverse the process call path corresponding to each processing task in the IoT edge computing node, parse the device access records and driver loading behaviors of the process in the kernel state layer by layer, match the data identification bit pattern in the bus transmission process connected to the physical port, screen the access segments pointing to the unified address space and compare them with the system permission mapping table to obtain the mapping relationship between the trust domain and the sensitive data source; Calculating resource limits according to a mapping relationship between the trust domain and the sensitive data source; Based on the resource limit of each isolation domain, read the characteristic tags of each domain in the mapping relationship between the trust domain and the sensitive data source, combine the standard processor clock frequency and memory channel allocation parameters, set the minimum time period of the central processor and the maximum read and write value limit of the memory for each trust domain, and establish the initial security isolation configuration.

[0007] Preferably, the steps of obtaining the list of data entries to be marked are: Based on the sensitive data identification set in the initial security isolation configuration, scan the system call table and driver entry mapping table registered in the kernel state of the operating system, extract all function pointer entries associated with user state input data and corresponding file descriptor binding information, identify the entry address with the ability to access sensitive data, and obtain an information list; According to the information list, compare the protocol fields, port numbers and function call sequences in the data path, analyze the source interface, application context and memory mapping segment information of the data input item by item, exclude the entry items that do not meet the data identification trigger conditions, and form an entry address sequence; Based on the entry address sequence, the entry hierarchical relationship is reorganized according to the order of the function stack frames called in the data inflow path, and the stack items with repeated references and invalid transfer nodes are removed to generate a list of data entries to be marked.

[0008] Preferably, the steps of obtaining the labeled sensitive data image are: Traverse each entry address in the list of data entry to be marked, intercept the corresponding system call trigger behavior during the kernel-mode processing, extract the data content filled in the receive buffer and the incoming timing information, and retrieve the target data features field by field according to the set field matching rules to form a set of data items to be marked with tags; According to the set of data items to be marked with tags, call the page table mapping interface to locate the mapped page frame number and the corresponding virtual address range of each data item in the physical memory, and combine the operation range of the data item in the system call stack to set the taint flag bit and register it in the taint propagation linked list maintained by the kernel, generating a list of data content segments with identifiers; Based on the list of data content segments with identifiers, perform integrity splicing on the original data items to which each segment belongs, perform page boundary reorganization and memory continuity check on cross-page data blocks, and construct all data content containing taint marks into a storage object in the form of a structured image, generating a marked sensitive data image.

[0009] Preferably, the step of obtaining the taint state of the real-time data stream is as follows: Scan the page frame mapping records of the marked sensitive data image in the physical memory of the IoT edge computing node, retrieve the access logs of the page table and virtual memory manager in the operating system, locate the memory address transfer relationship and thread call context information associated with the replication behavior of the data image between different processing threads, and generate a replication path sequence of the sensitive data image; According to the replication path sequence of the sensitive data image, parse the function call stack, processor core allocation record and kernel task scheduling track associated with each path, identify the task scheduling boundary passed by the image data when switching between different trust domains, and extract the trust domain switching time point and the corresponding data access status identifier to form a cross-trust domain data transfer status sequence; Based on the cross-trust domain data transfer status sequence, compare the corresponding image mark status, register content change situation and data buffer call permission during each trust domain switching process, mark the status of the data segments transmitted across domains, and integrate the data transmission records with changed or unchanged original taint marks in all propagation paths to generate the taint state of the real-time data stream.

[0010] Preferably, the step of obtaining the data access audit record is as follows: Traverse all marked data paths in the taint state of the real-time data stream, extract the memory address mapping relationship, thread operation stack call information and the corresponding trust domain boundary identifier contained in each path, and combine the set checkpoint list to identify and mark the node positions where each data item crosses the trust domain to obtain the cross-domain transmission records in the data path; Calculating a violation determination value of sensitive data transmission behavior according to the cross-domain transmission record in the data path; Based on the violation judgment value, a threshold judgment condition is set. If the violation judgment value exceeds the threshold, it is determined that there is a behavior of data flowing out of the trust domain or writing to the taint sink. The identification number of the data path, the transmission behavior timestamp and the associated thread control block are recorded together to generate a data access audit record.

[0011] Preferably, the step of obtaining the current domain resource occupancy value is: Retrieve the central processing unit time parameters set for each isolation domain in the initial security isolation configuration, divide the total allocatable time slots of the central processing unit into a corresponding number of cycle segments according to the mapping relationship between the isolation domain identifier and the trust domain to which it belongs, allocate cycle durations in combination with the current processor core state and the task priority order in the scheduling queue, and generate an isolation domain processor time allocation list; According to the isolation domain processor time allocation list, the number of context switches of active processes in each isolation domain, the start and end timestamps of processor occupancy, and the number of instruction cycles consumed by each task execution are monitored in real time, all data are aligned and mapped with the current processor allocation cycle, and idle cycles and scheduling waiting segments are eliminated to form an isolation domain task cycle usage detailed list; Based on the isolation domain task cycle usage details table, the central processing unit time occupied by each isolation domain in the current scheduling cycle is counted, the intermediate states of cross-cycle tasks and repeated measurement items in continuous cycles are merged, the processor occupancy of each isolation domain in the current period is extracted, and the current domain resource occupancy value is obtained.

[0012] Preferably, the step of obtaining the adjusted isolation domain operating parameters is: Analyze the usage details of each processor time slice in the current domain resource occupancy value, extract the corresponding process execution frequency, context switching times and idle cycle ratio, and combine the number of illegal data transmission events and the occurrence time distribution recorded in the data access audit record to generate a resource load correlation indicator set of the isolation domain in the current scheduling cycle; Calculating a resource adjustment coefficient for each isolation domain based on a resource load associated indicator set of the isolation domain in a current scheduling period; Based on the resource adjustment coefficient, combined with the set processor time baseline value and memory bandwidth upper limit, the processor time and bandwidth allocation ratio is linearly scaled, the updated computing resource configuration is written into the isolation domain operation parameter table, and the adjusted isolation domain operation parameters are established.

[0013] Compared with the prior art, the advantages and positive effects of the present invention are: By introducing an identification mechanism based on a sensitive data identification set in the Internet of Things edge computing node, the present invention can define the trust domain, and construct resource quotas by combining the minimum central processing unit time and the maximum memory bandwidth of each isolation domain, so as to constrain the basic distribution mode of computing resources and avoid resources being occupied by high-frequency and low-priority tasks. After locating the data entry at the system level and applying a taint mark according to the sensitive attributes, the sensitive data image can have recognizable features at the memory level. Combining the dynamic tracking of the replication path and the operation path enables the sensitive data to have the ability to record the state during the process of crossing the trust domain, forming a data management mechanism with controllable propagation trajectory. Through the comparative analysis of data transmission behaviors and purification rules, it is possible to identify whether the data is transmitted across boundaries or illegally written to key nodes, and accordingly construct an audit record of access behaviors, improving the monitorability of sensitive data flow. Based on the actual resource occupancy value, incorporating the behavior audit results into the resource adjustment judgment logic and dynamically correcting the computing resource supply structure further ensures that high-risk areas have sufficient response capabilities and low-risk areas maintain a resource-conservative state, realizing a closed-loop feedback control of the linkage between resource scheduling and security status. In this way, while ensuring that data is not illegally transmitted, the stable scheduling ability of the system is enhanced. BRIEF DESCRIPTION OF THE DRAWINGS

[0014] Figure 1 It is a schematic diagram of the steps of the present invention. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0015] In order to make the objectives, technical solutions and advantages of the present invention clearer, the present invention will be further described in detail below with reference to the drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present invention and are not used to limit the present invention.

[0016] Please refer to Figure 1 , the present invention provides a technical solution, a security isolation method for an Internet of Things edge computing node, including the following steps: Identify the trust domain and define the sensitive data source in the Internet of Things edge computing node, generate a sensitive data identification set, plan the minimum central processing unit time and the maximum memory bandwidth for each isolation domain based on the sensitive data identification set to form the isolation domain resource quota, and establish an initial security isolation configuration; Invoke the regulations of the sensitive data identification set in the initial security isolation configuration, locate the data items entering the system from the specified entry at the operating system kernel layer, obtain the list of data entries to be marked, and apply a taint mark to the data items based on the list of data entries to be marked to obtain the marked sensitive data image; Track the replication and operation paths of the marked sensitive data image in the memory of the IoT edge computing node, record the status during transmission between different trust domains, form a real-time data flow taint status, and based on the real-time data flow taint status, check against checkpoints and purification rules to judge the behavior of data flowing out of the trust domain or being written to the taint sink, and generate data access audit records; Allocate the central processing unit time of the isolation domain with reference to the resource quota of the isolation domain in the initial security isolation configuration, obtain the current domain resource occupancy value, and based on the current domain resource occupancy value, combined with the data access audit records, adjust the computing resource supply of the isolation domain and establish the adjusted isolation domain operation parameters.

[0017] The steps for obtaining the initial security isolation configuration are as follows: Traverse the process call paths corresponding to each processing task in the IoT edge computing node, layer by layer analyze the device access records and driver program loading behaviors of the process in the kernel state, match the data identification bit patterns during the bus transmission process connected to the physical port, screen out the access segments pointing to the unified address space and perform a combined comparison with the system privilege mapping table to obtain the mapping relationship between the trust domain and the sensitive data source; According to the mapping relationship between the trust domain and the sensitive data source, calculate the resource quota, and the calculation formula is: ; Among them, represents the resource quota of the th isolation domain, represents the average memory access rate (unit: MB / s) of the data path in the th trust domain, represents the average rate of sensitive data access (unit: MB / s) in the th trust domain, is the standard reference bandwidth value (unit: MB / s) used to normalize the rate index, represents the average processing cycle of all threads in the trust domain (unit: s), is the set reference processing time (unit: s), represents the number of executions of valid instructions in this trust domain per unit time (unit: times / s), is the preset reference execution rate (unit: times / s), represents the average square of the waiting time caused by thread blocking in this trust domain (unit: s²), represents the average number of context switches of the scheduling thread in the current domain plus the number of active processes (unit: pieces); Based on the resource quota of each isolated domain, read the feature tags of each domain in the mapping relationship between the trusted domain and the sensitive data source, and combine the standard processor clock frequency and the memory channel allocation parameters to set the minimum time period of the central processing unit and the maximum read / write value limit of the memory for each trusted domain, and establish an initial security isolation configuration.

[0018] Specifically, the system first starts to deeply trace each processing task running on the Internet of Things edge computing node. Using kernel detection tools, such as extended Berkeley packet filter (eBPF) programs or kernel modules, it is mounted on key system call entry points and scheduler events to capture the process identifiers (PIDs) related to each task and their parent-child relationships, forming a complete process call chain. Then, for each process in the call chain, especially those processes that need to execute with elevated privileges or directly interact with hardware, the system will analyze its behavior records in the kernel state. This includes monitoring its read / write operations on device files, memory mapping requests (mmap), and the registration and execution of interrupt handlers through audit logs or real-time kernel event streams (such as ftrace). At the same time, check the information in the kernel log about the dynamic loading and initialization of drivers (for example, drivers for specific sensors or communication interfaces), identify the binding relationship between the driver and the hardware device (such as USB devices, network interface cards). Furthermore, the system analyzes the bus (such as PCIe, USB) transmission activities associated with specific physical ports (for example, Ethernet port ETH0, serial port TTYUSB1). By checking the headers of bus protocol data units (PDUs) or specific offsets, match the predefined data identification bit patterns, which may represent specific data types or sources (for example, measurement data packets from specific sensors will contain fixed device IDs or data format identifiers), and identify the sensitive data streams flowing through these ports. Subsequently, the system checks the memory access patterns of these processes, especially those that access memory segments shared by multiple processes or mapped to the same physical address area. By analyzing the page table entries (PTEs) and virtual memory area (VMA) structures, filter out the memory access operations that point to the same physical address space. Finally, combine and compare these processes with shared memory access behavior and handling sensitive data with their permissions defined in the system privilege mapping table (this table defines the access permissions of each process or user to system resources, including device files, memory areas, system calls, according to predefined system security policies, such as role-based access control (RBAC) rules or mandatory access control (MAC) policies such as SELinux / AppArmor policies), and confirm which process combinations or execution paths constitute the trusted domains that can access specific sensitive data sources (such as dongles connected to port X, keys stored in specific memory areas). Finally, organize and output the clear mapping relationship table between these trusted domains and the sensitive data sources they can access.

[0019] Formula: , and the benefits of the formula are as follows: The formula comprehensively evaluates the various resource requirements of the isolation domain and the constraints imposed by the system on it. It not only considers bandwidth and CPU time but also incorporates factors such as processing efficiency, blocking latency, and scheduling overhead, enabling a more refined and dynamic calculation of the resource quota required for each isolation domain , the first term focuses on the ratio of the normalized memory bandwidth requirement ( and ) to the normalized processing cycle ( ), which reflects the resource requirement characteristics of data-intensive tasks. The second term focuses on the compute-intensive characteristics ( ) and the smoothness of task execution ( , ). By combining these two aspects, the formula can allocate reasonable resource upper limits for different types of isolation domains (such as heavy-computation, heavy-I / O, or hybrid types), providing an accurate basis for subsequent resource isolation and scheduling, which helps to improve the overall system resource utilization and task execution performance while ensuring secure isolation. The squared term of parameter , and the square root term of enhance the sensitivity to high bandwidth requirements, highly sensitive data access, and long blocking times, making the resource allocation more adaptable to extreme situations. The use of absolute values ensures that the contribution value of the second term is positive

[0020] represents the average memory access rate (unit: MB / s) of the data path in the th trust domain. This parameter reflects the demand intensity of the isolation domain for memory bandwidth in regular data processing (non-specific sensitive data). The acquisition method is as follows: Through a performance monitoring tool (such as the perf tool in Linux or a custom kernel monitoring module), sample the total number of bytes read and written by all processes in the isolation domain within a period of time (for example, a monitoring window set to 60 seconds), divide the total number of bytes by the monitoring time (60 seconds) to obtain the average rate. For example, within a monitoring period, all processes in domain read and wrote a total of 12000MB of memory data, then .

[0021] represents the average rate (unit: MB / s) of sensitive data access in the th trust domain. This parameter specifically focuses on the access frequency of the isolation domain to the identified sensitive data. The acquisition method is as follows: Based on the obtained "mapping relationship between the trust domain and the sensitive data source", use memory access tracking techniques (such as memory breakpoints, page access markers) to monitor the isolation domain The access of the in-process to the sensitive data sources listed in the mapping table (specific memory address ranges, buffers associated with file handles), accumulates the number of bytes of sensitive data accessed within the same monitoring window (60 seconds), and then divides by the monitoring time. For example, the monitoring discovery domain accessed 3000MB of sensitive data within 60 seconds, then .

[0022] is the standard reference bandwidth value (unit: MB / s). This parameter is used as a normalization benchmark to eliminate the influence of differences in the memory bandwidth capabilities of hardware platforms on the calculation results. The acquisition method is as follows: query the hardware specification manual of the edge computing node to obtain its theoretical maximum memory bandwidth, or measure the peak memory bandwidth obtained through a memory bandwidth benchmark tool (such as STREAM benchmark) under low system load, and set it as the reference value. For example, the theoretical bandwidth of the dual-channel DDR4-2400 memory of an edge node is about 38.4GB / s. Considering the actual efficiency, a slightly lower measured value or specification value can be set. For example, set (i.e., 20GB / s).

[0023] represents the average processing cycle of all threads in the trust domain (unit: s). This parameter reflects the average execution time length of tasks within the domain. The acquisition method is as follows: monitor the isolated domain the time spent by all threads from the start of execution to the completion of a typical processing unit (such as processing a request, completing a computing task) within, collect sample data and calculate the average value. For example, by analyzing the processing time records of the past 1000 tasks, the average processing cycle is obtained as (i.e., 50 milliseconds).

[0024] is the set reference processing time (unit: s). This parameter is used to normalize the processing cycle and represents a standard or expected task processing time benchmark. Its setting basis can refer to the system's requirements for task response time or a standard time slice length. For example, in scenarios with low real-time requirements, a general reference processing time can be set, such as (i.e., 100 milliseconds). This value should be adjusted according to the specific application scenario. For example, for control tasks that require quick response, should be set smaller.

[0025] represents the number of executions of valid instructions in this trust domain per unit time (unit: times / s). This parameter measures the computational intensity of the isolated domain. The acquisition method is as follows: use the performance counter of the processor to monitor the isolated domain The total number of instructions executed by the in-process within a unit of time (e.g., 1 second) (such as collecting the instructions event through the perfstat command). For example, the monitoring display domain executed instructions within 1 second, then .

[0026] is the preset reference execution rate (unit: times / s). This parameter serves as the benchmark for computing power and is used to normalize the instruction execution rate. The acquisition method is as follows: Based on the nominal performance of the edge computing node processor (e.g., the peak GIPS of a single core) or obtaining a reference value by running a standard computing benchmark (such as Dhrystone). For example, if the peak performance of a single core of the processor is approximately 10 GIPS, can be set as a reference, representing the computing power under medium to high load.

[0027] represents the square of the average waiting time caused by thread blocking within this trust domain (unit: s²). This parameter reflects the waiting situation caused by reasons such as I / O and lock contention during task execution. The square operation amplifies the impact of long waiting times. The acquisition method is as follows: Monitor the thread state transitions within the isolation domain , record the time difference (i.e., the waiting time) each time the thread enters the blocked state (such as waiting for I / O to complete or waiting for a lock) from the running state to the resumed running state, and collect all waiting time samples within a statistical period (e.g., 60 seconds) , calculate the average of the squared values of these waiting times. For example, a total of 500 blocking events were recorded within 60 seconds, and the waiting times were respectively , and after calculation, is obtained, then .

[0028] represents the sum of the average number of context switches of the scheduled threads in the current domain and the number of active processes (unit: pieces). This parameter comprehensively reflects the scheduling overhead and concurrency level of the isolation domain. The acquisition method is as follows: Monitor the total number of context switches within the isolation domain within a scheduling period (e.g., 1 second) (the number of switches within the domain can be obtained through the change of the ctxt item in / proc / stat or by perf monitoring the sched:sched_switch event), and at the same time, count the average number of processes / threads in the running or runnable state (the number of active processes) within this period. The sum of the two is , for example, domain had 200 context switches within 1 second and an average of 5 active processes, then .

[0029] Calculation process: Taking the th isolation domain as an example, substitute the parameter values obtained previously for calculation: ; The calculation process is as follows: Calculate the first part (terms related to bandwidth and processing time): Sum of squared normalized bandwidth: , normalized processing period: , result of the first part: ; Calculate the second part (terms related to calculation, blocking, and scheduling): Normalized instruction execution rate: , normalized impact of blocking waiting time: , difference between rate and waiting time: , absolute value of the result of the second part (before dividing by ): , divide by scheduling overhead and activity: , final result of the second part (absolute value): ; Calculate the final resource limit : ; ; This result indicates that: The resource limit of the th isolation domain is calculated as, which is a quantitative metric that synthesizes information from multiple dimensions such as the memory bandwidth usage intensity, sensitive data access frequency, task processing cycle, computational load, blocking situation, and scheduling overhead of this domain. This value itself is a relative and normalized measure. The larger the value, the higher the demand of this isolation domain for system resources (especially CPU time and memory bandwidth) or the more attention its operating characteristics (such as high blocking and high scheduling overhead) require. This calculated value will be used as the key basis for setting the specific minimum CPU time period and maximum memory read / write bandwidth limit in the next step, and together with the values of other isolation domains, it is used to allocate system resources proportionally. For example, if the sum of the values of all isolation domains is , then this domain will obtain an approximate resource quota benchmark of .

[0030] Based on the resource limit numerical values calculated previously for each isolation domain, and the mapping relationship between the trust domain and the sensitive data source established in the first step, the system begins to materialize the initial security isolation configuration. First, read the associations related to each isolation domain from the mapping relationship between the trust domain and the sensitive data source Feature tags that describe the expected workload characteristics of the isolation domain. For example, the tags may include "real-time control", "data acquisition", "batch computing", "user interaction", etc. These tags help to fine-tune the resource allocation strategy. For example, a domain with the "real-time control" tag may require a lower latency guarantee, even if its value is not high. Next, obtain the standard processor clock frequency of the current edge computing node (for example, by reading / proc / cpuinfo or using the lscpu command, such as 2.5 GHz) and the configuration parameters of the memory subsystem, including the number of memory channels (for example, dual-channel), the bandwidth per channel (for example, determined according to the memory type and frequency, such as about 19.2 GB / s for a single channel of DDR4-2400), and the total available memory bandwidth ( , usually close to but not exactly equal to the theoretical peak). Then, combine the resource quota of the isolation domain and its feature tags to perform specific resource limit settings. For the central processing unit (CPU) time, normalize the values of all isolation domains, calculate the proportion of the total CPU time that each domain should occupy, and then based on the total CPU time (for example, considering the total processing power of all cores) and the scheduling period (for example, the default scheduling period sched_latency_ns of the Linux CFS scheduler), set the minimum CPU time guarantee for each isolation domain (for example, allocate proportionally through cpu.shares of cgroups) or the maximum CPU time limit (for example, set a hard upper limit through cpu.cfs_quota_us and cpu.cfs_period_us of cgroups) to ensure that important or high-demand domains obtain sufficient computing time while restricting low-priority or potentially risky domains from over-consuming the CPU. For memory bandwidth, also based on the value (especially the proportion of the and parameters) and the feature tags, and refer to the total available memory bandwidth to set the maximum memory read / write bandwidth limit for each isolation domain (for example, limit the memory capacity through memory.max_usage_in_bytes of cgroups, and limit the bandwidth rate through the blkio controller (for block device IO) or a possible future memory bandwidth controller, such as Intel's Memory Bandwidth Allocation (MBA) technology). For example, if the domain has a If the value is relatively high and the label is "data collection", a higher memory bandwidth limit is allocated, while the "batch computing" domain may be allocated a lower memory bandwidth but a higher CPU time share. The minimum CPU time period (or ratio) and the maximum memory read and write value limit (bandwidth limit) of all isolation domains are integrated to form structured configuration data, such as a list or configuration file containing entries such as isolation domain ID, CPU share / quota, memory bandwidth limit, etc., to finally establish this initial security isolation configuration.

[0031] The steps to obtain the list of data entries to be marked are: Based on the sensitive data identification set in the initial security isolation configuration, scan the system call table and driver entry mapping table registered in the kernel state of the operating system, extract all function pointer entries associated with user-state input data and the corresponding file descriptor binding information, identify the entry address with the ability to access sensitive data, and obtain an information list; According to the information list, compare the protocol fields, port numbers and function call sequences in the data path, analyze the source interface, application context and memory mapping segment information of the data input item by item, exclude the entry items that do not meet the data identification trigger conditions, and form an entry address sequence; Based on the entry address sequence, the entry hierarchical relationship is reorganized according to the order of the function stack frames called in the data inflow path, and the repeatedly referenced stack items and invalid transfer nodes are removed to generate a list of data entries to be marked.

[0032] Specifically, based on the sensitive data identification set in the initial security isolation configuration, the system starts to actively detect the operating system kernel space to locate potential sensitive data entry points. First, by dynamically analyzing or statically parsing the kernel image, access and parse the system call table (for example, in the Linux system, this is an array named sys_call_table, whose address needs to be determined through symbol lookup or hard-coded offsets specific to the kernel version, or indirectly accessed through kernel probing mechanisms such as kprobes) to obtain the addresses of all registered system call handling functions. At the same time, the system traverses the exported symbols of the loaded modules in the kernel and the file operation structures (such as struct file_operations) filled during the registration of device drivers. These structures contain pointers to functions such as read, write, and ioctl, which are the key entry points for the driver to interact with the user space or hardware, and record these function pointers. For each extracted system call handling function and driver function entry, the system will analyze its parameter types and functions, especially those functions that directly or indirectly receive data from the user space (such as the call points of the copy_from_user function), and record the device type (such as character device, block device, network socket) or file system node information corresponding to the file descriptor (if applicable) associated with these entries. Next, compare the addresses of these entry functions with the information in the sensitive data identification set. For example, if the sensitive data identification set indicates that a specific physical serial port (such as / dev / ttyS1) is a sensitive data source, then all the entry function addresses related to the read operations of the serial port driver will be initially screened out. If the sensitive data identification set defines a specific network protocol or port number (such as a specific HTTP request pattern on TCP port 8080) as sensitive, then the function entries in the network stack that handle these protocols or ports will be concerned. In this way, identify those kernel function entry addresses that are capable of directly or indirectly accessing, receiving, or processing the defined sensitive data, and finally compile a preliminary list of entry addresses with the ability to access sensitive data and their associated information (such as related devices, file descriptor types, expected sensitive data types), obtaining an information list.

[0033] Based on the information list obtained in the previous step, the system reviews and filters each potential entry address in the list to exclude those entries that, although capable of accessing data, do not actually process or do not meet the specific sensitive data triggering conditions. This process first analyzes the characteristics of the data paths flowing through these entries. For example, for a network data entry (such as a receive function in a network protocol stack), the system checks the content of specific protocol fields in the data packets processed by this entry. For instance, in the ModbusTCP protocol, the function code field indicates the operation type, and the unit identifier specifies the target device; in an HTTP request, the URL path or specific header fields may indicate a request for sensitive resources, and matches it with the patterns defined in the sensitive data identification set. At the same time, the system also checks the destination port number of the data packet. For example, if the sensitive data identification set stipulates that the data stream on port 22 (SSH) is not marked as sensitive by itself unless accompanied by specific user behaviors or data content, then the port number alone is not sufficient to trigger a mark. Then, analyze the context of the function call sequence associated with this entry, that is, starting from this entry function, the subsequent kernel function paths that may be called to determine whether the data actually flows to the processing logic or storage area considered to be sensitive. The system also examines the type of source interface through which the data is incoming (for example, whether it is incoming from an untrusted external network interface or from an internal trusted inter-process communication pipeline), evaluates the execution context information of the application, such as the privilege level of the user process executing this system call, and the attributes of the memory segment it maps (for example, whether the data is directly written to a memory pool marked as "non-sensitive area"). These information together constitute the "data identification triggering conditions", which are a set of Boolean logic expressions. For example, the condition for an entry item to be retained may be "(the source IP address of the data packet is in the preset 'untrusted IP list' and the destination port is 502) or (the function call stack contains the 'process_critical_sensor_data' function and the data content matches the'specific sensor data format signature')". If an entry item and its associated data path analysis results do not meet any of the sensitive data identification triggering conditions defined for it, for example, a general network receive function receives all data, but for a specific data packet, its protocol fields and content do not match any sensitive data definitions, then this entry item is considered "not triggering" in this specific data inflow scenario and is excluded from the list. After a detailed analysis and condition judgment of each entry item in the information list, an entry address sequence is formed.

[0034] Based on the entry address sequence formed after the previous step of screening, the system then structures and optimizes these entry addresses with the aim of generating a clear, efficient, and non-redundant list for subsequent data taint marking operations. First, for each entry address in the sequence, the system traces the main function call path that the data follows after entering the kernel in a typical data processing scenario. This is usually accomplished through lightweight dynamic execution tracing (e.g., using eBPF programs to record the function call sequence in the kernel after a specific process triggers this entry and collecting samples of multiple executions to cover the main path) or static control flow analysis based on the kernel source code to obtain the sequential information of the function call stack frames following each entry point. Then, based on the sequential call relationships of these function stack frames, the entries in the entry address sequence are hierarchically organized. For example, a top-level entry (such as the system call read) may call a specific read function in the driver, and this read function may in turn call a lower-level bus communication function. This call chain constitutes the inflow hierarchy of the data. During the organization process, the system identifies and removes those common utility function stack items that appear repeatedly in different data inflow paths. For example, standard memory copy functions (such as memcpy) or general-purpose packet allocation / release functions. These functions do not directly determine the sensitivity of the data, and their taint propagation behavior will be handled by more general rules rather than being used as independent marked entries. At the same time, the system also identifies and removes the so-called "invalid transit nodes". An invalid transit node refers to a function node that only performs data transfer, format conversion (without changing the essential sensitivity), or simple conditional judgment in the data flow path but does not directly process sensitive information or distribute it to a new sensitive processing branch. For example, a function that simply transfers data from one buffer to another without parsing or making decisions may be regarded as an invalid transit node. The specific criterion for determining whether a node is an invalid transit node can be: the node does not access any sensitive data sources in the sensitive data identification set, does not write data to a known "taint sink", and the sensitivity state of its output data is completely determined by its input data. After removing duplicate references and invalid nodes in this way, what is obtained is a more refined and direct entry list that reflects the starting point of sensitive data processing, finally generating a structured and hierarchical list of data entries to be marked.

[0035] The steps for obtaining the marked sensitive data image are as follows: Traverse each entry address in the list of data entries to be marked, intercept the corresponding system call trigger behavior during the kernel-mode processing, extract the data content filled in the receive buffer and the incoming timing information, and retrieve the target data features field by field according to the set field matching rules to form a set of data items to which marks are to be applied; According to the set of data items to which tags are to be applied, call the page table mapping interface to locate the mapped page frame number in physical memory and the corresponding virtual address range for each data item. Combine the operation range of the data item in the system call stack, set the taint flag bits, and register them in the taint propagation linked list maintained by the kernel to generate a list of data content segments with identifiers. Based on the list of data content segments with identifiers, perform integrity splicing on the original data items to which each segment belongs, perform page boundary reorganization and memory continuity verification on cross-page data blocks, and construct the data content containing taint marks into a storage object in the form of a structured image to generate a marked sensitive data image.

[0036] Specifically, traverse each entry address recorded in the previously generated list of data entry points to be marked. The system uses kernel probing techniques, such as dynamically registering kprobes for these entry addresses (usually kernel function pointers) in the Linux environment or attaching probes using eBPF programs. When the corresponding system calls (such as read, recvmsg) or driver functions are triggered and executed, the registered probe programs will be immediately activated, thus achieving immediate interception of the kernel-state processing process. Once the interception is successful, the probe program will extract key information from the context of this call, including locating the kernel buffer address for receiving input data (for example, the pointer in the system call parameter pointing to the user space buffer before copy_from_user, or the data pointer in the DMA circular buffer inside the driver, the data pointer in the network socket receive queue sk_buff), as well as the exact range and length of the data actually filled into this buffer. At the same time, record the data incoming timestamp accurate to the microsecond level and other related timing characteristics, such as packet sequence numbers or data stream identifiers. Then, according to the set of field matching rules predefined in the sensitive data identifier set in the initial security isolation configuration, perform a byte-by-byte or field-by-field in-depth scan and comparison on the extracted data content. These rules detail the characteristic patterns of sensitive data. For example, the rule may be defined as "4 bytes starting at the data stream offset of 10 represent a specific device ID, and its value must be equal to 0xABCD1234", or "the data content contains a 16-digit numeric string that conforms to the regular expression '\d{16}'. The system will apply these rules one by one. For example, for a network packet, it will check whether the field values at predefined positions in its IP header, TCP / UDP header, and application layer payload match the sensitive data patterns in the rules. If a certain data content segment successfully matches any one of the field matching rules, then this data content segment and its meta-information (such as the exact offset, length, and the rule ID of the match in the original data stream) are collected to form a set of data items to which tags are to be applied.

[0037] For each item in the set of data items to be marked formed in the previous step, the system then marks these data items identified as potentially sensitive with a taint mark in physical memory. First, for each data item in the set, the system obtains its address in the kernel virtual address space, and then calls the page table traversal and address translation functions provided by the kernel (for example, in Linux, it can be parsed by functions in the follow_page series or by directly accessing process page table structures such as pgd_offset, pud_offset, pmd_offset, pte_offset) to convert this virtual address into the corresponding physical page frame number (PFN) and the offset of the data item within the physical page, so as to accurately locate the physical memory location of the data item. At the same time, the system will combine the operation range recorded in the system call stack frame information that triggered the data item to enter the kernel (for example, the number of bytes requested to be read by the read system call, or the length of the packet received by recvfrom), ensuring that the range of the taint mark is strictly limited to the actually incoming and successfully matched data content, without exceeding its legal boundary and avoiding incorrect expansion of the marking range. After confirming the physical location and range, the system sets the taint mark bit for this physical memory area. This mark can be implemented in a dedicated metadata area, such as a "shadow memory" area that corresponds one-to-one with physical memory, where each byte or bit corresponds to a byte or a fixed-size block of physical memory and stores its taint status (such as "tainted_by_sensor_X"), or alternatively, the physical page frame can be added to a specific kernel data structure for management. For example, a node containing taint mark bit information (such as physical address, length, taint source identifier, timestamp) is added to a doubly linked list or hash table maintained by the kernel and specifically used to track the propagation of taint data, that is, the so-called taint propagation linked list. Each time a data item is successfully marked, a corresponding record is generated and inserted into this linked list. Finally, all successfully marked data items and their location, range, and taint attribute information in physical memory are sorted out to generate a list of data content segments with identifiers.

[0038] Based on the list of labeled data content segments generated in the previous step, the system proceeds to integrate these potentially scattered and labeled memory segments into a complete and structured view of sensitive data, namely the labeled sensitive data image. First, the system traverses each segment in the list of labeled data content segments and, based on the original data item attribution information recorded in the segment meta-information (for example, they may all belong to different shards of the same network flow or different parts of the same file read operation), performs integrity stitching on those segments that logically belong to the same original data item but may be physically discontinuous or arrive in multiple parts. For example, if a large sensor reading is divided into multiple TCP packets for reception, the system will recombine these separately labeled segments in the correct order according to the TCP sequence number or the indication of the application layer protocol to form the original complete reading. During this process, special handling is given to data blocks that cross physical page boundaries to ensure that the logical continuity of the data is correctly reflected in the physical-level recombination. For example, a 1KB data block starts at the end of page A and ends at the beginning of page B, and the system will ensure that the relevant labeled segments on these two pages are identified and logically connected. At the same time, a memory continuity check is performed to confirm that the stitched data logically conforms to the structure and length of the original data item without loss or out-of-order. After analyzing, stitching, and verifying all segments, the system organizes all this data content with taint marks (including its physical address, length, taint attribute, original entry information, timestamp, etc.) into a structured storage object. This object can be regarded as a snapshot or "image" of all the identified and labeled sensitive data in memory in the current system. It is not a simple copy of the original data but a data structure containing rich metadata, such as a tree structure, where the leaf nodes represent specific taint data segments and the parent nodes represent data sources or aggregation relationships, thus generating the labeled sensitive data image.

[0039] The steps for obtaining the taint state of real-time data streams are as follows: Scan the page frame mapping records of the labeled sensitive data image in the physical memory of the IoT edge computing node, retrieve the access logs of the page table and virtual memory manager in the operating system, locate the memory address transfer relationship and thread call context information associated with the replication behavior of the data image among different processing threads, and generate the replication path sequence of the sensitive data image; According to the replication path sequence of the sensitive data image, parse the function call stack, processor core allocation record, and kernel task scheduling trajectory associated with each path, identify the task scheduling boundaries passed by the image data when switching between different trust domains, and extract the trust domain switching time points and the corresponding data access status identifiers to form the cross-trust domain data transfer status sequence; Based on the cross-trust domain data transfer status sequence, compare the corresponding image tag status, register content changes, and data buffer call permissions during each trust domain switch, mark the status of data segments transmitted across domains, and integrate the data transfer records of the changed or originally tainted tags in all propagation paths to generate the real-time data flow taint status.

[0040] Specifically, based on each sensitive data segment contained in the previously generated marked sensitive data image and its page frame mapping record in physical memory, the system starts continuous monitoring to track the replication behavior of these data segments. First, through the kernel-level memory operation monitoring mechanism, such as setting dynamic probes (such as kprobes) for kernel functions related to memory copying like memcpy and memmove, or using the hardware-assisted memory access monitoring function (such as the memory access events of Intel Processor Trace), it captures in real time the read operations on the physical page frames occupied by the marked sensitive data image, as well as subsequent possible write operations to other memory locations. At the same time, the system retrieves the logs or real-time event streams related to virtual memory management in the operating system kernel. For example, by analyzing page table modification events (such as page replication caused by the Copy-on-Write mechanism after a write protection fault) and data transfer records involving shared memory or message queues during inter-process communication (IPC). When it is detected that a marked sensitive data segment (source data) is read from its original physical address, and immediately afterwards or in the associated execution flow, data is written to another new memory address (target data), the system initially determines that a data replication may have occurred. At this time, it will record in detail multiple key information related to this replication operation, including the physical address where the source data is located, the physical address where the target data is written, the identifier of the thread (TID) that performs the replication operation, the process identifier (PID) to which this thread belongs, a snapshot of the function call stack when the replication operation is performed (including at least several key functions), and the exact timestamp when the replication operation occurs. Combine this information into a replication event record. Through continuous monitoring and recording, finally, a sequence containing the memory address transfer relationship and thread call context information associated with the replication of all marked sensitive data among different processing threads is generated, that is, the replication path sequence of the sensitive data image.

[0041] Based on the sequence of copy paths of the sensitive data image generated in the previous stage, the system deeply analyzes each copy path in the sequence to identify whether the sensitive data crosses the trust domain boundary. For each copy path that records memory address transfer and thread context, the system first traces back and analyzes the complete kernel function call stack information associated with the copy operation to determine the specific execution logic and context of the data copy. Then, it queries the processor core allocation record of the thread at the moment of the copy operation (i.e., which CPU core the thread was running on at that time) and the kernel task scheduling trace related to the thread. These trace information are obtained by analyzing the scheduling event logs of the kernel scheduler (such as the Linux CFS scheduler) (for example, sched_switch event), which can reveal when the thread was scheduled to execute, when it was preempted, and its switching relationship with other threads. Then, a crucial step is to identify whether the data crosses the predefined trust domain boundary during the copy process. The system determines the trust domain to which the source thread (if the data is copied from the memory space of one thread to another) or the target thread belongs based on the trust domains defined in the "Initial Security Isolation Configuration" (for example, trust domain A contains processes P1, P2, and trust domain B contains processes P3, P4). If a copy operation causes data to be transferred from the memory space of one trust domain (or held by a thread belonging to that trust domain) to the memory space of another different trust domain (or accessed by a thread belonging to a different trust domain), it is considered that a cross-trust domain data transfer has occurred. The system will accurately record the time point when this trust domain switch occurs (usually the timestamp when the copy operation is completed or the relevant task scheduling occurs), and mark the corresponding data access status identifier in combination with the nature of the copy operation (such as whether it is a direct memory copy or a transfer through the IPC mechanism) (for example, "Read from domain A, written to domain B", "Sent from domain A to domain B through pipe X"). Integrate all the identified cross-trust domain transfer events and their related information to form a cross-trust domain data transfer status sequence.

[0042] Based on the cross-trust-domain data transfer status sequence formed in the previous step, the system further analyzes the specific situation of each sensitive data crossing the trust domain boundary to determine the propagation and evolution of taint marks. For each cross-trust-domain data transfer event in the sequence, the system first checks the original taint mark status of the transferred data segment in the "marked sensitive data image" (e.g., the data originates from sensor X and the taint level is high). Subsequently, the system attempts to analyze whether the data content itself has changed during the trust domain switch and whether this change affects its sensitivity. This includes monitoring the changes in the content of CPU registers related to data operations before and after the execution of key instructions (such as arithmetic operations, logical operations, and cryptographic function calls) on the data transfer path. For example, if the data shows that before entering a "purification" trust domain (e.g., a domain specifically performing data desensitization), the data is loaded into the register, and after a series of operations, the data in the register or the target memory is no longer the same as the original data, and the difference conforms to the characteristics of the expected purification operation, then the taint status may change. At the same time, the system also checks the call permission settings of the target buffer where the data is transferred in the new trust domain, such as whether the access permission of the thread in the new trust domain to this buffer is read-only, read-write, or execute, and whether there are specific security policies (such as SELinux policies) restricting its operations. Combining this information - the original taint status, potential changes in register and memory content (judging whether there are substantial changes by comparing data checksums or small fragment hash values), access permissions of the target buffer, and the function attributes of the executed operations (e.g., whether it is a known purification function or cryptographic function), the system assigns an updated taint status to the data segment after cross-domain propagation. If the data is transferred directly without change, the original taint mark is maintained; if it undergoes an authenticated purification or encryption process, the taint level is reduced or the taint type is changed; if the data is improperly modified or transferred to a low-trust domain that should not receive it, the taint warning level is upgraded. Finally, the transfer records of the data segments that have changed or maintained their original taint marks before and after transfer in all the analyzed cross-trust-domain propagation paths are integrated and correlated to form a dynamically updated global view reflecting the taint situation of all monitored data streams in the current system, that is, the real-time data stream taint status.

[0043] The steps to obtain the data access audit record are as follows: Traverse all the marked data paths in the real-time data stream taint status, extract the memory address mapping relationships, thread operation stack call information, and corresponding trust domain boundary identifiers included in each path, and combine with the set checkpoint list to identify and mark the node positions where each data item crosses the trust domain, and obtain the cross-domain transfer records in the data path; According to the cross-domain transfer records in the data path, calculate the violation determination value of the sensitive data transfer behavior. The calculation formula is: ; Among them, represents the violation determination value of the th data path, represents the total number of bytes of data marked as tainted in the th data path (unit: byte), represents the average transmission delay (unit: second) from the th data path to the interface outside the trusted domain, represents the response delay (unit: second) of the source - end interface of the th data path in the trusted domain, represents the total number of transit nodes between trusted domains in the th data path (unit: number), represents the total number of nodes that have triggered the purification rule in the th data path (unit: number); Based on the violation determination value, set a threshold judgment condition. If the violation determination value exceeds the threshold, it is determined that there is a behavior of data flowing out of the trusted domain or writing to the tainted sink. Record the identification number of the data path, the timestamp of the transmission behavior, and the associated thread control block together to generate a data access audit record.

[0044] Specifically, the system first traverses all the marked data paths recorded in the previously generated taint states of the real-time data stream. These paths detail the flow trajectory of the tainted data in the system. For each marked data path, the system carefully extracts the key information it contains, specifically including the address mapping relationship between physical memory and virtual memory (e.g., a certain tainted data segment is currently located in physical page frame 0xABC and is mapped to the virtual address 0x12345000 of process P), the thread context information of the executed relevant operations, especially its call stack record (e.g., the data copy operation is completed by the thread with TID 1001 when executing the function kernel_write() by calling memcpy_to_user()), and the trust domain boundary identifiers identified during the data flow process (e.g., the data is transferred from a thread belonging to the "sensor input processing domain" to a thread belonging to the "network sending domain"). Next, the system will analyze these paths in combination with a pre-configured "checkpoint list", which lists the known key code locations or interfaces that may cause information leakage or improper access. For example, the list may include specific system calls (such as sendto, write to a specific device file), or functions in the kernel that directly communicate with external hardware (such as the sending function of the network card driver, the writing function of the USB storage device), or specific IPC channels defined as sensitive data exits by the security policy. The system matches each node (such as function call, thread switch, IPC event) on the data path with the checkpoint list. When it is found that a certain node on the data path matches an item in the checkpoint list, and the operation of this node involves transferring tainted data from one trust domain to another trust domain, or from one trust domain to the external interface or potential taint sink identified by the checkpoint, the system marks the location of this node as a cross-domain transfer event and records relevant details, such as data flow direction (source domain, target domain / interface), timestamp, identification of the involved data segment, etc. By performing this analysis and annotation process on all the marked data paths, a cross-domain transfer record in the data path is finally compiled and formed.

[0045] Formula: , The benefit of the formula is that it provides a method for quantitatively evaluating the risk of sensitive data transmission behavior. It comprehensively considers multiple dimensions such as data volume, change in transmission efficiency, path complexity, and effectiveness of purification measures. The parameter ensures that transmitting a large amount of sensitive data itself has a relatively high basic risk value. The logarithmic term can amplify the relative change in transmission delay, that is, when the delay of the data flowing out of the trust domain is much greater than its processing delay within the domain When there is a bottleneck or abnormal waiting during data leakage (which may indicate), the risk value will increase significantly, and vice versa. However, the absolute value ensures that both extremely large delays and extremely small delays (which may indicate an extremely fast internal transfer to the exit) will contribute to the risk. The final factor adjusts the risk according to the proportion of unpurified transfer nodes in the path. The more unpurified transfer nodes there are ( the larger), the higher the risk. Through this comprehensive multi-factor assessment, high-risk data transmission behaviors can be identified more accurately, providing a basis for subsequent auditing and response.

[0046] represents the total number of bytes of tainted data (unit: byte) marked in the th data path. This parameter directly reflects the amount of potentially leaked or improperly accessed data. The way to obtain it is as follows: When generating the "real-time data flow taint status", each marked tainted data segment records its size. When analyzing the th data path, the total number of bytes of the core tainted data segments flowing on this path is accumulated to obtain . For example, if the path transmits a tainted data block containing 1024 bytes of user credentials, then .

[0047] represents the average transmission delay (unit: second) of the th data path flowing out to the interface outside the trusted domain. This parameter measures the time taken for data to leave the current trusted domain and reach an external interface (such as a network card, disk). The way to obtain it is as follows: By setting timestamp collection points at key nodes of the data path (such as the time point when the data leaves the last internal processing function in the trusted domain and the time point when the data actually reaches the external interface driver and is ready to be sent ), calculate as the single delay. After collecting such delay data for multiple transmissions, calculate their average value. For example, for the path , after 10 observations, the average transmission delay is .

[0048] represents the response delay (unit: second) of the th data path at the source end interface within the trusted domain. This parameter measures the processing time taken for data to be generated to be ready to be transmitted from its source within the trusted domain. The way to obtain it is as follows: Within the source trusted domain of the data path, record the time point when the data is generated or received and the time point when the data is processed within the trusted domain and reaches the internal interface at the outgoing point , calculate As a single delay, after collecting such delay data for multiple transmissions, calculate its average value. For example, for the path , after 10 observations, the average response delay is .

[0049] Denote the total number of transit nodes between trust domains in the th data path item (unit: number). This parameter reflects the number of different trust domains (or key processing modules within the same trust domain) that the data passes through before reaching the final exit. The acquisition method is as follows: Analyze the "cross-domain transmission records in the data path", and count the number of different trust domain boundaries or predefined important internal processing nodes passed by the th data path from the source to its currently analyzed exit point. For example, for the path , if the data is generated in domain A, processed in domain B, and then reaches the exit of domain C, the number of transit nodes (referring to the crossed boundaries or entered intermediate domains) is .

[0050] Denote the total number of nodes that have triggered the purification rule in the th data path item (unit: number). This parameter measures how many effective purification processes the data has undergone during transmission. The acquisition method is as follows: During the generation of the "real-time data flow taint status", if the taint marking status of the data changes favorably (such as the taint level decreases or is removed) according to the preset purification rules (for example, the data is encrypted, desensitized, or aggregated) after passing through a certain node (such as a specific function or process), then this node is regarded as a purification node, and count the number of such purification nodes on the path . For example, for the path , when the data on it passes through domain B and undergoes processing by a known encryption function, and this function is marked as a purification rule trigger point, then .

[0051] Calculation process: Taking the th data path item as an example, substitute the parameter values obtained previously for calculation: ; The calculation process is as follows: Calculate the logarithmic term of the delay ratio: The absolute value is: ; Calculate the path complexity adjustment factor: The overall adjustment factor is: ; Calculate the final violation determination value : ; ; ; ; The result shows that: for the illegal determination value of the nth data path is calculated as

[0052] , which is a quantitative indicator comprehensively evaluating the risk of the data path transmission behavior. The higher the value, the greater the potential risk or suspicion of illegal behavior of the data transmission behavior. This value will be used for subsequent comparison with a preset threshold to determine whether it constitutes an illegal event that needs to be recorded. Based on the illegal determination value of the sensitive data transmission behavior calculated for each analyzed data path in the previous step , the system will next compare this determination value with a preset "illegal determination threshold". The setting of this illegal determination threshold is a key step. It is not fixed, but dynamically adjusted or hierarchically set according to historical data analysis, security policy levels, and acceptable false positive and false negative rates. For example, the system can initially run in a learning mode, collecting the value distributions of a large number of normal and known abnormal data streams

[0053] The steps to obtain the current domain resource occupancy value are as follows: Retrieve the CPU time parameters set for each isolation domain in the initial security isolation configuration, divide the total allocatable time slots of the CPU into a corresponding number of cycle segments according to the mapping relationship between the isolation domain identifier and the trust domain to which it belongs, allocate cycle durations in combination with the current processor core state and the task priority order in the scheduling queue, and generate an isolation domain processor time allocation list; According to the isolation domain processor time allocation list, the number of context switches of active processes in each isolation domain, the start and end timestamps of processor occupancy, and the number of instruction cycles consumed by each task execution are monitored in real time. All data are aligned and mapped with the current processor allocation cycle, and idle cycles and scheduling waiting segments are eliminated to form an isolation domain task cycle usage list; Based on the isolation domain task cycle usage details table, the central processing unit time occupied by each isolation domain in the current scheduling cycle is counted, the intermediate states of cross-cycle tasks and repeated measurement items in continuous cycles are merged, the processor occupancy of each isolation domain in the current period is extracted, and the current domain resource occupancy value is obtained.

[0054] Specifically, the system first retrieves the central processing unit time parameters set for each defined isolation domain in the previously established "initial security isolation configuration". These parameters include the CPU time quota (for example, isolation domain A is allocated 20,000 microseconds of running time, and its scheduling period is 100,000 microseconds, that is, 20% of the CPU), the CPU share (for example, in the CFS scheduler, the CPU shares value of isolation domain B is 512, while that of isolation domain C is 1024, indicating that the weight of C is twice that of B), and the possible minimum guarantee time. Subsequently, the system refers to the mapping relationship between the isolation domain identifiers (for example, Domain_SensorProcessing, Domain_NetworkGateway) in the "initial security isolation configuration" and their corresponding trusted domains (for example, TrustZone_HighSecurity, TrustZone_Standard), and divides the total allocable computing time slots of the central processing unit of the entire Internet of Things edge computing node (for example, in a 100-millisecond global scheduling large cycle, if there are 4 CPU cores, the total time slots are 400 milliseconds) according to the proportion of the CPU time parameters configured for each isolation domain to form the theoretical cycle quota for each isolation domain. Then, the system will query the running status of each core of the current processor in real time, including the current load percentage of each core, whether there is a core in an idle or low-power state, and check the real-time priorities of the tasks in each isolation domain in the operating system kernel scheduling queue (for example, the priority of real-time tasks is higher than that of ordinary tasks) and the length of the task waiting queue. Considering these dynamic factors comprehensively, the system fine-tunes the allocation of the theoretical cycle quota. For example, if an isolation domain with a higher CPU share currently has no active tasks or its task priority is low, while another isolation domain with a lower share but high-priority real-time tasks urgently needs CPU resources, the scheduler may temporarily adjust the allocation in the current small cycle to give priority to meeting the needs of high-priority tasks, while ensuring that in the long run, the CPU time allocation ratio of each domain conforms to the initial configuration. Through such dynamic combination and priority adjudication, the specific running duration of the processor allocated to each isolation domain in the next one or more scheduling small cycles (for example, every 10 milliseconds) is tabulated and recorded to generate the isolation domain processor time allocation list.

[0055] Based on the processor running durations planned for each isolated domain in the isolated domain processor time allocation list generated in the previous step, the system starts to precisely and real-time monitor the CPU usage of the active processes within each isolated domain. This monitoring is achieved by subscribing to the kernel's performance events or by using specific kernel tracepoints (tracepoints). For example, for each active process within each isolated domain (i.e., a process in the running state or the ready state), the system records each event of context switch (obtained through the sched_switch tracepoint, including the timestamp when the switch occurs, the ID of the process being switched out, and the ID of the process being switched in), obtains the start and end timestamps when each process actually occupies the processor, calculates the exact duration of a single run. At the same time, if the hardware supports it, the system will also access the counters of the processor performance monitoring unit (PMU) to obtain the number of CPU instruction cycles consumed by the process during each task execution (for example, configuring the monitoring of cpu-cycles or instructions events through the perf_event_open system call). All the original monitoring data collected (number of context switches, start and end timestamps of runs, number of instruction cycles) will be time-aligned and associated with the specific processor allocation cycle when they occur (for example, each 10-millisecond allocation window defined by the isolated domain processor time allocation list). Then, the system will analyze this data, excluding those cycles during which the CPU is actually idle within the time slice allocated to a certain isolated domain (i.e., the isolated domain has a quota but no task is running), and the time periods when the process is in the scheduling waiting queue due to waiting for I / O or synchronization operations and does not actually consume the CPU. After such data cleaning and alignment processing, a detailed table recording the actual CPU usage of each task within each isolated domain during the allocation cycle is finally sorted out for each isolated domain, forming a detailed table of the usage of isolated domain task cycles.

[0056] Based on the isolation domain task cycle usage details table formed in the previous stage, which records the detailed CPU usage of tasks in each isolation domain during the allocation cycle, the system begins to accurately count the total CPU time actually occupied by each isolation domain in the current complete scheduling cycle (for example, a 100-ms global scheduling cycle, which is composed of multiple small allocation cycles). For tasks whose execution time spans multiple small allocation cycles or even the entire scheduling cycle, the system will carefully divide and accumulate the CPU time consumed in different cycles to ensure that their occupancy in each cycle is correctly counted, and merge their intermediate states at different stages (such as cumulative running time, number of executed instructions), avoiding repeated measurement or omissions caused by the continuity of task execution. For example, a task in a 10-ms allocation cycle If a CPU usage fragment is calculated only once, and all the records in the detailed table are carefully summarized, segmented and deduplicated, the system can accurately extract the total processor usage time of each isolation domain in the current complete scheduling period. This usage time is the sum of the CPU time actually consumed by all processes in the domain, thereby obtaining the current domain resource usage value of each isolation domain.

[0057] The steps to obtain the adjusted isolation domain operating parameters are as follows: Analyze the usage details of each processor time slice in the current domain resource occupancy value, extract the corresponding process execution frequency, context switching times and idle cycle ratio, and combine the number and occurrence time distribution of illegal data transmission events recorded in the data access audit record to generate a resource load correlation indicator set for the isolation domain in the current scheduling cycle; Based on the resource load associated indicator set of the isolation domain in the current scheduling cycle, the resource adjustment coefficient of each isolation domain is calculated using the following formula: ; in, For the The resource adjustment factor for each isolation domain, For the The average number of context switches for processes in an isolation domain, For the The number of illegal data access events recorded by the isolation domain in this scheduling cycle, For the The total number of idle processor cycles of an isolation domain during this period is the number of illegal data flow paths determined in the nth isolation domain; Based on the resource adjustment coefficient, combined with the set processor time reference value and the upper limit of memory bandwidth, linearly scale the allocation ratio of processor time and bandwidth, write the updated computing resource configuration into the isolation domain operation parameter table, and establish the adjusted isolation domain operation parameters.

[0058] Specifically, the system first analyzes the current domain resource occupancy value obtained in the previous step and delves into its constituent basis, namely the "Isolation Domain Task Cycle Usage Details Table", extracts the detailed usage records of each processor time slice within each isolation domain from it, and for the nth isolation domain, the system calculates the average execution frequency of its internal processes. This frequency can be defined as the average number of times the key business processes within the domain are scheduled and executed during the current scheduling period divided by the cycle duration, or the average call rate of key functions. For example, if a sensor data acquisition process within the domain is awakened and executed 20 times within a one-second scheduling period, its execution frequency is 20Hz. The system will also directly extract or further statistically obtain the total number of context switches of all processes within the isolation domain during the current scheduling period, as well as the total number of processor idle cycles, and calculate the idle cycle ratio, that is, the total number of idle processor cycles divided by the total number of processor cycles allocated to the isolation domain. For example, if 1 million CPU cycles are allocated to a certain domain and 200,000 of them are idle, the idle cycle ratio is 20%. At the same time, the system retrieves the previously generated "Data Access Audit Record", filters out the records related to the current isolation domain from it, counts the total number of illegal data transmission events that occurred during the current scheduling period, and analyzes the timestamp distribution characteristics of these events, such as whether they are concentrated in a certain time period or evenly distributed. Integrate these extracted and statistically obtained process execution frequencies, total context switch counts, idle cycle ratios, the number of illegal data transmission events, and event time distribution characteristics (which can be quantified as a risk score, for example, the more concentrated the events, the higher the score) to generate a set containing these multi-dimensional information for each isolation domain, that is, the resource load correlation index set of the isolation domain during the current scheduling period.

[0059] Formula: , Regarding the explanation of the denominator of the formula: When is the case, the denominator takes a preset fixed value of 1.

[0060] The benefit of the formula is that it comprehensively evaluates the operating status and security performance of the isolation domain to dynamically calculate the tendency of resource adjustment. The numerator part combines the pressures of two core aspects through the Euclidean distance method: represents the process scheduling overhead or activity. Frequent context switches usually mean heavy tasks or large interference between tasks; quantifies the contradiction between security risk and resource utilization, that is, under a certain amount of idle resources ( ), how many security events occur ( ). If there are many security events and few idle resources, this item will increase significantly, indicating that the domain is both busy and insecure. The denominator introduces a penalty for historical or cumulative security bad records ( , the number of illegal data flow paths). The more illegal paths, the larger the denominator, thus reducing the overall adjustment coefficient . This design enables resource adjustment to consider not only the current load but also security compliance, helping to tilt resources towards domains with good performance and genuine resource requirements, or restricting the resource expansion of domains with poor performance.

[0061] is the average number of context switches of processes in the th isolated domain. This parameter reflects the scheduling frequency of tasks within the domain, indirectly indicating the concurrency or fragmentation degree of tasks. It is obtained by analyzing the total number of context switches of the th isolated domain recorded in the "Resource Load Association Index Set of the Isolated Domain in the Current Scheduling Cycle" generated in the previous step within a specified scheduling cycle (for example, the most recent 1 second), and then dividing it by the number of active processes in the domain (if calculating the number of switches per process on average) or directly using the total number of switches as a measurement index (if refers to the total switching activity of the domain), to obtain this value. For example, within a 1 - second scheduling cycle, the isolated domain has a total of 150 context switches. If there are 5 main active processes in this domain, then on average each process switches 30 times, or directly take as the total switching index of the domain.

[0062] is the number of illegal data access event records of the th isolated domain in this scheduling cycle. This parameter is directly related to the real - time security performance of the domain and is obtained by extracting from the "Resource Load Association Index Set of the Isolated Domain in the Current Scheduling Cycle", which has combined the "Data Access Audit Record" to count the total number of illegal data transfer event records of the th isolated domain in the current scheduling cycle (for example, the most recent 1 second). For example, if the isolated domain detects and records 3 illegal data access events in this cycle, then .

[0063] is the The total number of idle processor cycles of an isolation domain during this period. This parameter measures how much of the CPU resources allocated to this domain are not actually used, reflecting the redundancy of resources. The acquisition method is: extract from the "Resource Load Association Index Set of the Isolation Domain in the Current Scheduling Period". This index set analyzes the "Detailed Schedule of Isolation Domain Task Cycles Used" and counts the total number of CPU cycles not used by any of its internal processes in the current scheduling period of the isolation domain (for example, in the most recent 1 second, for example, a total of CPU cycles are allocated to this domain). For example, if there are CPU cycles idle in this isolation domain during this period, then .

[0064] is the number of illegal data flow paths determined in the th isolation domain. This parameter represents the historical or cumulative performance of the domain in terms of data processing compliance. The acquisition method is: extract from the "Resource Load Association Index Set of the Isolation Domain in the Current Scheduling Period". This index set counts the total number of independent data flow paths originating from the "Data Access Audit Record" and belonging to the th isolation domain that have been finally determined to be illegal in history or over a long evaluation period. For example, if the isolation domain has been identified as having 2 illegal persistent data leakage paths so far, then .

[0065] Calculation process: Taking the th isolation domain as an example, substitute the parameter values obtained previously for calculation: ; The calculation process is as follows: For the numerator part: , inside the square root of the numerator: , the result of the numerator: ; For the denominator part: , the result of the denominator: ; Calculate the final resource adjustment coefficient : ; This result indicates that: the resource adjustment coefficient of the th isolation domain is calculated to be

[0066] Based on the resource adjustment coefficients calculated for each isolation domain in the previous step , the system then adjusts the resource supply of each isolation domain with reference to the pre-set or dynamically updated "processor time benchmark value" and "memory bandwidth upper limit". First, the processor time benchmark value can be defined as the minimum CPU time share guaranteed by the system for each isolation domain (for example, each domain obtains at least 5% of the single-core CPU time), or the CPU time value allocated in the previous cycle. The memory bandwidth upper limit is the maximum available bandwidth set for each isolation domain according to the total hardware bandwidth capacity of the edge computing node (for example, the total memory bandwidth is 10 GB / s) and the overall system policy (for example, any single domain does not exceed 2 GB / s). The adjustment process adopts a linear scaling method. For example, for the processor time allocation of the th isolation domain, the new allocation ratio or absolute value can be calculated based on its current allocation ratio and the resource adjustment coefficient to calculate an adjusted weight , where is after normalization (compressing the of all domains to the interval), is an adjustment sensitivity parameter (for example, , controlling the adjustment amplitude). If is greater than 1, resources are increased; if less than 1, resources are decreased. A similar logic is adopted for the memory bandwidth, and its allocation ratio is scaled according to the bandwidth-related metrics. The allocation ratios of all adjusted processor time and memory bandwidth must be renormalized to ensure that the total CPU time of all isolation domains does not exceed the total available CPU time, and their respective memory bandwidths do not exceed their upper limits and the system total upper limit. The adjusted computing resource configuration, including the updated CPU time quota / share and memory bandwidth limit value, is accurately recorded and written into the "isolation domain running parameter table" in the kernel. This parameter table is the configuration basis directly read and executed by the operating system scheduler and resource limit modules (such as cgroups), thereby establishing the dynamically adjusted isolation domain running parameters.

[0067] The above is only the preferred embodiment of the present invention, and it is not intended to limit the present invention in other forms. Any person skilled in the art may use the disclosed technical content to make changes or modifications into equivalent embodiments with equivalent changes and apply them to other fields. However, any simple modification, equivalent change, and modification made to the above embodiments based on the technical essence of the present invention without departing from the technical solution content of the present invention still fall within the protection scope of the technical solution of the present invention.

Claims

1. A security isolation method for an Internet of Things edge computing node, characterized in that The following steps are involved: Identify the trust domain and define the sensitive data source in the IoT edge computing node, generate a sensitive data identification set, plan the minimum CPU time and maximum memory bandwidth for each isolation domain based on the sensitive data identification set to form an isolation domain resource limit, and establish an initial security isolation configuration; Invoke the provisions of the sensitive data identification set in the initial security isolation configuration, locate the data items entering the system from the specified entry in the operating system kernel layer, obtain the list of data entries to be marked, apply taint marks to the data items based on the list of data entries to be marked, and obtain a marked sensitive data image; Track the replication and computation path of the marked sensitive data image in the memory of the IoT edge computing node, record the state of transmission between different trust domains, form a real-time data flow taint state, and judge the behavior of data flowing out of the trust domain or writing into the taint sink based on the real-time data flow taint state and checkpoints and purification rules, and generate data access audit records; Refer to the isolation domain resource limit in the initial security isolation configuration to allocate the central processing unit time of the isolation domain, obtain the current domain resource occupancy value, adjust the computing resource supply of the isolation domain based on the current domain resource occupancy value and combine the data access audit record, and establish the adjusted isolation domain operating parameters.

2. The security isolation method of the Internet of Things edge computing node according to claim 1, characterized in that The steps for obtaining the initial security isolation configuration are: Traverse the process call path corresponding to each processing task in the IoT edge computing node, parse the device access records and driver loading behaviors of the process in the kernel state layer by layer, match the data identification bit pattern in the bus transmission process connected to the physical port, screen the access segments pointing to the unified address space and compare them with the system permission mapping table to obtain the mapping relationship between the trust domain and the sensitive data source; Calculating resource limits according to a mapping relationship between the trust domain and the sensitive data source; Based on the resource limit of each isolation domain, read the characteristic tags of each domain in the mapping relationship between the trust domain and the sensitive data source, combine the standard processor clock frequency and memory channel allocation parameters, set the minimum time period of the central processor and the maximum read and write value limit of the memory for each trust domain, and establish the initial security isolation configuration.

3. The security isolation method for the Internet of Things edge computing node according to claim 1, wherein The steps for obtaining the list of data entries to be marked are: Based on the sensitive data identification set in the initial security isolation configuration, scan the system call table and driver entry mapping table registered in the kernel state of the operating system, extract all function pointer entries associated with user state input data and corresponding file descriptor binding information, identify the entry address with the ability to access sensitive data, and obtain an information list; According to the information list, compare the protocol fields, port numbers and function call sequences in the data path, analyze the source interface, application context and memory mapping segment information of the data input item by item, exclude the entry items that do not meet the data identification trigger conditions, and form an entry address sequence; Based on the entry address sequence, the entry hierarchical relationship is reorganized according to the order of the function stack frames called in the data inflow path, and the stack items with repeated references and invalid transfer nodes are removed to generate a list of data entries to be marked.

4. The security isolation method of the Internet of Things edge computing node according to claim 1, characterized in that The steps of obtaining the labeled sensitive data image are: Traverse each entry address in the list of data entry addresses to be marked, intercept the system call trigger behavior corresponding to the process in the kernel mode, extract the data content filled in the receive buffer and the incoming timing information, and retrieve the target data features field by field according to the set field matching rules to form a set of data items to be marked with tags; According to the set of data items to be marked with tags, call the page table mapping interface to locate the mapped page frame number and the corresponding virtual address range of each data item in the physical memory, and combine the operation range of the data item in the system call stack to set the taint flag bit and register it in the taint propagation linked list maintained by the kernel to generate a list of data content segments with identifiers; Based on the list of data content segments with identifiers, perform integrity splicing on the original data items to which each segment belongs, perform page boundary reorganization and memory continuity check on cross-page data blocks, and construct all data content containing taint marks into a storage object in the form of a structured image to generate a marked sensitive data image.

5. The security isolation method of the Internet of Things edge computing node according to claim 1, characterized in that The steps for obtaining the taint state of the real-time data stream are as follows: Scan the page frame mapping records of the marked sensitive data image in the physical memory of the Internet of Things edge computing node, retrieve the access logs of the page table and the virtual memory manager in the operating system, locate the memory address transfer relationship and thread call context information associated with the replication behavior of the data image between different processing threads, and generate a replication path sequence of the sensitive data image; According to the replication path sequence of the sensitive data image, analyze the function call stack, processor core allocation record and kernel task scheduling track associated with each path, identify the task scheduling boundary passed by the image data when switching between different trust domains, and extract the trust domain switching time point and the corresponding data access status identifier to form a cross-trust domain data transfer status sequence; Based on the cross-trust domain data transfer status sequence, compare the corresponding image mark status, register content change situation and data buffer call permission during each trust domain switching process, mark the status of the data segments transmitted across domains, and integrate the data transfer records with changed or unchanged original taint marks in all propagation paths to generate the taint state of the real-time data stream.

6. The security isolation method for the Internet of Things edge computing node according to claim 1, wherein, The steps for obtaining the data access audit record are as follows: Traverse all the marked data paths in the taint state of the real-time data stream, extract the memory address mapping relationship, thread operation stack call information and the corresponding trust domain boundary identifier contained in each path, and combine the set checkpoint list to identify and mark the node positions where each data item crosses the trust domain to obtain the cross-domain transmission record in the data path; Calculate the violation determination value of the sensitive data transmission behavior according to the cross-domain transmission record in the data path; Based on the violation determination value, set the threshold judgment condition. If the violation determination value exceeds the threshold, it is determined that there is a behavior of data flowing out of the trust domain or writing to the taint sink, and record the identifier number of the data path, the transmission behavior timestamp and the associated thread control block together to generate a data access audit record.

7. The security isolation method of the Internet of Things edge computing node according to claim 1, characterized in that The steps for obtaining the current domain resource occupancy value are as follows: Retrieve the central processing unit (CPU) time parameters set for each isolation domain within the initial security isolation configuration. According to the mapping relationship between the isolation domain identifier and the trusted domain it belongs to, divide the total allocable time slots of the CPU into corresponding numbers of periodic segments. Combine the current processor core status and the task priority order in the scheduling queue to perform periodic duration allocation and generate an isolation domain processor time allocation list. Based on the isolation domain processor time allocation list, monitor in real time the number of context switches of active processes in each isolation domain, the start and end time stamps of processor occupancy, and the number of instruction cycles consumed by each task execution. Align and map all the data with the current processor allocation cycle, and eliminate idle cycles and scheduling waiting segments to form a detailed list of task cycle usage in the isolation domain. Based on the detailed list of task cycle usage in the isolation domain, calculate the CPU time occupied by each isolation domain during the current scheduling cycle. Merge the intermediate states of cross-cycle tasks and the repeated measurement items in consecutive cycles, extract the processor occupancy of each isolation domain in the current period, and obtain the current domain resource occupancy value.

8. The security isolation method of the Internet of Things edge computing node according to claim 1, characterized in that The steps for obtaining the adjusted isolation domain operating parameters are as follows: Analyze the usage details of each CPU time slice in the current domain resource occupancy value, extract the corresponding process execution frequency, number of context switches, and idle cycle ratio. Combine the number of illegal data transmission events and their occurrence time distribution recorded in the data access audit record to generate a resource load correlation index set for the isolation domain during the current scheduling cycle. Based on the resource load correlation index set for the isolation domain during the current scheduling cycle, calculate the resource adjustment coefficient for each isolation domain. Based on the resource adjustment coefficient, combine the set CPU time reference value and the memory bandwidth upper limit, linearly scale the CPU time and bandwidth allocation ratio, write the updated computing resource configuration into the isolation domain operating parameter table, and establish the adjusted isolation domain operating parameters.

Images