An operating system kernel level data exchange based identification method

Abstract

The application discloses a kind of based on operating system kernel level data exchange identification method, it is related to operating system security and data exchange control technical field.The method is designed to solve the problems such as limited authority of traditional identification method, high monitoring delay, insufficient adaptability and unsafe data storage, by constructing kernel state security interception system, the storage resource call request of user state thread is captured in full by using dynamic patching technology and hangs up;Multi-dimensional feature quantization review is carried out to the thread, and the safety is judged according to the matching degree of preset security feature set and actual feature;Start the collaborative correlation analysis of call resources and thread characteristics, complete compliance verification based on dynamically updated multidimensional access control strategy matrix;AES-256 encryption record and life cycle management are carried out to compliant data exchange behavior, and the key is dynamically generated by kernel and stored safely.The application realizes accurate identification and closed-loop control of data exchange full link, and guarantees the security, real-time performance and traceability of system data exchange.

Description

Technical Field

[0001] This invention relates to the field of operating system security and data exchange management technology, specifically to a method for identifying data exchange based on the operating system kernel level. Background Technology

[0002] As operating systems handle increasingly complex business scenarios and the frequency and scale of data exchange continue to grow, the kernel, as the core hub for system resource scheduling and data flow, becomes crucial for ensuring the security and controllability of its data exchange, thus guaranteeing stable system operation. Traditional data exchange identification often relies on user-space monitoring tools, using system calls hooked or log files to collect data. However, these methods suffer from limitations such as restricted permissions, high monitoring latency, and susceptibility to circumvention by malicious processes. They are ill-equipped to address security threats posed by malicious kernel-level data exchange activities and cannot meet the demand for accurate identification of the entire data exchange process in complex scenarios.

[0003] Kernel-level data exchange directly touches upon underlying system resources, and its identification process must balance security, real-time performance, and compatibility. Existing technologies often focus on single-dimensional access control or monitor only specific types of storage resources, lacking a collaborative analysis mechanism that considers thread characteristics and the content of accessed resources. Furthermore, the characteristic data and request data generated during data exchange lack secure and reliable storage solutions, making them susceptible to data leakage or tampering risks, further reducing the credibility and traceability value of the identification results.

[0004] Chinese patent (publication number: CN118427160A) discloses a kernel-based file access control method and apparatus. Addressing the issue of coarse granularity in traditional access control, this patent proposes a method using inodes as the granularity, matching process namespaces with access control rules to achieve file access control, effectively enhancing the file system isolation between containers and the host machine. However, this technology focuses only on the single scenario of file access, failing to conduct comprehensive feature examination of the processes initiating access, and lacks a dynamic adjustment mechanism to adapt to the system's operating state. When faced with multiple types of storage resource calls and complex process behavior, its accuracy and adaptability are insufficient.

[0005] To address the limitations of the aforementioned patents in terms of application scenarios, Chinese Patent (Publication No.: CN118069071A) discloses a resource access control method, apparatus, computer device, and storage medium. This patent effectively reduces lock conflicts during thread concurrency and improves access efficiency for various resource types by constructing a target-oriented memory object pool and allocating resources based on the mapping relationship between thread identifiers and resource lists. However, this technology lacks a correlation analysis logic between thread characteristics and the content of the accessed resources, making it unable to accurately identify abnormal resource access behavior initiated by legitimate threads. Furthermore, it does not encrypt and protect data during the access process, posing a risk of data leakage. Additionally, it lacks a synchronous triggering mechanism with the resource access process, making it difficult to guarantee the real-time performance of the identification process.

[0006] Therefore, there is an urgent need for a kernel-level data exchange identification method that can achieve collaborative review of thread characteristics and called resource content, and has dynamic adaptation capabilities and secure storage mechanisms. This method should ensure the real-time performance and accuracy of identification while also ensuring the security and traceability of data records, providing a comprehensive and highly reliable identification and management solution for operating system kernel data exchange. Summary of the Invention

[0007] To address the aforementioned technical problems, this application discloses a method for identifying data exchange based on the operating system kernel level, comprising:

[0008] A kernel-mode security interception system is constructed. By using dynamic instrumentation technology to hook the system call table, all storage resource call requests initiated by user-mode threads are captured. At the same time, a context freeze mechanism is triggered, and the call process is suspended by saving the complete state of the thread's task_struct structure and register data.

[0009] The system performs multi-dimensional feature quantification review of incoming threads. It pre-sets a set of system security features including permission level, signature verification, runtime environment, and behavior pattern. It extracts the actual feature set of incoming threads and obtains the quantification matching result by calculating the feature matching degree. When the feature matching degree is not lower than the preset security threshold, the review is deemed to pass; otherwise, the call is rejected and the abnormal event is recorded.

[0010] Initiate a collaborative correlation analysis of resource calls and thread characteristics, construct a multi-dimensional access control policy matrix based on resource access permissions, data transmission rate, storage usage, and time window, extract feature vectors of called resource content, and achieve compliance judgment through dimensional threshold comparison. The policy matrix is ​​dynamically updated to adapt to the system's operating status in real time.

[0011] Full-link encrypted recording and lifecycle management are implemented for compliant data exchange activities. Thread characteristic data and resource request data are encrypted and stored using the AES-256 algorithm. The encryption key is dynamically generated by the kernel and stored in a secure storage area, thus completing the closed-loop control of the data exchange process.

[0012] Preferably, the process of initiating the storage resource access request is seamlessly integrated with the kernel-mode security interception system, specifically including:

[0013] S1.1: User-mode threads initiate a call request for a specific storage resource through the system call interface. The call request includes key parameters such as the target resource path, access mode, data buffer address, and transmission priority identifier.

[0014] S1.2: The user-mode thread submits a kernel object creation request to the operating system kernel, and establishes a unique association between the kernel object and the target specific storage resource through the resource identifier hash mapping mechanism. The association process synchronously generates an object attribute verification code.

[0015] S1.3: The user-mode thread triggers a kernel function call instruction, completes the context switch from user mode to kernel mode through a system call, and the kernel function call instruction triggers the generation of a storage resource call request, while activating the hook function of the kernel-mode dynamic instrumentation;

[0016] S1.4: The kernel function performs indirect management of the kernel object of the associated target storage resource, including kernel object attribute configuration, dynamic allocation of resource access permissions and establishment of encrypted data transmission channels, so as to realize compliant access requests to the associated storage resource, and the key operation logs of the management process are synchronized to the secure storage area in real time.

[0017] Preferably, the specific process of feature review is as follows:

[0018] Preset system security feature set ,in The number of system security features, For the first Each system security feature;

[0019] Extract the actual feature set of the thread that initiated the storage resource request. ,in The number of actual features in the thread. For the first The actual characteristics of each thread;

[0020] Calculate feature matching degree The formula is: ,when When =1, it is determined that the characteristics of the advancing thread meet the system security requirements, and the correlation analysis step is allowed;

[0021] when When the value is less than 1, it is determined that the characteristics of the thread do not meet the system security requirements, the storage resource call request is rejected and the call process is terminated, and the call termination event is recorded.

[0022] Preferably, the system security feature set This includes the thread's permission level characteristics, signature verification characteristics, runtime environment characteristics, and behavioral pattern characteristics, among which:

[0023] The permission level feature is represented by a numerical quantification, with a larger value indicating a higher permission level;

[0024] The signature verification feature is a binary variable. This indicates that the signature verification has passed. This indicates that the signature verification failed.

[0025] Operating environment characteristics include process startup path, memory usage range, and CPU utilization threshold;

