A Linux process code segment metric enhancement method based on a dual system architecture

Abstract

The application discloses a Linux process code segment measurement enhancement method based on a double system architecture, which comprises the following steps: S1, process benchmark value collection; S2, kernel key data monitoring mechanism addition; and S3, process real-time measurement. Based on a trusted execution environment, a set of prototype systems for real-time measurement of processes in a Linux operating system are realized on the basis of trusted starting. The prototype systems provide a mechanism for immediately initiating real-time measurement when abnormal kernel key data operation occurs while periodically measuring process code segments. The kernel key data comprises a system call table, an interrupt descriptor table, SELinux enabling and configuration information. The scheme solves certain TOCTTOU problems and enhances the security of the Linux system. The application realizes real-time measurement of processes related to kernel key data operation in a computing component operating system, enhances the security of the system during the operation of the operating system, guarantees the trustworthiness of the computing platform, and conforms to the active immunization trust idea.

Description

Technical Field

[0001] This invention relates to the field of information security, and specifically to a method for enhancing the measurement of Linux process code segments based on a dual-architecture system. Background Technology

[0002] Trusted computing is a comprehensive information security technology that enhances the trustworthiness of computer systems by using cryptography as its foundation and trusted chips as the source of trust. Its main idea is to establish a root of trust within the computing system, and then extend this trust from the root of trust to the hardware platform, operating system, and applications, measuring, authenticating, and trusting each level, thus extending this trust to the entire computer system. Control measures are then implemented to ensure the integrity of computing resources and the predictability of behavior, thereby improving the trustworthiness of the computing system.

[0003] In view of the shortcomings of the international TCG trusted computing theory, my country has summarized relevant theories of information security technology and proposed the Trusted 3.0 theory, namely, proactive immune trusted computing. Proactive immune trusted computing is a new computing model that performs security protection while computing. It adopts a dual system architecture that performs computing and protection in parallel. Security protection is performed during computing, so that the computing results always meet expectations, and the entire computing process is measurable, controllable, and uninterrupted.

[0004] The proactive immune trusted computing architecture establishes a dual architecture, including a computing component and a protection component. The original functional flow of the computing component remains unchanged, while a logically independent protection component is established in parallel. This protection component proactively implements trusted monitoring of the computing component, achieving trusted assurance throughout its entire lifecycle. The protection component uses the TPCM (Trusted Module Management) connected in parallel with the computing component as its root of trust. It starts before the computing component, proactively measuring and controlling it, becoming the source of system trust. Secondly, a trusted software base is constructed. This base connects to the trusted management mechanism above, implementing proactive monitoring under the guidance of security policies and rules; and schedules and manages trusted hardware resources such as the TPCM below, coordinating proactive measurement and control. The TPCM, as the root of trust, possesses proactive measurement capabilities and integrates the Trusted Measurement Root (RTM), Trusted Storage Root (RTS), and Trusted Reporting Root (RTR) into the TPCM, enhancing security.

[0005] Metrics is a trust quantification method that verifies the integrity of the measured object or assesses the degree to which entity behavior matches the expected description based on a benchmark value. Dynamic process measurement is a technique for protecting the integrity of processes during operating system operation. It can prevent processes from being illegally tampered with or damaged by malware, thereby improving the trustworthiness and security of the operating system. Existing methods for dynamic process measurement during operating system operation have some shortcomings. For periodic dynamic measurements, if the process measurement period is longer than the time when the process is attacked and the file system is corrupted, this measurement method may not be effective in defending against malicious processes attacking the Linux file system. Therefore, a real-time measurement method for processes accessing the Linux file system is needed to alleviate the TOCTTOU problem.