[0026] Behavioral pattern characteristics are obtained through statistical analysis of thread history call records.

[0027] Preferably, the specific process of the association analysis is as follows:

[0028] Build the system's internal access control policy matrix ,in The number of access control dimensions. The number of policy thresholds for each dimension. For the first The first dimension Each strategy threshold;

[0029] Extract the content feature vector of the called resource ,in To call resources in the first Feature values ​​of each access control dimension;

[0030] When all are satisfied ,exist Make When the content of the called resource meets the system's internal access control policy, the data exchange behavior is allowed.

[0031] Otherwise, reject the storage resource call request and terminate the call process, recording the call termination event.

[0032] Preferably, the access control dimensions include resource access permission dimensions, data transfer rate dimensions, storage resource usage dimensions, and access time window dimensions, with policy thresholds for each dimension. Update dynamically using the following methods: ,in, For the first Time of the first The first dimension Each strategy threshold For the threshold update rate coefficient, For the first The first dimension The rate of change in demand for each strategy threshold.

[0033] Preferably, the operating system kernel is built based on a secure boot mechanism, and the trust state transfer model of the secure boot mechanism is as follows: ,in, This represents the trust status value of the system during the data exchange and identification process. The initial trust value provided for the trusted chip. For the first The weight coefficients of each trust transmission node. For the first The state parameters of each trust transmission node For the first State transition function for each trust-transferring node.

[0034] Preferably, the feature review and the initiation process of the storage resource call request are seamlessly connected through a kernel-mode triggering synchronization mechanism, specifically including:

[0035] During the instruction execution phase when a user-mode thread calls a kernel function, the kernel's instruction parsing module monitors the instruction execution progress in real time.

[0036] Once the parameter parsing of the calling instruction is completed and the kernel object association is established, a synchronization signal is triggered to the feature review module.

[0037] Upon receiving the synchronization signal, the feature review module immediately initiates the thread-based feature acquisition and verification process without waiting for subsequent operation instructions from the user-mode thread.

[0038] By configuring process scheduling priority in kernel mode, the scheduling priority of the feature review process is set to be higher than that of ordinary kernel tasks, ensuring that the startup delay of the review process is in the microsecond range and does not affect the normal operation of other core kernel functions.

[0039] Preferably, the recorded data is stored in an encrypted manner, and the encryption algorithm is as follows: ,in, For the thread characteristic data and resource request data to be recorded, The hash value of the data is calculated using the SHA-256 algorithm. The encryption key is dynamically generated by the operating system kernel and stored in a secure storage area.

[0040] Preferably, the identification and management of the data exchange process includes real-time monitoring, anomaly alarms, and log tracing, wherein:

[0041] Real-time monitoring uses a millisecond-level sampling period to collect data exchange traffic, frequency, and content characteristics in real time.

[0042] When data exchange behavior is detected to meet the anomaly detection criteria When an abnormal alarm is triggered, among which... To exchange feature values ​​for actual data, This is the threshold value for normal data exchange characteristics. This is the anomaly detection coefficient;

[0043] Log tracing supports multi-dimensional queries based on thread ID, time range, and resource type, and the log storage duration meets the system's preset tracing requirements.

[0044] Compared with the prior art, the technical solution of this application has the following technical effects:

[0045] This invention captures and suspends all storage resource call requests through a kernel-level interception mechanism. Combined with dual verification logic of thread feature review and resource call correlation analysis, it blocks illegal data exchange behavior at the source. Feature review is based on the accurate matching of system security feature set and actual features, while correlation analysis relies on a multi-dimensional access control policy matrix to achieve fine-grained verification. The two work together to form a closed-loop control, which greatly improves the accuracy of kernel-level data exchange identification and effectively avoids the security risk of malicious processes initiating abnormal data exchanges by masquerading as legitimate privileges.

[0046] The secure boot mechanism trust transfer model constructed in this invention ensures that the system trust state is effectively transferred from the source of the trusted chip, providing stable and reliable underlying support for the data exchange identification process. The feature review and resource call process are seamlessly connected through the kernel-mode trigger synchronization mechanism. The real-time performance of the review is guaranteed by optimizing the scheduling priority, avoiding the monitoring delay and process disconnect problems existing in traditional identification methods. Real-time identification and control of data exchange behavior are achieved without affecting the operation of the core kernel functions.

[0047] This invention uses a dynamic update algorithm to adaptively adjust the access control policy threshold, enabling the system to flexibly adapt to resource call requirements under different operating states. This significantly improves the scenario compatibility and scalability of the technical solution. The recorded data adopts a dual protection mechanism of AES-256 encryption algorithm combined with SHA-256 hash operation. The key is dynamically generated by the kernel and securely stored, ensuring the integrity and confidentiality of the audited data and providing reliable data support for tracing data exchange behavior.

[0048] This invention breaks down data exchange identification and management into three major functional modules: real-time monitoring, anomaly alarm, and log tracing, forming a full-process, multi-dimensional management system. Real-time monitoring enables comprehensive collection of data exchange characteristics, the anomaly alarm mechanism responds quickly to abnormal behavior, and log tracing supports accurate multi-condition queries. The synergistic effect of these three modules not only simplifies the management process of kernel-level data exchange but also provides efficient support for system security auditing and problem investigation, significantly improving the intelligence and convenience of operating system data exchange management.

[0049] The above description is only an overview of the technical solution of this application. In order to better understand the technical means of this application and implement it in accordance with the contents of the specification, and to make the above and other objects, features and advantages of this application more obvious and understandable, the preferred embodiments of this application are described in detail below with reference to the accompanying drawings.

[0050] The above and other objects, advantages and features of this application will become more apparent to those skilled in the art from the following detailed description of specific embodiments in conjunction with the accompanying drawings. Attached Figure Description

[0051] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort. In all drawings, similar elements or parts are generally identified by similar reference numerals. In the drawings, the elements or parts are not necessarily drawn to scale.

[0052] Based on the description of the figures and their corresponding technical content in the document, the titles of the figures are as follows:

[0053] Figure 1 : Overall process architecture diagram of operating system kernel-level data exchange and identification method;

[0054] Figure 2 Flowchart illustrating the seamless integration between storage resource request initiation and kernel-mode security interception system;

[0055] Figure 3 : Flowchart of closed-loop logic for multi-dimensional feature quantification review in the thread;

[0056] Figure 4 Flowchart for the collaborative analysis and compliance determination of resource calls and thread characteristics;

[0057] Figure 5 Flowchart of Dimensional Policy Matching Based on Access Control Policy Matrix and Feature Vector;

[0058] Figure 6 Flowchart of operating system secure boot trust transfer mechanism, status determination and policy adjustment;

[0059] Figure 7 : Module diagram of a kernel-level data exchange and identification system based on a user-mode and kernel-mode layered architecture;

[0060] Figure 8 : A graph showing the changes in identification metrics for different data block sizes under four typical kernel-level data exchange scenarios;

[0061] Figure 9 : Response latency, QPS, and resource usage graphs for different numbers of concurrent threads in a shared memory swapping scenario;

[0062] Figure 10 : Correlation diagram of recognition accuracy, data integrity and average jitter under different data exchange rates;

[0063] Figure 11 Graph showing changes in recognition accuracy, response latency, and resource consumption under a 72-hour uninterrupted operation scenario;

[0064] Figure 12 : Correlation between the number of data exchanges and feature matching scores in three types of data exchange scenarios;

[0065] Figure 13 : Correlation diagram of recognition response delay and accuracy corresponding to different data exchange priorities. Detailed Implementation

[0066] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. In the following description, specific details such as specific configurations and components are provided merely to help fully understand the embodiments of this application. Therefore, those skilled in the art should understand that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of this application. In addition, for clarity and brevity, descriptions of known functions and structures are omitted in the embodiments.

[0067] It should be understood that the phrase "an embodiment" or "this embodiment" throughout the specification means that a specific feature, structure, or characteristic related to the embodiment is included in at least one embodiment of this application. Therefore, "an embodiment" or "this embodiment" appearing throughout the specification does not necessarily refer to the same embodiment. Furthermore, these specific features, structures, or characteristics can be combined in any suitable manner in one or more embodiments.

[0068] Furthermore, reference numerals and / or letters may be repeated in different examples within this application. Such repetition is for the purpose of simplification and clarity and does not in itself indicate a relationship between the various embodiments and / or settings discussed.

[0069] In this article, the term "and / or" is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can mean: A exists alone, B exists alone, and A and B exist simultaneously. The term " / and" in this article describes another type of relationship between related objects, indicating that two relationships can exist. For example, A / and B can mean: A exists alone, and A and B exist alone. In addition, the character " / " in this article generally indicates that the related objects before and after it are in an "or" relationship.

[0070] In this article, the term "at least one" is merely a description of the relationship between related objects, indicating that there can be three relationships. For example, "at least one of A and B" can mean: A exists alone, A and B exist simultaneously, or B exists alone.

[0071] It should also be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion.

[0072] Example 1

[0073] This embodiment mainly describes a data exchange identification method based on the operating system kernel level, such as... Figure 1 As shown, it specifically includes:

[0074] A kernel-mode security interception system is constructed. By using dynamic instrumentation technology to hook the system call table, all storage resource call requests initiated by user-mode threads are captured. At the same time, a context freeze mechanism is triggered, and the call process is suspended by saving the complete state of the thread's task_struct structure and register data.

[0075] The system performs multi-dimensional feature quantification review of incoming threads. It pre-sets a set of system security features including permission level, signature verification, runtime environment, and behavior pattern. It extracts the actual feature set of incoming threads and obtains the quantification matching result by calculating the feature matching degree. When the feature matching degree is not lower than the preset security threshold, the review is deemed to pass; otherwise, the call is rejected and the abnormal event is recorded.

[0076] Initiate a collaborative correlation analysis of resource calls and thread characteristics, construct a multi-dimensional access control policy matrix based on resource access permissions, data transmission rate, storage usage, and time window, extract feature vectors of called resource content, and achieve compliance judgment through dimensional threshold comparison. The policy matrix is ​​dynamically updated to adapt to the system's operating status in real time.

[0077] Full-link encrypted recording and lifecycle management are implemented for compliant data exchange activities. Thread characteristic data and resource request data are encrypted and stored using the AES-256 algorithm. The encryption key is dynamically generated by the kernel and stored in a secure storage area, thus completing the closed-loop control of the data exchange process.

[0078] The process of initiating a storage resource request is seamlessly integrated with the kernel-mode security interception system, such as... Figure 2 As shown, it specifically includes:

[0079] S1.1: User-mode threads initiate a call request for a specific storage resource through the system call interface. The call request includes key parameters such as the target resource path, access mode, data buffer address, and transmission priority identifier.

[0080] S1.2: The user-mode thread submits a kernel object creation request to the operating system kernel, and establishes a unique association between the kernel object and the target specific storage resource through the resource identifier hash mapping mechanism. The association process synchronously generates an object attribute verification code.

[0081] S1.3: The user-mode thread triggers a kernel function call instruction, completes the context switch from user mode to kernel mode through a system call, and the kernel function call instruction triggers the generation of a storage resource call request, while activating the hook function of the kernel-mode dynamic instrumentation;

[0082] S1.4: The kernel function performs indirect management of the kernel object of the associated target storage resource, including kernel object attribute configuration, dynamic allocation of resource access permissions and establishment of encrypted data transmission channels, so as to realize compliant access requests to the associated storage resource, and the key operation logs of the management process are synchronized to the secure storage area in real time.

[0083] Interception of storage resource call requests is based on kernel-mode dynamic instrumentation. The `syscall_trace_enter` hook function is registered through a kernel module, hooking all system call entry points related to storage resource operations to achieve comprehensive capture of all call requests. The instrumentation process is completed through the kernel's kprobe mechanism, requiring no modification to the kernel source code. Hook function registration is achieved solely through dynamic module mounting. During mounting, the physical address of the system call table `sys_call_table` is obtained through kernel symbol table resolution. This physical address resolution uses the following formula: ,in The page index value returned by the kernel symbol lookup function. The system page size (configured by kernel parameters) definition), The offset of the kernel image in physical memory is determined by parsing the kernel ELF file. Segment retrieval. The entry address of the target system call is replaced with the address of the hook function. The atomicity of this replacement operation is determined by the formula: Guarantee, among which For the first The entry address of a system call. The address of the hook function. This is the original system call entry address, used for subsequent recovery.

[0084] After interception is triggered, the hangup mechanism is implemented by modifying the `task_struct` structure corresponding to the incoming thread: the `state` field in `task_struct` is set to `TASK_INTERRUPTIBLE`, and the `schedule()` function triggers process scheduling, removing the incoming thread from the CPU ready queue and transferring it to the blocked queue. During the hangup process, the kernel saves the complete context of the incoming thread using the `copy_thread()` function. The context saving is verified using the following formula: Verification, among which For register context data set, This is the process identifier for the current thread. This is a checksum for the context data, used to verify data integrity during recovery. The trigger sequence for hang-up is determined by the formula: Control, among which The time spent parsing system call parameters. Preprocessing time for kernel objects ensures that the triggering occurs after parameter parsing is complete and before the kernel object is created.

[0085] The extraction of parameters from storage resource access requests is implemented through the kernel's `get_user()` function, which reads key parameters from the user-space address space. During the extraction process, the `access_ok()` function verifies the validity of the user-space address. The validity verification formula is as follows: ,in User-space address, For parameter length, and These are the start and end addresses of the user-mode address space, respectively. This is a function for detecting the existence of a page. Logarithm of page size ( );

[0086] The extracted parameters are stored in a request_struct structure in kernel mode. This structure dynamically allocates memory using the kmalloc() function. The size of the allocated memory is calculated as follows: ,in For the first The length of each parameter For the first Alignment factor for each parameter (determined by data type, such as int type) long type Specifying the GFP_KERNEL flag during allocation ensures the safety of memory allocation.

[0087] like Figure 3 As shown, the feature review process for the thread is based on a closed-loop logic of baseline features, actual features, and matching verification. The formula for calculating the feature matching degree is as follows: System security feature set The system is built based on a kernel-based security configuration subsystem, which statically registers features through kernel modules. Each feature... For each independent feature description structure, feature_desc, the weights of the feature terms are assigned using the following formula: ,in For the first The security importance coefficient of each feature term (within a range of 1) (defined by the security policy configuration file) For the first The weights of each feature term satisfy the following condition: The dynamic updating of the feature set is achieved through the netlink communication mechanism. The consistency verification formula for the updated feature set is as follows: ,in For the updated number Each feature term For the previous version Each feature term Consistency threshold (default value) The new feature set can only be enabled after the verification is passed.