[0006] CN 114168934A, titled "A Kernel-Level Dynamic Process Measurement Method for Linux," is characterized by importing a measurement file into the Linux kernel state. This measurement file includes a preset executable ELF file. When executing a program and obtaining the first code of the executable ELF file, the program simultaneously obtains the first preset code. If the first code and the first preset code are inconsistent, an alarm log is generated. When running the program and verifying the correctness of its bprm file, the program compares the second code read from the executable ELF file with the second preset code. If they are inconsistent, an alarm log is generated. After the program calls the __schedule() function, it compares the third code included in the process pointed to by the current macro with the third preset code. If they are inconsistent, an alarm log is generated. This method is designed for the Linux operating system and ensures that the executable ELF file is not tampered with throughout the execution process. However, this method does not employ a dual-system architecture, cannot guarantee the security of the trusted benchmark library, and does not conform to the proactive measurement concept of Trusted Computing 3.0.

[0007] CN 113221117A, titled "A Dynamic Measurement Method for a Trusted Computing Platform Based on a Dual-Architecture Architecture," is characterized by providing a dynamic measurement method for a trusted computing platform based on a dual-architecture architecture. This method implements a two-level dynamic measurement engine within the kernel of the computing subsystem. This engine measures the process code segment and read-only data segment, and then passes the measurement results to the measurement engine of the protection subsystem for verification. The method intercepts the `exec_binprm` and `copy_process` hook functions in the computing subsystem kernel, calculates the HASH value, passes it to the baseline value module of the protection subsystem, and calculates the baseline value. The dynamic process measurement engine of the computing subsystem traverses the processes by scanning the kernel process list, measuring each process individually. This dynamic measurement method for a trusted computing platform based on a dual-architecture architecture can reduce the allocation of large blocks of contiguous physical memory, improving overall performance and stability. However, this method measures processes by periodically scanning the kernel process list. If the scanning period is longer than the time it takes for processes to be attacked or the file system to be corrupted, this measurement method may not be effective in defending against attacks.

[0008] CN 117313143A, titled "Method, System, Device, and Storage Medium for Protecting Critical Files in a DCS Host Computer," is characterized by monitoring the file access process through a Hook function and passing file parameters of the file to be accessed. The method determines whether the file to be accessed is in the host computer's trusted file list based on these parameters. If it is not in the list, the access is successful. Otherwise, it checks if the file is opened in read-only mode. If it is, the access is successful. If it is opened in read-only mode, it checks if the file's trust flag is at a first preset value. If it is not, the access is successful. Otherwise, the flag is cleared, the file's trust value is calculated, and the file's trustworthiness is determined. If the file is trustworthy, the access is successful; otherwise, the file is recovered from a redundant server, and the access fails. However, this method only measures the file itself and does not measure the trustworthiness of the process accessing the file, thus failing to prevent malicious processes from damaging the file. Summary of the Invention

[0009] This invention proposes a method for enhancing the security of Linux systems based on a dual-architecture approach, grounded in a trusted execution environment. Building upon trusted boot, it implements a prototype system for real-time process measurement during Linux operating system runtime. This prototype system periodically measures process code segments and provides a mechanism to immediately initiate real-time measurement when abnormalities occur in critical kernel data operations. Critical kernel data includes: system call tables, interrupt descriptor tables, SELinux enable and configuration information. This solution addresses certain TOCTTOU issues and enhances the security of the Linux system.

[0010] The purpose of this invention is to enable real-time measurement of processes related to kernel critical data operations during the operation of the operating system on the computing component, based on the completion of trusted boot of the device and without the impact of security protection components on the computing component. This enhances the security of the system during the operation of the operating system, ensures the trustworthiness of the computing platform, and conforms to the concept of proactive immune trust.

[0011] The technical solution adopted in this invention is a method for enhancing the measurement of Linux process code segments based on a dual-system architecture, which mainly includes three steps:

[0012] S1: Process baseline acquisition. By deploying LSM hook functions in the Linux computing component, ELF file information is obtained from the Linux system. The ELF header file is parsed to obtain the starting address and size of the .text segment, thereby calculating the process's trusted baseline and protecting the storage in the component.

[0013] S2: Addition of a kernel critical data monitoring mechanism. First, the virtual addresses where kernel critical data is stored in the Linux system are obtained; this kernel critical data includes: system call tables, interrupt descriptor tables, SELinux enable and configuration information. By monitoring whether permission abnormalities occur on the pages containing the virtual addresses of kernel critical data, such as write operations on read-only pages, process metrics are immediately initiated to check whether processes in the current Linux system have been modified.