[0088] Actual feature set of advanced threads The data collection is implemented through the kernel's process feature extraction module, which iterates through all associated data of the thread using the `task_struct` structure. The quantitative extraction of permission level features uses the following formula: ,in This is the effective permission mask for the thread. The maximum number of privileges supported by the system (determined by kernel configuration parameters). definition), For the first The weight values ​​for each permission are configured through the system security policy file. Signature verification features are extracted using the formula: ,in The executable file hash value calculated for the IMA module. This is a set of whitelist hash values, loaded from a security whitelist file configured in the kernel. The CPU utilization calculation in the runtime environment characteristics uses the following formula: ,in User-mode runtime, For kernel-mode runtime, The total duration of each thread from startup to the present is obtained by reading the corresponding fields of the `task_struct` structure. The formula for calculating the call frequency in the behavioral pattern characteristics is: ,in For the first The number of resource calls within a statistical period To determine the starting period for statistics, This is the current statistical period; the length of the statistical period is determined by kernel parameters. definition.

[0089] Feature matching degree calculation is implemented through the kernel's matching engine module, and its core involves the intersection operation and quantization calculation of two feature sets. The intersection operation uses a hash table lookup mechanism, and the formula for calculating the bucket index of the hash table is: ,in For the first in the actual feature set 1 eigenvalue, The number of buckets in the hash table (using the formula) calculate, (where the total number of features is ), ensuring that the average time complexity of hash lookup is O(n). Intersection Count The atomic increment is achieved through the formula: Implementation, in which Atomic variables are used as counters for intersection feature terms to avoid concurrent counting errors. Feature matching degree. The calculations are performed through the floating-point arithmetic module. After the kernel enables the FPU unit, the calculation precision is determined by the formula: Guarantee, among which To calculate the matching degree, For theoretical matching degree, Precision threshold (default value) Matching results and preset thresholds ( The comparison is performed using the formula: Judgment, among which To match the tolerance level (determined by the system security level, basic security level) High security level ).

[0090] like Figure 4 As shown, the core of association analysis is the access control policy matrix. With feature vectors Dimensional matching. Access control policy matrix. The system is built upon the kernel's policy configuration module, with matrix data stored in a two-dimensional array `policy_matrix` within the kernel. The matrix elements... The initial value is obtained through the formula: Calculation, where For the first The baseline threshold for each access control dimension For the first The first dimension Scaling factor for each threshold (value range is...) (Defined by the policy configuration file). The integrity of the policy matrix is ​​verified using the following formula: Implementation, in which For the first A prime number is used to enhance the uniqueness of the verification. This is the checksum of the matrix, used to detect configuration file tampering.

[0091] Dynamic updates to the policy matrix are implemented through the kernel's sysfs interface, and the updated threshold... Through the formula: Calculation, where The threshold before the update. The threshold update rate coefficient (from the formula) Dynamic adjustment (This is the average system load). For the first The first dimension The demand change rate for each threshold is calculated using the following formula: ,in For the first Current statistical values ​​for each dimension This is the baseline statistic for this dimension. The atomicity of the update operation is guaranteed by a spinlock, and the lock holding time is specified by the formula: Control, among which Time taken to read the old threshold The time required to calculate the new threshold To ensure that the time taken to write to the new threshold does not exceed the kernel scheduling delay threshold, ensure that the lock holding time does not exceed the kernel scheduling delay threshold.

[0092] Feature vector The extraction is achieved through the kernel's resource parsing module, which parses the request_struct, the parameter structure storing resource call requests, and extracts the feature values ​​corresponding to each access control dimension. Resource access permission dimension feature values Through the formula: Calculation, where For the corresponding bits of the access mode mask (read mode) Write mode Execution mode Modify mode ), Weight values ​​for each mode (read mode) Write mode Execution mode Modify mode Data transmission rate dimension feature value Through the formula: Calculation, where The number of bytes of data requested to be transferred. Maximum transmission timeout (determined by kernel parameters) (Definition), results are in Mbps. Storage resource usage dimension feature values. Through the formula: Calculation, where Page density factor (determined by storage device type, mechanical hard drive) Solid State Drive Access time window dimension feature values Through the formula: Calculation, where A function to obtain the current system tick count, This is the starting beat number of the time window. This represents the system clock frequency; the result is in seconds.

[0093] The feature vector extraction process disables local interrupts and acquires a spinlock using the spin_lock_irqsave() function. The lock contention priority is determined by the formula: Definition, where Interrupt priority (fixed) ), The static priority of the current thread ensures the atomicity of the extraction process. The extracted feature vectors are stored in a kernel-mode `vector_struct` structure, and the memory allocation of this structure is determined by the formula: Calculation, where The number of access control dimensions. The storage length for each feature value is allocated from the kernel cache pool using the kmem_cache_alloc() function. The size of the cache pool is determined by the formula: Configure the cache pool to ensure it can hold 10 complete policy matrix data.

[0094] like Figure 5 As shown, policy matching is implemented through the kernel's policy matching engine, and its core is the matching of feature vectors. With the strategy matrix Dimensional comparison. The matching process employs a "short-circuit decision" mechanism, and the matching result for each dimension is determined by the formula: Calculation, where For logical OR operation, when the first... There exists a policy threshold in each dimension. satisfy hour, ,otherwise The global matching result is obtained through the formula: Calculation, where For logical AND operations, the global match result is 1 only when all dimensions match 1; otherwise, it is 0. The time taken for the matching process is expressed by the formula: Estimate, of which The time required for a single value comparison (determined by CPU clock speed) This ensures that the matching time does not exceed the system response threshold.

[0095] The core of encrypted data storage is the kernel-level encryption module, which integrates the SHA-256 hash algorithm and the AES-256 encryption algorithm. The formula is... Data to be encrypted The consolidation is achieved using the log_merge() function, and the length of the consolidated data is determined by the formula: Calculation, where The size of the memory hole in the structure is determined by the formula. calculate, This is the alignment factor for the structure. This represents the offset of a structure field. This refers to the field size.

[0096] The calculation of Hash(data) is implemented through the kernel's crypto_shash interface, and the integrity of the hash value is determined by the formula: Verification, among which This is the key for the HMAC algorithm (generated by the kernel random number generator), ensuring the hash value has not been tampered with. Encryption Key The key is generated through the kernel's random number generation module. The `get_random_bytes()` function retrieves a 32-byte random number from the kernel's entropy pool. The entropy value of the key is calculated using the formula: Calculation, where For the key The probability of occurrence of each byte is required. (i.e., full entropy). Key storage security is achieved through the formula: Guarantee, among which The root key (stored in the PCR register of the TPM chip) ensures that even if the key is stolen, it cannot be used directly.

[0097] XOR operation Implemented through the kernel's bitops interface, the parallelism of the operations is expressed by the formula: Optimization, among which The length of the hash value (256 bits). This refers to the number of CPU cores in the system, where efficiency is improved through multi-core parallel processing. The block operation for AES-256 encryption uses the following formula: ,in For the first One plaintext block (128 bits). For the first The initialization vector for each group is obtained through the formula. generate, The initial vector (generated by the kernel random number generator). The integrity of encrypted data is verified using the formula: Generate, where This is the key for the CMAC algorithm (different from the AES-256 encryption key, generated independently). This is an authentication tag used to verify data integrity during decryption.

[0098] Encrypted data is written to the kernel's security log file / dev / kernel_secure_log using the vfs_write() function. File access permissions are specified using the formula: Settings, where File owner permissions (default) (i.e., reading, writing, and executing). Group permissions (default) ), Grant other users permissions (default) The permission verification is enforced through the inode_permission() function, allowing only the root user with CAP_SYS_ADMIN privileges to read the data. The permission verification formula is as follows: ,in To access the user's user identifier, This is the valid permission mask.