[0014] S3: Real-time Process Measurement. When the Linux system initiates a process measurement request, it collects information about the process through the process's `task_struct` pointer, calculates a hash value as the measurement value, and sends it to the protection component for real-time reliable measurement of the process. The protection component returns the measurement result, and the operating system in the calculation component determines whether to stop the process based on the measurement result. Real-time measurement includes two scenarios: one is when an anomaly occurs in a critical kernel data operation, in which case the process is measured; the other is periodically measuring all processes in the process tree.

[0015] Furthermore, based on the Trusted 3.0 technical solution, a dual-architecture deployment environment is adopted, with the computing component environment being a Linux system and the protection component deploying TPCM, which has a certain degree of universality and effectiveness.

[0016] Furthermore, after the Linux system completes trusted boot, the Linux system will utilize the hardware platform's data isolation and protection mechanisms to establish a secure shared memory area between the computing component and the protection component for secure data communication between the two.

[0017] Furthermore, on the computing component, a metrics agent is deployed on the Linux operating system, which includes the following core components:

[0018] Baseline value acquisition module: This module registers the hook function bprm_check_security() with the kernel's exec() system call so as to obtain the baseline value information of the code segment before the process is executed, and ensure that its integrity is not compromised.

[0019] Kernel Critical Data Monitoring Module: This module first obtains the location of the kernel's critical data stored in the system as the detection address. Then, it uses Kprobe probes to intercept the `do_page_fault` function to detect changes in page permissions. Specifically, it uses kprobes to dynamically insert hooks into the `do_page_fault` function, capturing relevant information when a page fault occurs and detecting whether abnormal operations have occurred at the detection address, such as write operations to a read-only page. Process metrics are triggered when abnormal conditions occur.

[0020] Process metric acquisition module: It is responsible for obtaining the memory page address corresponding to the application process code segment through the mm_struct structure of the process, collecting the real-time metric value of the process code segment in memory page by page, and sending it to the protection component benchmark library.

[0021] Within the protection component, a trusted benchmark library is deployed to store benchmark values ​​for process code segments and to provide a basis for measurement judgments based on the results of metric value matching.

[0022] Furthermore, the process baseline value acquisition process is as follows:

[0023] First, the LSM hook function `bprm_check_security()` hooks the `bprm` structure corresponding to a normal application, obtaining a file pointer. The ELF header table is then parsed to read the start address and size of the stored `.text` segment, thus determining the start and end addresses. Next, the `.text` segment content is read page by page in 4KB units, and a digest value is calculated using the SM3 hash algorithm. A corresponding digest value is generated for each 4KB page, and these multiple digest values ​​are used as a baseline value. The communication module forwards the calculated baseline values ​​to the protection component, which stores them in a trusted baseline library.

[0024] Furthermore, the process of establishing the kernel critical data monitoring module is as follows:

[0025] First, to monitor critical kernel data, the addresses where this data is stored in the system are obtained. These addresses are located by parsing the kernel symbol table. If a symbol is not exported, its address to be monitored is obtained by parsing kallsyms. Page permission changes are detected by intercepting the `do_page_fault` function. The Linux kernel's kprobes mechanism is used to dynamically insert hooks before `do_page_fault` executes. `do_page_fault` is the core function for handling page faults; it is triggered when a process attempts to access an invalid or permission-incompatible virtual address. kprobes allows capturing and analyzing page faults before this function executes. When a page fault occurs, `do_page_fault` stores the virtual address that triggered the fault in the CR2 register. The hook retrieves this address by reading CR2. The hook code further checks if this address is the address to be monitored. If it is, the hook parses the page table entry (PTE) for that virtual address and uses the information in the page table to determine if the page has the correct access permissions.

[0026] Furthermore, the real-time process measurement process is as follows.

[0027] When a hook function is triggered and a change in permissions at the monitored address is detected, a page fault caused by the permission change or mismatch is detected. In this case, it indicates that the Linux system may have encountered an anomaly, and the Linux system will immediately perform a measurement on all processes.

[0028] Specifically, the Linux system traverses all processes in the process tree, obtains the corresponding `task_struct`, and reads the `mm_struct` structure within the `task_struct` to access the virtual address range of the process's runtime code segment. Then, it obtains the physical address corresponding to the virtual address: each page's page table entry records the mapping relationship between the virtual page and the physical page frame for that application process. The data item of the corresponding page table entry for the virtual page is read, and the corresponding physical page is calculated. The physical page is mapped to the kernel's `vmalloc` area using the `kmap()` function. The kernel performs SM3 operations on the data within that page. Then, based on the process's page table, the same process is used to measure the data of the next virtual page until all virtual pages of the process have been processed. After processing, the communication module sends the measurement value to the trusted benchmark library of the protection component for measurement and returns the measurement result. If the measurement fails, the process has been tampered with, and the process is immediately stopped.

[0029] Compared to existing technologies, relying solely on periodic dynamic measurement mechanisms poses certain security risks. If the process measurement period is too long, for example, longer than the time it would take an attacker to intrude and corrupt the file system, then the attack could occur between two measurements, leading to the failure of the system's security defenses.

[0030] To address this deficiency, this invention introduces a real-time monitoring mechanism based on page read / write permission access control, in addition to periodic process measurement. Specifically, the system closely monitors changes in the read / write permissions of the pages storing critical kernel operation data. If a change indicates a potential attack, a process measurement is immediately initiated.

[0031] The system retrieves critical kernel operation data addresses, including the system call table, interrupt descriptor table, SELinux enable and configuration information, by parsing kallsyms as the addresses to be monitored. It then registers a Kprobe probe to intercept the `do_page_fault` function. If a problem with page read / write permissions is detected, the system immediately initiates a process measurement module to perform emergency measurements and assessments on suspicious processes. If the measurement fails, indicating a security risk in the process's behavior, the system immediately terminates the process to prevent further escalation of the potential threat.

[0032] This invention provides a novel dynamic process measurement triggering mechanism, avoiding the TOCTTOU problem that may exist in static and dynamic measurements, and enhancing the security of the Linux system. In this invention, the trusted benchmark library is stored in the protection component, and the measurement value verification function is completed through the protection component, which conforms to the basic idea of ​​proactive measurement in Trusted Computing 3.0. Attached Figure Description

[0033] Figure 1 This is an architecture diagram of a Linux process code segment metric enhancement method based on a dual-architecture system.

[0034] Figure 2 The flowchart shows a method for enhancing the measurement of Linux process code segments based on a dual-architecture system. Detailed Implementation

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

[0036] Figure 1 This is an architecture diagram of a Linux process code segment metric enhancement method based on a dual-architecture system.

[0037] Figure 2 The flowchart shows a method for enhancing the measurement of Linux process code segments based on a dual-architecture system.

[0038] The purpose of this invention is to enable real-time measurement of processes related to kernel critical data operations during the operation of the operating system on the computing component, based on the completion of trusted boot of the device and without the impact of security protection components on the computing component. This enhances the security of the system during the operation of the operating system, ensures the trustworthiness of the computing platform, and conforms to the concept of proactive immune trust.

[0039] The present invention provides a method for enhancing the measurement of Linux process code segments based on a dual-system architecture. This method mainly consists of three parts:

[0040] Part 1: Process Baseline Value Acquisition. By deploying LSM hook functions in the Linux computing component, information about ELF files in the Linux system is obtained. The ELF header file is parsed to obtain the starting address and size of the .text segment, thereby calculating the process's trusted baseline value and protecting the storage within the component.

[0041] Part Two: Adding a Kernel Critical Data Monitoring Mechanism. First, the virtual addresses of critical kernel data stored in the system are obtained. Critical kernel data includes: the system call table, interrupt descriptor table, SELinux enable and configuration information, etc. The system monitors whether there are permission abnormalities on the pages containing the virtual addresses of critical data. For example, if a write operation is performed on a read-only page, process metrics are immediately initiated to check whether any processes in the current system have been modified.