[0099] Real-time monitoring is implemented through the kernel's timer module. The `setup_timer()` function is called to create a periodic timer, and the timer period is determined by the formula: Calculation, where The monitoring sampling frequency (configured by user space, default 100Hz) is used. This refers to the system clock frequency. The timer callback function `monitor_timer_cb()` is responsible for collecting data exchange characteristics. The amount of feature data collected is determined by the formula: Estimate, of which To ensure the average throughput of data exchange, the monitoring buffer can accommodate the collected data.

[0100] The monitoring buffer adopts a circular buffer design, and the size of the buffer is determined by the formula: Calculations are performed to ensure the buffer size is a power of 2, improving read / write efficiency. The read / write pointers of the circular buffer are synchronized using the formula: and Control, among which To read the pointer, To write pointers, To read the data length, The free space in the buffer is determined by the formula: (The formula is missing from the original text.) Calculate, when Data dump is triggered at any time. This is the free space threshold (1 / 4 of the default buffer size).

[0101] The core of anomaly alerts is the kernel's anomaly detection module, which compares the characteristic values ​​of the actual data exchanged. Compared with normal threshold Determine whether an alarm is triggered. Normal threshold. Calculated using the kernel's statistics module, employing the following formula: ,in This represents the average of the characteristic values ​​of historical normal data exchange. Standard deviation, mean The calculation uses the sliding window algorithm: ,in For the first The mean at time, For the first The mean at time, The size of the sliding window (default 100 sampling points). For the first Characteristic values ​​at time points. Standard deviation. The calculation formula is: .

[0102] Anomaly determination coefficient The configuration is implemented through the kernel's sysctl interface, and its dynamic adjustment formula is as follows: ,in This is the baseline coefficient (default 0.3). The system risk level is determined by the statistical results of security incidents, and the value range is [value range missing]. Anomaly detection is calculated using the following formula: Achieve, when An alarm is triggered at a specific time. The priority of alarm information is determined by the formula: Calculate, the range of values ​​is The higher the priority, the higher the priority of alarm information transmission.

[0103] Log traceability is implemented through the kernel's log indexing module, which creates a multi-dimensional index for each encrypted log entry. The index data is stored in a B+ tree structure within the kernel. The order of the B+ tree is determined by the formula: Calculation, where This is the header structure of a B+ tree node. For the index item structure, ensure that each B+ tree node can be fully stored in a single page. Index creation is achieved using the formula: Generate, where The timestamp (accurate to the second) for log entries. Encode the storage resource type to ensure the uniqueness of the index key.

[0104] Log queries are implemented through the kernel system call sys_log_query(), and the query results are sorted using the following formula: Generate, according to Sort in ascending order to ensure query results are returned in chronological order. Query performance is measured by the formula: Estimate, of which The total number of log entries is used to ensure that the query time remains within an acceptable range. The query results are decrypted using the formula: Implementation, in which This is the inverse operation of the hash value (implemented by looking up the hash table), ensuring the correctness of data decryption.

[0105] like Figure 6 As shown, Secure Boot trust transfer is based on the kernel's Trusted Execution Environment (TEE) interface, and the formula is: Initial root of trust The PCR register of the TPM chip is used to obtain the value of the PCR[0] register by calling the tpm_pcr_read() function. The integrity of the value is determined by the formula: Verification, among which For TPM reference functions, To verify the key, For a valid signature, ensure It has not been tampered with. The quantization value is obtained through the formula: Convert to The values ​​within the range.

[0106] Weight coefficient of trust transmission node By configuring the trust module in the kernel, the following conditions are met. The weighting coefficients are allocated using the entropy weighting method: ,in For the first The entropy value of each trusted node. For the first The node The probability of a state. The number of states of a node. The weight coefficients are calibrated using the formula: Implementation, in which The calibration factor (determined by the historical accuracy of trust transfer) , (To ensure historical trust and accuracy), ensuring that the calibration still meets the requirements. .

[0107] State parameters of trust transit node Collected via the kernel's trust monitoring module, each state parameter is quantified using the following formula: Convert to The values ​​in the interval, where This represents the actual state value of the node. and These represent the minimum and maximum values ​​of the state, respectively. State transition function. Using piecewise functions: ,in and State transition threshold (defined by security policy, default) , ).

[0108] Trust status value The calculation is performed through the kernel's trust calculation module, and the reliability of the calculation result is determined by the formula: Assessment, in which For the first The actual state transition value of each node, For credibility, it is required .when ( When the trust threshold (default 0.6) is reached, the `trust_enforce()` function is called to initiate a security enhancement mechanism, tightening the access control policy. The policy tightening factor is determined by the formula: The calculated policy threshold after tightening is: .

[0109] The synchronous triggering of feature inspection and resource access is implemented through the kernel's interrupt control module, and the delay of synchronous triggering is determined by the formula: Calculation, where Interrupt trigger time, The time consumed by soft interrupt handling The wake-up time of the feature review module is required to be... ( This is the synchronization delay threshold, with a default value of 10 microseconds. The transmission of synchronization signals is achieved through the kernel's software interrupt mechanism, and the priority of software interrupts is determined by the formula: Settings, where The highest soft interrupt priority, This is the importance coefficient for the synchronization signal (default 1), ensuring that the synchronization signal is processed first.

[0110] The synchronization of the review process and the resource retrieval process is achieved through a completion mechanism, and the waiting time for the resource retrieval process is expressed by the formula: Dynamic adjustment, among which Set the base timeout (default 100 milliseconds). This represents the average system load. Status monitoring during the waiting process is achieved using the formula: Set, every interval The review process status is checked periodically. If the review is complete, the resource retrieval process resumes immediately. If the review is not completed within the timeout period, the following formula is used: Forcefully terminate the resource call process to avoid deadlock.

[0111] This implementation details how to intercept storage resource call requests from user-mode threads using dynamic instrumentation and then suspend the thread, conduct multi-dimensional feature review of the incoming thread, perform collaborative correlation analysis between the called resources and the characteristics of the incoming thread, and perform end-to-end encrypted recording of compliant data exchange behavior to achieve closed-loop management.

[0112] Based on Example 1, this example describes in detail a data exchange and identification system based on the operating system kernel level, which achieves end-to-end data exchange and identification through a layered architecture of user space and kernel space, such as... Figure 7 As shown, it includes a user-entry thread module, a kernel function module, a data exchange and inspection module, and a kernel object module. It completes the connection through the privileged communication mechanism between kernel mode and user mode, realizing the process from user request initiation, kernel interception and inspection to resource authorization.

[0113] The user-entry thread module runs in user space and is the initiator of data exchange requests. This module submits storage resource access requests to kernel space through system call interfaces (such as `open`, `write`, etc.). Its request parameters include key information such as the target resource path, access mode, and data buffer address. When the user-entry thread initiates a resource call, the system triggers a software interrupt or a `syscall` instruction to switch the user-mode context to kernel mode. The request signal is then passed to the kernel function module through the kernel's system call processing chain.

[0114] The kernel function module, serving as the interaction hub between user space and kernel space, is deployed on the system call processing chain in kernel space. It is responsible for capturing all system call requests related to storage resources. This module hooks into the kernel system call table through dynamic instrumentation technology. When a resource call request from a user thread is detected, it immediately suspends the execution flow of the request and forwards the request parameters to the data exchange review module. The kernel function module is also responsible for resuming or terminating the execution of the user thread based on the review results after the review is completed. It is the core node that ensures the atomicity of system calls.