[0042] Part Three: Real-time Process Measurement. When the system initiates a process measurement request, it collects information about the process through the process's `task_struct` pointer, calculates a hash value as the measurement value, and sends it to the protection component for real-time reliable measurement of the process. The protection component returns the measurement result, and the operating system in the calculation component determines whether to stop the process based on the measurement result. Real-time measurement mainly includes two situations: one is when an anomaly occurs in a critical kernel data operation, in which case the process is measured; the other is to periodically measure all processes in the process tree.

[0043] This invention is based on the Trusted 3.0 technology solution and adopts a dual-architecture deployment environment. The computing component environment is a Linux operating system, and the protection component deploys TPCM, which has certain universality and effectiveness. The specific implementation includes the following process.

[0044] Process 1: Initialization phase.

[0045] After the operating system completes trusted boot, the system will use the hardware platform's data isolation and protection mechanisms to establish a secure shared memory area between the computing component and the protection component for secure data communication between the two.

[0046] On the computing component, a metrics agent is deployed at the Linux operating system kernel level. This agent contains the following core components:

[0047] (1) Baseline value acquisition module: This module registers the hook function bprm_check_security() with the kernel's exec() system call so as to obtain the baseline value information of the code segment before the process is executed, and ensure that its integrity is not compromised.

[0048] (2) Kernel Critical Data Monitoring Module: This module first obtains the location of the kernel critical data stored in the system as the detection address. Then, it uses the Kprobe probe to intercept the do_page_fault function to detect changes in page permissions. Specifically, it uses kprobes to dynamically insert hooks into the do_page_fault function, capturing relevant information when a page fault occurs and detecting whether abnormal operations occur at the detection address, such as write operations on read-only pages. Process metrics are triggered when abnormal situations occur.

[0049] (3) Process metric acquisition module: It is responsible for obtaining the memory page address corresponding to the application process code segment through the mm_struct structure of the process, collecting the real-time metric value of the process code segment in memory in pages, and sending it to the protection component benchmark library.

[0050] Within the protection component, a trusted benchmark library is deployed to store benchmark values ​​for process code segments and to provide a basis for measurement judgments based on the results of metric value matching.

[0051] Process 2: Process baseline value acquisition.

[0052] First, the LSM hook function `bprm_check_security()` hooks the `bprm` structure corresponding to a normal application, obtaining a file pointer. The ELF header table is then parsed to read the start address and size of the stored `.text` segment, thus determining the start and end addresses. Next, the `.text` segment content is read page by page in 4KB units, and a digest value is calculated using the SM3 hash algorithm. A corresponding digest value is generated for each 4KB page, and these multiple digest values ​​are used as a baseline value. The communication module forwards the calculated baseline values ​​to the protection component, which stores them in a trusted baseline library.

[0053] Process 3: Establishment of the kernel critical data monitoring module.

[0054] First, to monitor critical kernel data, it's necessary to obtain the address where this data is stored in the system. This address can be found by parsing the kernel symbol table. If the symbol is not exported, its address can be obtained by parsing kallsyms. Page permission changes are detected by intercepting the `do_page_fault` function, using the Linux kernel's kprobes mechanism to dynamically insert a hook before `do_page_fault` executes. `do_page_fault` is the core function for handling page faults, triggered when a process attempts to access an invalid or permission-incompatible virtual address. kprobes allows us to capture and analyze page faults before this function executes. When a page fault occurs, `do_page_fault` stores the virtual address that triggered the fault in the CR2 register, and the hook obtains this address by reading CR2. The hook code can further check if this address is the address to be monitored. If it is, the hook parses the page table entry (PTE) of that virtual address, using the information in the page table to determine if the page has the correct access permissions, such as whether it is read-only, write-allowed, or executable. In this way, we can monitor changes in permissions of the address under monitoring in real time and detect page errors caused by permission changes or mismatches, such as writing to a read-only page or accessing a non-executable page.

[0055] Process 4: Real-time process measurement.