[0115] The data exchange review module is the core of the system's security verification. Located in the kernel space, it comprises two parallel processing units: an entry thread feature review submodule and a storage resource correlation analysis submodule. The entry thread feature review submodule collects feature data from kernel data structures such as `task_struct` and `cred`, including the effective permission mask, executable file hash value, CPU usage, and historical call frequency of the requesting entry thread. This data is then matched against a pre-defined set of security features, and the security of the entry thread is determined by calculating the feature matching degree. The storage resource correlation analysis submodule extracts the resource feature vector of the call request and compares it dimension-by-dimensionally with the system's internal access control policy matrix to determine the compliance of resource access. Only when both submodules pass the verification will the review module send an authorization signal to the kernel object module.

[0116] The kernel object module runs in kernel space and is the unit for mapping and authorizing storage resources. Upon receiving an authorization signal from the data exchange review module, this module creates a unique kernel object (such as a `file` structure or an `inode` structure) for the user thread and associates the kernel object with the target storage resource through a resource identifier hash mapping mechanism. The kernel object contains key attributes such as resource access permissions, data buffer address, and file offset. User threads can indirectly access storage resources by manipulating this kernel object. When data exchange is complete or the review fails, the kernel object module destroys the kernel object and releases the associated resources, ensuring efficient reclamation of system resources.

[0117] Furthermore, the system operates as follows: a user thread initiates a storage resource access request, which is passed to the kernel function module via the system call interface; the kernel function module captures the request and triggers a hang-up, forwarding the request parameters to the data exchange review module; the thread feature review submodule and the storage resource association analysis submodule perform parallel verification and generate review results; if the verification passes, the kernel object module creates a kernel object and authorizes the user thread to access the storage resource, and destroys the kernel object after the data exchange is completed; if the verification fails, the kernel function module terminates the user thread's request and records a security log.

[0118] This embodiment describes in detail how the system, through a layered design of user mode and kernel mode, combined with technologies such as dynamic instrumentation, feature matching, and matrix verification, achieves full-link identification and control of data exchange at the operating system kernel level, ensuring that every resource access undergoes strict security verification and effectively preventing malicious data exchange behavior.

[0119] Based on Embodiment 1 or 2, a kernel-level data exchange identification test environment was constructed using an x86 architecture server as the hardware platform, equipped with a Linux 5.15.0 kernel operating system, an Intel Xeon Gold 6348 processor (2.6GHz, 32 cores), 128GB DDR4 ECC memory, and 2TB NVMe SSD storage. The verification process focused on the identification accuracy, response latency, and resource consumption characteristics of the method under different data exchange intensities, data types, and concurrency scenarios. A multi-dimensional test dataset was generated using the controllable variable method. All test data were repeatedly tested three times, and the average value was taken. During the verification process, kernel-mode logs, memory page table switching records, and data exchange link characteristics were collected simultaneously.