[0056] When the hook function is triggered and a change in permissions at the monitored address is detected, a page error caused by the permission change or mismatch is detected. In this case, it indicates that a system anomaly may have occurred, and the system will immediately perform a measurement on all processes in the system.

[0057] Specifically, the system traverses all processes in the process tree, obtains the corresponding `task_struct`, and reads the virtual address range of the process's runtime code segment by reading the `mm_struct` structure within the `task_struct`. Then, it obtains the physical address corresponding to the virtual address: each page's page table entry records the mapping relationship between the virtual page and the physical page frame for that application process. The system reads the data item of the corresponding page table entry for the virtual page and calculates the corresponding physical page. The physical page is mapped to the kernel's `vmalloc` area using the `kmap()` function. The kernel performs SM3 operations on the data within that page. Then, based on the process's page table, it measures the data of the next virtual page according to the same process until all virtual pages for that process have been processed. After processing, the communication module sends the measurement value to the trusted benchmark library of the protection component for measurement and returns the measurement result. If the measurement fails, the process has been tampered with, and the process is immediately stopped.

[0058] Relying solely on periodic dynamic measurement mechanisms poses certain security risks. If the process measurement period is too long, for example, longer than the time it would take an attacker to intrude and corrupt the file system, then the attack could occur between two measurements, leading to the failure of the system's security defenses.

[0059] To address this deficiency, this invention introduces a real-time monitoring mechanism based on page read / write permission access control, in addition to periodic process measurement. Specifically, the system closely monitors changes in the read / write permissions of the pages storing critical kernel operation data. If a change indicates a potential attack, a process measurement is immediately initiated.

[0060] The system retrieves critical kernel operation data addresses, including the system call table, interrupt descriptor table, SELinux enable and configuration information, by parsing kallsyms as the addresses to be monitored. It then registers a Kprobe probe to intercept the `do_page_fault` function. If a problem with page read / write permissions is detected, the system immediately initiates a process measurement module to perform emergency measurements and assessments on suspicious processes. If the measurement fails, indicating a security risk in the process's behavior, the system immediately terminates the process to prevent further escalation of the potential threat.

[0061] This invention provides a novel dynamic process measurement triggering mechanism, avoiding the TOCTTOU problem that may exist in static and dynamic measurements, and enhancing the security of the Linux system. In this invention, the trusted benchmark library is stored in the protection component, and the measurement value verification function is completed through the protection component, which conforms to the basic idea of ​​proactive measurement in Trusted Computing 3.0.

Claims

1. A method for enhancing the measurement of Linux process code segments based on a dual-architecture system, characterized in that, It includes three steps: S1: Process baseline value acquisition; By deploying LSM hook functions in the Linux computing component, information about ELF files in the Linux system is obtained, and the starting address and size of the .text segment are obtained by parsing the ELF header file, thereby calculating the process trust baseline value and protecting the storage in the component; S2: Added kernel critical data monitoring mechanism; First, obtain the virtual address where the kernel critical data is stored in the Linux system; The kernel critical data includes: system call table, interrupt descriptor table, SELinux enable and configuration information; Monitor whether there are permission abnormalities on the page where the virtual address of the kernel critical data is located; S3: Real-time process measurement; When the Linux system initiates a process measurement request, it collects information about the process through the process's task_struct structure pointer, calculates a hash value as the measurement value, and sends it to the protection component for real-time reliable measurement of the process. The protection component returns the measurement result, and the operating system of the calculation component determines whether to stop the process based on the measurement result. Real-time measurement includes two situations: one is when an anomaly occurs in the kernel's critical data operation, in which case the process is measured; the other is to periodically measure all processes in the process tree. The process of establishing the kernel critical data monitoring module is as follows: First, to monitor critical kernel data, the addresses where this data is stored in the system are obtained. These addresses are found by parsing the kernel symbol table. If a symbol is not exported, its address to be monitored is obtained by parsing kallsyms. Page permission changes are detected by intercepting the `do_page_fault` function. The Linux kernel's kprobes mechanism is used to dynamically insert hooks before `do_page_fault` executes. `do_page_fault` is the core function for handling page faults; it is triggered when a process attempts to access an invalid or permission-incompatible virtual address. kprobes allows capturing and analyzing page faults before this function executes. When a page fault occurs, `do_page_fault` stores the virtual address that triggered the fault in the CR2 register. The hook obtains this address by reading CR2. The hook code further checks whether this address is the address to be monitored. If it is, the hook parses the page table entry (PTE) of that virtual address and uses the information in the page table to determine whether the page has the correct access permissions. The real-time process measurement process is as follows; When a hook function is triggered and a change in permissions at the monitored address is detected, and a page fault caused by a permission change or mismatch is detected, it indicates that the Linux system may have encountered an anomaly. The Linux system will immediately perform a measurement on all processes. The Linux system traverses all processes in the process tree, obtains the corresponding `task_struct`, and reads the `mm_struct` structure within the `task_struct` to access the virtual address range of the process's runtime code segment. Then, it obtains the physical address corresponding to the virtual address. Each page's page table entry records the mapping relationship between the virtual page and the physical page frame for that application process. The system reads the data item from the corresponding page table entry for the virtual page and calculates the corresponding physical page. The physical page is then mapped to the kernel's `vmalloc` area using the `kmap()` function. The kernel performs SM3 operations on the data within that page. Following the same process, it measures the data of the next virtual page according to the process's page table until all virtual pages of the process have been processed. After processing, the communication module sends the measurement value to the trusted benchmark library of the protection component for further measurement and returns the measurement result. If the measurement fails, the process has been tampered with, and the process is immediately stopped.

2. The method for enhancing Linux process code segment metrics based on a dual-architecture system as described in claim 1, characterized in that, Based on the Trusted 3.0 technology solution, the experimental environment is deployed using a dual architecture: the computing component environment is a Linux system, and the protection component deploys TPCM.

3. The method for enhancing Linux process code segment metrics based on a dual-architecture system as described in claim 2, characterized in that, After the Linux system completes trusted boot, it uses the hardware platform's data isolation and protection mechanisms to establish a secure shared memory area between the computing and protection components for secure data communication between them.

4. The method for enhancing Linux process code segment metrics based on a dual-architecture system as described in claim 3, characterized in that, On the computing component, a metrics agent is deployed on the Linux operating system. This metrics agent contains the following core components: Baseline value acquisition module: This module registers the hook function bprm_check_security() with the kernel's exec() system call so as to obtain the baseline value information of the code segment before the process is executed, and ensure that its integrity is not compromised; Kernel Critical Data Monitoring Module: This module first obtains the location of the kernel critical data stored in the system as the detection address. Then, it uses Kprobe probes to intercept the do_page_fault function to detect changes in page permissions. Specifically, it uses kprobes to dynamically insert hooks into the do_page_fault function, captures relevant information when a page fault occurs, and detects whether there are abnormal operations at the detection address, such as write operations to a read-only page. When abnormal conditions occur, it triggers process metrics. Process metric acquisition module: responsible for obtaining the memory page address corresponding to the application process code segment through the mm_struct structure of the process, collecting the real-time metric value of the process code segment in memory page by page, and sending it to the protection component benchmark library; Within the protection component, a trusted benchmark library is deployed to store benchmark values ​​for process code segments and to provide a basis for measurement judgments based on the results of metric value matching.

5. The method for enhancing Linux process code segment metrics based on a dual-architecture system as described in claim 1, characterized in that, The process of acquiring baseline values ​​is as follows: First, the LSM hook function bprm_check_security() is used to hook the bprm structure corresponding to the ordinary application to obtain the file pointer. The ELF header table is parsed to read the start address and size of the .text segment, thereby determining the start and end addresses. Then, the contents of the .text segment are read page by page in 4KB units, and the digest value is calculated using the SM3 hash algorithm to generate a corresponding digest value for each 4KB page. The generated digest values ​​are used as the base value. The communication module forwards the calculated baseline values ​​to the protection components and stores them in the trusted baseline library.

Images