[0120] In the initial validation phase, the basic recognition accuracy of the method was calibrated. Four typical kernel-level data exchange scenarios were selected (inter-process shared memory exchange, kernel-to-user space data copying, block device I / O data interaction, and network protocol stack kernel-to-user space data forwarding). For each scenario, 10 sets of different data block sizes were set (from 4KB to 1024KB, with a step size of 128KB). Each scenario was run for 10 minutes, recording the number of times the method recognized valid data exchange events and the actual number of occurrences. The recognition accuracy (Accuracy), false negative rate (MR), and false positive rate (FR) were calculated. To visually demonstrate the stability of recognition performance under different scenarios, such as... Figure 8 As shown, the attached figure contains 4 sub-figures ( Figure 8 (a)- Figure 8 (d) Figure 8(a) shows the change curve of recognition indicators in the shared memory swapping scenario. When the data block size is ≥64KB, the recognition accuracy is maintained at over 99.8%, the false recognition rate is less than 0.15%, and the false recognition rate is controlled within 0.05%. When the data block size is reduced to 16KB, the accuracy is still maintained at 99.2%, the false recognition rate rises to 0.6%, and the false recognition rate does not fluctuate significantly. This performance is due to the method's accurate capture of the switching of shared memory page table entries. Even if the page table changes caused by the swapping of small data blocks are slight, feature extraction can be completed through kernel hook functions. Figure 8 (b) Demonstrates the recognition effect of kernel mode and user mode data copying scenarios. The overall recognition accuracy is always higher than 99.5%, the false negative rate is no more than 0.3%, and it is not affected by the size of the data block, which shows the method's efficient recognition ability of copy_to_user / copy_from_kernel function call trajectory. Figure 8 (c) For block device IO data interaction scenarios, when the data block size is ≥256KB, the accuracy reaches 99.9% and the false negative rate is ≤0.08%. In small data block scenarios, frequent IO interruptions lead to increased interference in feature extraction, and the accuracy decreases slightly, but it still remains above 99.0%. Figure 8 (d) is the network protocol stack kernel mode data forwarding scenario. Affected by network packet fragmentation, the accuracy drops to 98.9% when the data block size is 64KB. In other scenarios, the accuracy remains above 99.4%, showing excellent scenario adaptability.

[0121] Based on the basic accuracy verification results, the performance of the method was further tested under different concurrent data exchange scenarios. The number of concurrent exchange threads was set from 8 to 128 (in increments of 16), the data block size was fixed at 256KB, and the inter-process shared memory exchange scenario was selected as the test object. The test was run continuously for 30 minutes, and the average response latency (Avg. Latency), number of recognitions per second (QPS), and kernel CPU usage were recorded simultaneously. Residential memory usage was also collected. This was done to present the impact of concurrency on performance, such as... Figure 9 As shown, the attached figure contains 3 sub-figures ( Figure 9 (a)~ Figure 9 (c) Figure 9 (a) Focusing on the relationship between response latency and concurrency, when the number of concurrent threads increases from 8 to 64, the average response latency gradually increases from 12.3 μs to 28.7 μs, an increase of 133.3%. When the number of concurrent threads exceeds 64, the latency growth rate slows down. The latency is 41.2 μs with 128 threads, which is still at the microsecond level. This shows that the method can still maintain low latency response in high concurrency scenarios. This is due to the lightweight design of the kernel hook function, which avoids blocking the data exchange link. Figure 9(b) shows the QPS curve as a function of concurrency. With 8 threads, the QPS is 8234, which increases linearly with the increase of concurrency. With 64 threads, the QPS reaches 49872, and with 128 threads, the QPS rises to 86541, which is close to the hardware processing limit, demonstrating good concurrency scalability. Figure 9 (c) The changes in kernel-mode CPU utilization and memory usage are shown. With 128 threads, the kernel-mode CPU utilization is 18.7% and the memory usage is 42.3MB. Even under the highest concurrency scenario, the resource usage is still within a reasonable range and will not interfere with other kernel services, thus verifying the resource friendliness of the method.

[0122] To quantify the adaptability of the method under dynamically changing data exchange rates, the data exchange rate was set from 100MB / s to 2000MB / s (in steps of 300MB / s), with a fixed number of concurrent threads of 32, a data block size of 512KB, and a test period of 15 minutes. The recognition accuracy, average jitter, and data integrity (the ratio of the amount of data recognized to the amount of data actually exchanged) were recorded at different rates. Figure 10 As shown in the test results, the recognition accuracy remained stable between 99.6% and 99.9% as the data exchange rate increased from 100MB / s to 2000MB / s, and the data exchange integrity remained above 99.8% without significant fluctuations. The average jitter gradually increased from 3.2μs to 7.8μs, an increase of 143.7%, but remained within the low jitter range overall. This performance stems from the dynamic feature threshold adjustment mechanism employed in the method, which optimizes the kernel-state feature extraction frequency in real time according to the data exchange rate, avoiding feature loss in high-speed scenarios while suppressing jitter and ensuring the stability of the recognition effect.

[0123] During the verification process, details of kernel-mode resource usage were collected synchronously. The analysis focused on page table usage (KB), cache hit rate (%), and system call overhead (ns) under different data exchange scenarios. Four typical scenarios were selected, each with a fixed data block size of 256KB and 16 concurrent threads, running continuously for 5 minutes to generate a detailed resource usage dataset. Table 1 (an advanced composite table containing scenario classification, resource usage indicators, and statistical data) was constructed based on this dataset. Note: Key abbreviations in Table 1 are as follows: PTU for Page Table Usage, CHR for Cache Hit Rate, SO for Syscall Overhead, SM for Shared Memory, KU for Kernel-User Copy, BD for Block Device IO, and NS for Network Stack Forwarding.

[0124] Table 1 Kernel-mode resource usage in four typical scenarios

[0125] Data exchange scenarios PTU CHR SO Context switching time Feature extraction time percentage SM 128.6 92.3 186.4 321.7 12.8 KU 96.3 89.7 213.8 289.4 15.2 BD 142.5 87.9 231.6 345.2 16.7 NS 135.8 90.1 204.5 312.6 14.3

[0126] As shown in Table 1, the method's PTU is below 150KB across all scenarios, CHR remains above 87%, SO is controlled within 250ns, and feature extraction time accounts for no more than 17%. This indicates that the method has a low level of kernel resource consumption and short context switching time, which will not cause significant performance loss to the original kernel data exchange link. Among them, the CHR is the highest in the SM scenario because shared memory exchange does not need to go through kernel-mode cache forwarding, and the dependence on cache during feature extraction is low. In the BD scenario, due to the involvement of block device I / O interaction, the cache hit rate is slightly lower, and the corresponding SO and feature extraction time accounts for slightly higher proportions, but overall they are still within a reasonable range.

[0127] To further verify the stability of the method under long-term continuous operation, a 72-hour uninterrupted test was conducted. A mixed concurrency mode of SM and NS scenarios was selected, with 64 concurrent threads, randomized data block sizes (4KB-1024KB), and data exchange rates fluctuating between 1000MB / s and ±200MB / s. Core metrics were collected hourly, including recognition accuracy, average response latency, kernel-mode CPU utilization, and memory leakage (KB / h). To present the trend of metric changes over long-term operation, such as... Figure 11 As shown, including Figure 11(a) Figure 11 (b), Figure 11 (a) Showing the changes in recognition accuracy and average response delay, the accuracy remained stable at 99.7% ± 0.1% within 72 hours, with no obvious downward trend; the average response delay fluctuated in the range of 25μs-32μs, with a fluctuation range not exceeding 28%, and there was no cumulative delay growth. Figure 11 (b) The kernel-level CPU utilization and memory leak situation are presented. The CPU utilization is stable at 15%±1.2%, the memory leak is controlled within 5KB / h, and the cumulative leak in 72 hours does not exceed 360KB, which is negligible. This shows that the method has no resource leakage problem during long-term operation, has good stability and reliability, and can meet the continuous operation requirements of server kernel-level data exchange and identification.

[0128] To address the challenge of identifying small data blocks in kernel-level data exchange, a separate verification was conducted. Data block sizes ranged from 1KB to 64KB (in 8KB increments), with a fixed number of concurrent threads of 32. Focusing on SM and KU scenarios, the recognition accuracy, false negative rate, and feature extraction success rate (in %) were recorded for different data block sizes. Simultaneously, feature matching records from kernel-mode logs were collected, and Table 2 (an advanced composite table containing data block size, scenario, and multi-dimensional indicators) was constructed. Note: (The key abbreviations in Table 2 are as follows: FESR for Feature Extraction Success Rate, MR for Miss Rate, FR for False Rate, and other abbreviations are the same as in Table 1.)

[0129] Table 2. Identification of small data blocks in kernel-level data exchange

[0130] Data block size Scene accuracy MR FR FESR Feature matching time 1 SM 97.2 2.5 0.3 96.8 178.3 1 KU 96.8 2.9 0.3 96.5 192.6 8 SM 98.7 1.1 0.2 98.5 185.4 8 KU 98.5 1.3 0.2 98.2 201.7 16 SM 99.2 0.6 0.2 99.0 190.8 16 KU 99.0 0.8 0.2 98.8 208.3 32 SM 99.6 0.3 0.1 99.5 196.2 32 KU 99.5 0.4 0.1 99.4 213.5 64 SM 99.8 0.1 0.1 99.7 201.5 64 KU 99.7 0.2 0.1 99.6 219.8

[0131] Table 2 clearly shows that even for extremely small data blocks of 1KB, the method's recognition accuracy remains above 96.8%, and the FESR remains above 96.5%. As the data block size increases, all indicators continue to optimize. At 64KB, the accuracy rises to over 99.7%, and the MR drops to below 0.2%, demonstrating a highly efficient ability to identify small data block exchanges. This advantage stems from the method's precise capture of the smallest feature unit of kernel-mode data exchange. By analyzing low-level features such as memory page frame allocation records and data buffer offset changes, it achieves effective identification of small data block exchange events. At the same time, the feature matching time is consistently kept below 220ns, preventing performance degradation due to high-frequency small data block exchanges.

[0132] To visually demonstrate the effectiveness of the method in feature extraction across different data exchange links, such as Figure 12 As shown, the subgraphs correspond to three scenarios: SM, KU, and NS, with a fixed data block size of 256KB and a concurrent thread count of 16. Figure 12 In (a), the feature matching scores of the SM scenario are concentrated between 0.92 and 0.98, with a fluctuation range of only 0.06, indicating that the shared memory exchange features are highly stable and the method can accurately match page table switching and memory read / write features. Figure 12 (b) The feature matching score of the KU scenario is between 0.90 and 0.96, which fluctuates slightly more than that of the SM scenario. This is because the buffer state changes more frequently during the data copying process between kernel mode and user mode, but the overall matching degree is still high. Figure 12 (c) The feature matching score of the NS scenario is between 0.89 and 0.95. Due to the dynamic changes in the network packet header information, the feature fluctuation is slightly large, but it always remains in the high score range, which verifies the adaptability of the method to different link features.

[0133] like Figure 13 As shown, the recognition performance of the method is presented in a data exchange priority scenario. During the test, the data block size was fixed at 256KB and the number of concurrent threads was 32. Kernel-mode resources were allocated to exchange tasks of different priorities, and the core indicators under each priority were recorded. The results show that for the high-priority task of priority 13, the recognition response latency was stable within 20μs, and the accuracy reached 99.9%; for the medium-priority task of priority 47, the latency was between 20μs and 30μs, and the accuracy remained between 99.7% and 99.8%; for the low-priority task of priority 810, the latency increased to 30μs-35μs, but the accuracy still remained above 99.6%. This performance indicates that the method can adapt to the kernel-level data exchange priority mechanism, prioritizing the recognition response speed and accuracy of high-priority tasks while not affecting the recognition effect of low-priority tasks, which is in line with the resource scheduling logic of kernel-mode services.

[0134] Through the above specific verifications, the operating system kernel-level data exchange recognition method of this application demonstrates the core advantages of high recognition accuracy, low response latency, low resource consumption, and good stability under different scenarios and parameter configurations. All the measured data have verified the feasibility and practicality of the method, which can meet the actual application requirements of operating system kernel-level data exchange recognition.

[0135] The above are merely preferred embodiments of the present invention and are not intended to limit the scope of protection of the present invention. For those skilled in the art, the present invention can have various modifications and variations. Any changes, modifications, substitutions, integrations, and parameter changes made to these embodiments within the spirit and principles of the present invention, without departing from the principles and spirit of the present invention, through conventional substitutions or to achieve the same function, fall within the scope of protection of the present invention.

Claims

1. A data exchange identification method based on the operating system kernel level, characterized in that, include: A kernel-mode security interception system is constructed. By using dynamic instrumentation technology to hook the system call table, all storage resource call requests initiated by user-mode threads are captured. At the same time, a context freeze mechanism is triggered, and the call process is suspended by saving the complete state of the thread's task_struct structure and register data. Perform multi-dimensional feature quantification review of the incoming thread, extract the actual feature set of the incoming thread, obtain the quantification matching result by calculating the feature matching degree, and determine that the review is passed when the feature matching degree is not lower than the preset safety threshold; otherwise, reject the call and record the abnormal event. Initiate a collaborative correlation analysis of resource invocation and thread characteristics, construct a multi-dimensional access control policy matrix, extract feature vectors of resource invocation content, and achieve compliance determination through dimensional threshold comparison. The policy matrix is ​​dynamically updated to adapt to the system's operating status in real time. Full-link encrypted recording and lifecycle management are implemented for compliant data exchange activities. Thread characteristic data and resource request data are encrypted and stored using the AES-256 algorithm. The encryption key is dynamically generated by the kernel and stored in a secure storage area, thus completing the closed-loop control of the data exchange process.

2. The method for identifying data exchange based on operating system kernel level according to claim 1, characterized in that, The process of initiating the storage resource access request is seamlessly integrated with the kernel-mode security interception system, specifically including: S1.1: User-mode threads initiate a call request for a specific storage resource through the system call interface. The call request includes key parameters such as the target resource path, access mode, data buffer address, and transmission priority identifier. S1.2: The user-mode thread submits a kernel object creation request to the operating system kernel, and establishes a unique association between the kernel object and the target specific storage resource through the resource identifier hash mapping mechanism. The association process synchronously generates an object attribute verification code. S1.3: The user-mode thread triggers a kernel function call instruction, completes the context switch from user mode to kernel mode through a system call, and the kernel function call instruction triggers the generation of a storage resource call request, while activating the hook function of the kernel-mode dynamic instrumentation; S1.4: The kernel function performs indirect management of the kernel object of the associated target storage resource, including kernel object attribute configuration, dynamic allocation of resource access permissions and establishment of encrypted data transmission channels, so as to realize compliant access requests to the associated storage resource, and the key operation logs of the management process are synchronized to the secure storage area in real time.

3. The method for identifying data exchange based on operating system kernel level according to claim 1, characterized in that, The specific process of the feature quantification review is as follows: Preset system security feature set ,in The number of system security features, For the first Each system security feature; Extract the actual feature set of the thread that initiated the storage resource request. ,in The number of actual features in the thread. For the first The actual characteristics of each thread; Calculate feature matching degree The formula is: ,when When =1, it is determined that the characteristics of the advancing thread meet the system security requirements, and the correlation analysis step is allowed; when When the value is less than 1, it is determined that the characteristics of the thread do not meet the system security requirements, the storage resource call request is rejected and the call process is terminated, and the call termination event is recorded.

4. The method for identifying data exchange based on operating system kernel level according to claim 3, characterized in that, The system security feature set This includes the thread's permission level characteristics, signature verification characteristics, runtime environment characteristics, and behavioral pattern characteristics, among which: The permission level feature is represented by a numerical quantification, with a larger value indicating a higher permission level; The signature verification feature is a binary variable. This indicates that the signature verification has passed. This indicates that the signature verification failed. Operating environment characteristics include process startup path, memory usage range, and CPU utilization threshold; Behavioral pattern characteristics are obtained through statistical analysis of thread history call records.

5. The method for identifying data exchange based on operating system kernel level according to claim 1, characterized in that, The specific process of the association analysis is as follows: Build the system's internal access control policy matrix ,in The number of access control dimensions. The number of policy thresholds for each dimension. For the first The first dimension Each strategy threshold; Extract the content feature vector of the called resource ,in To call resources in the first Feature values ​​of each access control dimension; When all are satisfied ,exist Make When the content of the called resource meets the system's internal access control policy, the data exchange behavior is allowed. Otherwise, reject the storage resource call request and terminate the call process, recording the call termination event.

6. The method for identifying data exchange based on operating system kernel level according to claim 5, characterized in that, The access control dimensions include resource access permission dimensions, data transfer rate dimensions, storage resource usage dimensions, and access time window dimensions, with policy thresholds for each dimension. Update dynamically using the following methods: ,in, For the first Time of the first The first dimension Each strategy threshold For the threshold update rate coefficient, For the first The first dimension The rate of change in demand for each strategy threshold.

7. The method for identifying data exchange based on operating system kernel level according to claim 1, characterized in that, The operating system kernel is built on a secure boot mechanism, whose trust state transfer model is as follows: ,in, This represents the trust status value of the system during the data exchange and identification process. The initial trust value provided for the trusted chip. For the first The weight coefficients of each trust transmission node. For the first The state parameters of each trust transmission node For the first State transition function for each trust-transferring node.

8. The method for identifying data exchange based on operating system kernel level according to claim 1, characterized in that, The feature review and the initiation process of the storage resource call request are seamlessly connected through a kernel-mode triggering synchronization mechanism, specifically including: During the instruction execution phase when a user-mode thread calls a kernel function, the kernel's instruction parsing module monitors the instruction execution progress in real time. Once the parameter parsing of the calling instruction is completed and the kernel object association is established, a synchronization signal is triggered to the feature review module. Upon receiving the synchronization signal, the feature review module immediately initiates the thread-based feature acquisition and verification process without waiting for subsequent operation instructions from the user-mode thread. By configuring process scheduling priority in kernel mode, the scheduling priority of the feature review process is set to be higher than that of ordinary kernel tasks, ensuring that the startup delay of the review process is in the microsecond range and does not affect the normal operation of other core kernel functions.

9. The method for identifying data exchange based on operating system kernel level according to claim 1, characterized in that, The recorded data is stored in an encrypted manner, and the encryption algorithm is as follows: ,in, For the thread characteristic data and resource request data to be recorded, The hash value of the data is calculated using the SHA-256 algorithm. The encryption key is dynamically generated by the operating system kernel and stored in a secure storage area.

10. The method for identifying data exchange based on operating system kernel level according to claim 1, characterized in that, The identification and management of the data exchange process includes real-time monitoring, anomaly alarms, and log tracing, wherein: Real-time monitoring uses a millisecond-level sampling period to collect data exchange traffic, frequency, and content characteristics in real time. When data exchange behavior is detected to meet the anomaly detection criteria When an abnormal alarm is triggered, among which... To exchange feature values ​​for actual data, This is the threshold value for normal data exchange characteristics. This is the anomaly detection coefficient; Log tracing supports multi-dimensional queries based on thread ID, time range, and resource type, and the log storage duration meets the system's preset tracing requirements.

Images