A kernel data integrity protection method based on TrustZone
By using TrustZone technology and a monitor to generate volume shadow copies in Secure World, this method solves the problems of high overhead and insufficient protection of non-control flow data in existing technologies for memory corruption attacks, and achieves efficient and reliable kernel data integrity protection.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- NANJING UNIV OF AERONAUTICS & ASTRONAUTICS
- Filing Date
- 2022-11-30
- Publication Date
- 2026-06-30
AI Technical Summary
Existing technologies incur significant overhead and lack protection for non-control flow data when protecting the operating system kernel from memory corruption attacks, especially without special hardware support.
A kernel-based data integrity protection method based on TrustZone is adopted. By inserting monitoring code into the compiler, the monitor generates and inspects volume shadow copies of security-critical data in Secure World. Combined with OCRAM and TrustZone technology, efficient data integrity protection is achieved.
It provides low-overhead and highly reliable defense against memory corruption attacks, protects the operating system kernel and applications, extends protection for return addresses, function pointers, vtable pointers and user-commented non-control data, and performs integrity checks without context switching.
Smart Images
Figure CN115964758B_ABST
Abstract
Description
Technical Field
[0001] This invention belongs to the field of system security, and in particular relates to a kernel data integrity protection method based on TrustZone. Background Technology
[0002] In reality, operating system kernels contain vulnerabilities, making data in memory susceptible to memory corruption attacks. Once an attacker compromises the operating system kernel, they can gain root privileges and perform any malicious operation they desire, including manipulating underlying hardware, executing arbitrary code, and reading or writing arbitrary data in memory or on disk.
[0003] Memory corruption attacks can be broadly categorized into two types: control-oriented and data-oriented. Defenses against control flow hijacking attacks include Data Execution Prevention (DEP), memory randomization (such as ASLR and DSR), and Control Flow Integrity (CFI). Defenses against data-oriented attacks include Dynamic Attack Analysis (DTA) and Data Flow Integrity (DFI).
[0004] However, the existing methods described above have many shortcomings. For example, these defenses incur significant overhead without specialized hardware support, control flow may be affected by non-control flow data, and the defense measures primarily focus on control flow protection, lacking protection for non-control flow data. Summary of the Invention
[0005] The technical problem to be solved by the present invention is to provide a kernel data integrity protection method based on TrustZone, which protects the operating system kernel (including applications) from memory corruption attacks with less overhead and higher reliability through out-of-band methods.
[0006] The present invention discloses a kernel data integrity protection method based on TrustZone, comprising:
[0007] Step 1: Input the source code of the kernel and the application to be protected into the compiler. The compiler performs static analysis to identify all security-critical data that needs to be protected and inserts the necessary monitoring code into the program to report operations related to the target to be protected to a monitor running on an independent operating system.
[0008] Step 2: After receiving a legitimate (i.e., original program-defined) operation on security-critical data in a protected program, the monitor generates or updates a volume shadow copy of the security-critical data in a dedicated table. Later, when the security-critical data is used, the monitor checks the integrity of the critical data by comparing its runtime value with the volume shadow copy. If a mismatch is detected, it indicates that the security-critical data in the protected program has been illegally modified. In response, the monitor terminates the corresponding program and reports the violation to the user via the proc filesystem.
[0009] In step 1, the security-critical data of the kernel (and the application to be protected) in memory includes:
[0010] Return address;
[0011] Function pointers;
[0012] Vtables pointers;
[0013] User-annotated non-control data.
[0014] Step 1 includes the following steps:
[0015] Step 1-1: The compiler locates the target, determines the location where code should be inserted into the application or kernel to be protected, and reports the target memory data.
[0016] Steps 1-2: The compiler performs code instrumentation to obtain an enhanced program with security code inserted.
[0017] Steps 1-3 enhance the operation of security-critical data in the program, transferring it from NormalWorld to the monitor in SecureWorld via high-speed shared memory OCRAM;
[0018] Steps 1-4: The protected program reports five types of operations to the monitor, including OP_STORE, OP_LOAD, OP_PUSH, OP_POP, OP_FORK, and OP_FREE, to monitor the lifecycle of security-critical data.
[0019] OP_STORE refers to a write operation, which writes data from registers to memory. OP_LOAD refers to a read operation, which reads data from memory into registers. OP_PUSH refers to pushing data onto the stack. OP_POP refers to popping data from the stack. OP_FORK is a process copy operation. A process is created at the beginning of a program. When this process reaches OP_FORK, it copies the original process, creating a new process called the child process. The original process is called the parent process. The parent and child processes coexist and execute code together. The OP_FREE operation displays the system's used and free memory, including physical memory, interactive memory, and kernel buffer memory.
[0020] Steps 1-2 include:
[0021] Step 1-2-1: Calculate the location of the returned address object using a fixed offset from the frame pointer on the heap or stack;
[0022] Step 1-2-2: If the memory object is declared as a function pointer type, such as a special pointer type pointing to a function address, then the function pointer is detected directly; if the function pointer is converted from other types, such as void* type, then flow analysis is performed to trace a set of memory objects whose type is not function pointer, but rather propagated from function pointer to function pointer.
[0023] Steps 1-2-3: Implement the identification of the Vtable pointer using C++ ABI;
[0024] Steps 1-2-4 use attribute annotations (__attribute__((annotate("sensitive")))) to locate non-control data in user-annotated text.
[0025] Steps 1-3 include the following steps:
[0026] Step 1-3-1: Shared memory is organized into a block matrix, with each column of the matrix representing a circular buffer; a single circular buffer is allocated to one of the groups of processes operating the enhancement program, and the task identifiers of the group of processes have the same hash value (i.e., tid); when an operation reports security-critical data, the program process pushes one of the groups of processes in the circular buffer into the corresponding ring;
[0027] In step 1-3-2, each group of processes in the circular buffer is signed by the program that wrote the shared memory. When the program starts, the additional monitoring code inserted by the compiler will calculate the public-private key pair together with the monitor. The public key is stored in the monitor. The program uses the private key to sign the operation of writing to the shared memory. Before executing any operation request, the monitor will first check whether the signature is valid using the public key associated with the program ID. The signature ensures that only authenticated processes can write to the circular buffer, thereby preventing malicious programs from writing to the circular buffer arbitrarily.
[0028] Step 1-3-3: Use OCRAM (which can be an i.MX6 processor) as shared memory between the Normal World and Secure World. OCRAM is statically mapped in the memory address space and can be directly accessed through the Advanced eXtensible Interface (AXI) bus.
[0029] In step 2, the monitor is an independent operating system running in a SecureWorld separated by ARM's TrustZone technology.
[0030] In step 2, isolated execution allows two different pieces of code to run completely in isolation, placing safety-critical components and other non-safety-critical software components in different domains.
[0031] In step 2, ARM's TrustZone technology is a system-wide security solution. ARM provides two execution domains: Normal World and Secure World, which isolate memory space and properly configured secure peripherals.
[0032] In step 2, the special tables are divided into two types: one is a shadow lookup table, and the other is a volume shadow stack of non-return data and return addresses;
[0033] In step 2, after the monitor receives a legitimate (i.e., original program-defined) operation on the security-critical data in the protected program, it generates or updates a shadow copy of the security-critical data in a dedicated table, specifically including:
[0034] In order to report the initialization or assignment of function pointers, vtable pointers, or security-related non-control data, an OP_STORE message containing the data address and content is written to shared memory. In response, the monitor will generate a shadow copy of the relevant data address and content in the shadow stack.
[0035] When the return address needs to be protected, the OP_PUSH message will be written to shared memory. After receiving the OP_PUSH message, the monitor will make a shadow copy of the return address on the shadow stack.
[0036] When a program uses safety-critical data, an OP_LOAD or OP_POP message is written to shared memory, notifying the monitor to perform an integrity check. Depending on the operation type, the monitor searches for non-return data in the shadow lookup table and for a return address in the shadow stack. If no shadow copy of the safety-critical data is found, or if the safety-critical data does not match the runtime value reported by the program, a conflict is detected.
[0037] When the OP_FORK message is written to shared memory, the monitor clones all volume shadow copies associated with the parent process to the child process, so that safety-critical data in the branch process is still protected.
[0038] To prevent use-after-free attacks, when an OP_FREE message is issued, the monitor will remove all relevant shadow copies from the shadow lookup table or shadow stack.
[0039] This invention proposes a kernel data integrity protection method based on TrustZone. This method monitors the independent operating system running in a secure world, protecting the integrity of the operating system kernel. Evaluation results show that the method is correct, effective, and efficient.
[0040] The present invention has the following beneficial effects:
[0041] 1) Provides a monitor that runs independently of the operating system, protecting the operating system kernel (including applications) from memory corruption attacks with less overhead and higher reliability through out-of-band operation;
[0042] 2) It extends the shadow stack concept originally proposed by CFI, protecting not only the return address but also other security-critical data, such as function pointers, vtable pointers, and sensitive non-control data in user comments.
[0043] 3) It provides a fast communication mechanism between the Normal World and the Secure World, thus enabling efficient integrity checks without context switching; Attached Figure Description
[0044] Figure 1 This is a system architecture overview diagram.
[0045] Figure 2 A lookup table diagram for managing multiple circular buffers and monitors in shared memory.
[0046] Figure 3 A flowchart illustrating the workflow of the shaded lookup table. Detailed Implementation
[0047] This invention provides a kernel data integrity protection method based on TrustZone, comprising:
[0048] Step 1: Input the source code of the kernel (and the application to be protected) into the compiler. The compiler performs static analysis to identify all security-critical data that needs to be protected and inserts the necessary monitoring code into the program to report operations related to the target to be protected to a monitor running on an independent operating system.
[0049] Step 2: After receiving a legitimate (i.e., original program-defined) operation on security-critical data in a protected program, the monitor generates or updates a volume shadow copy of the security-critical data in a dedicated table. Later, when using this security-critical data, the monitor checks the integrity of the critical data by comparing its runtime value with the volume shadow copy. If a mismatch is detected, it indicates that the security-critical data in the protected program has been illegally modified. In response, the monitor terminates the corresponding program and reports the violation to the user via the proc filesystem.
[0050] In step 1, the target to be protected includes:
[0051] Return address;
[0052] Function pointers;
[0053] Vtables pointers;
[0054] User-annotated non-control data.
[0055] Step 1 includes the following steps:
[0056] Step 1-1: The compiler locates the target, determines where to insert code in the protected application or kernel, and reports the target memory data.
[0057] Steps 1-2: The compiler performs code instrumentation to obtain an enhanced program with security code inserted.
[0058] Steps 1-3 enhance the process of transferring security-critical data operations from NormalWorld to the Secure World monitor via high-speed shared memory OCRAM.
[0059] Steps 1-4 involve the protected program reporting five types of operations to the monitor: OP_STORE, OP_LOAD, OP_PUSH, OP_POP, OP_FORK, and OP_FREE, to monitor the lifecycle of safety-critical data. OP_STORE refers to a write operation, writing data from registers to memory. OP_LOAD refers to a read operation, reading data from memory into registers. OP_PUSH refers to pushing data onto the stack. OP_POP refers to popping data from the stack. OP_FORK is a process copy operation. A process is created at the beginning of the program. When this process reaches OP_FORK, it copies the original process, creating a new process called the child process. The original process is called the parent process. The parent and child processes coexist and execute code together. The OP_FREE operation displays the system's used and free memory, including physical memory, interactive memory, and kernel buffer memory.
[0060] Steps 1-2 include:
[0061] Step 1-2-1: Calculate the location of the returned address object using a fixed offset from the frame pointer on the heap or stack;
[0062] Step 1-2-2: If the memory object is declared as a function pointer type, such as a special pointer type pointing to a function address, then the function pointer is detected directly; if the function pointer is converted from other types, such as void* type, then flow analysis is performed to trace a set of memory objects whose type is not function pointer, but rather propagated from function pointer to function pointer.
[0063] Steps 1-2-3: The identifier of the Vtable pointer is implemented through the C++ ABI;
[0064] Steps 1-2-4 use attribute annotations (__attribute__((annotate("sensitive")))) to locate non-control data in user-annotated text.
[0065] Steps 1-3 include the following steps:
[0066] Step 1-3-1: The shared memory is organized into a block matrix, with each column of the matrix representing a circular buffer; a single circular buffer is allocated to one of the groups of processes operating the enhancement program, whose task identifiers have the same hash value (i.e., tid); when an operation reports security-critical data, the program process pushes one of the groups of processes in one of the circular buffers into the corresponding ring;
[0067] In step 1-3-2, each group of processes in the circular buffer is signed by the program that wrote the shared memory. When the program starts, the additional monitoring code inserted by the compiler will calculate the public-private key pair together with the monitor. The public key is stored in the monitor. The program uses the private key to sign the operation of writing to the shared memory. Before executing any operation request, the monitor will first check whether the signature is valid using the public key associated with the program ID. The signature ensures that only authenticated processes can write to the circular buffer, thereby preventing malicious programs from writing to the circular buffer arbitrarily.
[0068] Step 1-3-3 uses OCRAM as shared memory between the Normal World and the Secure World. OCRAM is statically mapped in the memory address space and can be directly accessed through the Advanced eXtensible Interface (AXI) bus.
[0069] In step 2, the monitor is isolated and executed within the Secure World defined by ARM's TrustZone technology.
[0070] In step 2, isolated execution allows two different pieces of code to run completely in isolation, placing safety-critical components and other non-safety-critical software components in different domains.
[0071] In step 2, ARM's TrustZone technology is a system-wide security solution. ARM provides two execution domains: Normal World and Secure World, which isolate memory space and properly configured secure peripherals.
[0072] In step 2, generating or updating shadow copies of key data in the dedicated table specifically includes: the dedicated tables managed by the monitor are divided into two types: one is a shadow lookup table, and the other is a shadow stack of non-return data and return addresses.
[0073] In step 2, after the monitor receives a legitimate (i.e., original program-defined) operation on security-critical data in the protected program, it generates or updates a shadow copy of the critical data in a dedicated table, specifically including:
[0074] In order to report the initialization or assignment of function pointers, vtable pointers, or security-related non-control data, an OP_STORE message containing the data address and content is written to shared memory. In response, the monitor will generate a shadow copy of the relevant data address and content in the shadow stack.
[0075] When the return address needs to be protected, the OP_PUSH message will be written to shared memory. After receiving the OP_PUSH message, the monitor will make a shadow copy of the return address on the shadow stack.
[0076] When a program uses safety-critical data, an OP_LOAD or OP_POP message is written to shared memory, notifying the monitor to perform an integrity check. Depending on the operation type, the monitor searches for non-return data in the shadow lookup table and for a return address in the shadow stack. If no shadow copy of the safety-critical data is found, or if the safety-critical data does not match the runtime value reported by the program, a conflict is detected.
[0077] When the OP_FORK message is written to shared memory, the monitor clones all volume shadow copies associated with the parent process to the child process, so that safety-critical data in the branch process is still protected.
[0078] To prevent use-after-free attacks, when an OP_FREE message is issued, the monitor will remove all relevant shadow copies from the shadow lookup table or shadow stack.
[0079] Example
[0080] 1. System Scenario
[0081] Figure 1 This is a system architecture overview diagram, mainly composed of a compiler and a monitor. The ARM TrustZone provides two execution domains: the Normal World and the Secure World. It isolates the memory space and properly configured secure peripherals. The monitor runs in the Secure World. Communication between the two execution domains uses shared memory composed of OCRAM, which is statically mapped in the memory address space and can be directly accessed through the Advanced eXtensible Interface (AXI) bus. The functions of each component are as follows:
[0082] Compiler: The compiler performs static analysis to identify all security-critical data that needs protection and inserts necessary monitoring code into the program to report operations related to the protected target to a monitor running on a separate operating system.
[0083] Monitor: Upon receiving a legitimate (i.e., program-defined) operation on security-critical data within a protected program, the monitor generates or updates a volume shadow copy of the security-critical data in a dedicated table. Later, when this security-critical data is used, the monitor checks its integrity by comparing its runtime value with the volume shadow copy. If a mismatch is detected, it indicates that the security-critical data in the protected program has been illegally modified. In response, the monitor terminates the corresponding program and reports the violation to the user via the proc filesystem.
[0084] Shared memory: Communication between the two worlds relies on shared memory. Enhanced operations on security-critical data in the program are passed from the Normal World to the monitor in the Secure World via high-speed shared memory OCRAM, so that the monitor can generate or update shadow copies of the security-critical data in a dedicated table.
[0085] Figure 2 It is a lookup table graph managed by multiple circular buffers and monitors in shared memory. Its specific functions when writing operations on safety-critical data into shared memory are as follows:
[0086] A single circular buffer is assigned to a group of processes with the same task identifier hash (i.e., tid). When an operation reporting security-critical data is needed, the program process pushes a group of processes from one of the circular buffers into the corresponding ring. This design allows the monitor to allow multiple processes running on different CPU cores to write to different circular buffers simultaneously. Each group of processes in the circular buffer is signed by the program writing the shared memory. For example, additional monitoring code inserted by the compiler at program startup calculates a public-private key pair with the monitor. The public key is stored in the monitor, and the program uses the private key to sign messages written to shared memory. Before executing any operation request, the monitor first checks the signature for validity using the public key associated with the task ID. The signing ensures that only verified processes can write to the circular buffer, thus preventing malicious programs from writing to arbitrary circular buffers.
[0087] The monitor management has two types of dedicated tables: one is the shadow lookup table, and the other is the shadow stack for non-return data and return addresses;
[0088] 2. Monitor Shadow Lookup Table Process
[0089] like Figure 3As shown, non-return target data is stored in a shadow lookup table, and hash buckets store the task ID, the memory location of the security-critical data (called the data address), the data value, and a timestamp. When an operation on security-critical data in the enhancement program writes to shared memory, the monitor first verifies the message signature to determine if the write operation is authenticated. After authentication, the monitor calculates a hash key based on the task ID and data address embedded in the message. After calculating the key, the monitor operates on the corresponding hash bucket according to the message type. For example, if the type is OP_STORE, the monitor will create a new bucket to perform a volume shadow copy of the security-critical data or update the data value of an existing bucket in the table if no match is found. If the message type is OP_LOAD, the monitor will compare the runtime value of the security-critical data with the stored volume shadow copy. If there is no match or no bucket is found, the monitor will issue an integrity conflict.
[0090] In its specific implementation, this application provides a computer storage medium and a corresponding data processing unit. The computer storage medium is capable of storing a computer program, which, when executed by the data processing unit, can run the content of the TrustZone-based kernel data integrity protection method provided by this invention, as well as some or all of the steps in various embodiments. The storage medium can be a magnetic disk, optical disk, read-only memory (ROM), or random access memory (RAM), etc.
[0091] Those skilled in the art will clearly understand that the technical solutions in the embodiments of the present invention can be implemented using computer programs and their corresponding general-purpose hardware platforms. Based on this understanding, the technical solutions in the embodiments of the present invention, or the parts that contribute to the prior art, can be embodied in the form of computer programs, i.e., software products. These computer program software products can be stored in a storage medium and include several instructions to cause a device containing a data processing unit (which may be a personal computer, server, microcontroller, MUU, or network device, etc.) to execute the methods described in various embodiments or certain parts of the embodiments of the present invention.
[0092] This invention provides a kernel data integrity protection method based on TrustZone. Many methods and approaches exist for implementing this technical solution; the above description is merely a preferred embodiment. It should be noted that those skilled in the art can make various improvements and modifications without departing from the principles of this invention, and these improvements and modifications should also be considered within the scope of protection of this invention. All components not explicitly stated in this embodiment can be implemented using existing technologies.
Claims
1. A kernel data integrity protection method based on TrustZone, characterized in that, Includes the following steps: Step 1: Input the source code of the kernel and the application to be protected into the compiler. The compiler performs static analysis to identify all security-critical data that needs to be protected and inserts the necessary monitoring code into the program to report operations related to the target to be protected to a monitor running on an independent operating system. Step 2: After the monitor receives a legitimate operation on security-critical data in the protected program, it generates or updates a shadow copy of the critical data in a dedicated table. When the security-critical data is used, the monitor will check the integrity of the critical data by comparing the runtime value and the volume shadow copy. If a mismatch is detected, it means that the security-critical data in the protected program has been illegally modified. In response, the monitor will terminate the corresponding program and report the violation to the user through the proc file system. In step 1, the safety-critical data includes: Return address; Function pointers; Vtable pointer; User-commented non-control data; Step 1 includes the following steps: Step 1-1: The compiler locates the target, determines the location where code should be inserted into the application or kernel to be protected, and reports the target memory data. Steps 1-2: The compiler performs code instrumentation to obtain an enhanced program with security code inserted. Steps 1-3 enhance the operation of security-critical data in the program, transferring it from NormalWorld to the monitor in SecureWorld via high-speed shared memory OCRAM; Steps 1-4: The protected program reports six types of operations to the monitor, including OP_STORE, OP_LOAD, OP_PUSH, OP_POP, OP_FORK, and OP_FREE, to monitor the lifecycle of security-critical data.
2. The method according to claim 1, characterized in that, Steps 1-2 include: Step 1-2-1: Calculate the location of the returned address object using a fixed offset from the frame pointer on the heap or stack; Step 1-2-2: If the memory object is declared as a function pointer type, the function pointer is detected directly; if the function pointer is converted from another type, flow analysis is performed to trace a set of memory objects whose type is not function pointer, but rather propagated from function pointer to function pointer. Steps 1-2-3: Implement the identification of the Vtable pointer using the C++ ABI; Steps 1-2-4 use attribute annotations (__attribute__((annotate("sensitive")))) to locate non-control data in user-annotated text.
3. The method according to claim 2, characterized in that, Steps 1-3 include the following steps: Step 1-3-1: Shared memory is organized into a block matrix, with each column of the matrix representing a circular buffer; a single circular buffer is allocated to one of the groups of processes operating the enhancement program, and the task identifiers of the group of processes have the same hash value; when an operation reports security-critical data, the program process pushes one of the groups of processes in one of the circular buffers into the corresponding ring; In step 1-3-2, each group of processes in the circular buffer is signed by the program that wrote the shared memory. When the program starts, the additional monitoring code inserted by the compiler will calculate the public-private key pair together with the monitor. The public key is stored in the monitor. The program uses the private key to sign the operation of writing to the shared memory. Before executing any operation request, the monitor will first check whether the signature is valid using the public key associated with the program ID. The signature ensures that only authenticated processes can write to the circular buffer, thereby preventing malicious programs from writing to the circular buffer arbitrarily. Step 1-3-3: Use OCRAM as shared memory between the Normal World and the Secure World. OCRAM is statically mapped in the memory address space and can be directly accessed through the AXI bus.
4. The method according to claim 3, characterized in that, In step 2, the monitor is an independent operating system running in a Secure World separated by ARM's TrustZone technology.
5. The method according to claim 4, characterized in that, In step 2, isolated execution allows two different pieces of code to run completely in isolation, placing safety-critical components and other non-safety-critical software components in different domains.
6. The method according to claim 5, characterized in that, In step 2, ARM provides two execution domains: NormalWorld and Secure World, which isolate the kernel space from properly configured secure peripherals.
7. The method according to claim 6, characterized in that, In step 2, the special tables are divided into two types: one is a shadow lookup table, and the other is a volume shadow stack that returns non-data and return addresses.
8. The method according to claim 7, characterized in that, In step 2, after the monitor receives a legitimate operation on security-critical data in the protected program, it generates or updates a shadow copy of the security-critical data in a dedicated table, specifically including: To report the initialization or assignment of function pointers, vtable pointers, or security-related non-control data, an OP_STORE message containing the data address and content is written to shared memory; in response, the monitor generates a shadow copy of the relevant data address and content in the shadow stack. When the return address needs to be protected, the OP_PUSH message will be written to shared memory. After receiving the OP_PUSH message, the monitor will make a shadow copy of the return address on the shadow stack. When a program uses safety-critical data, an OP_LOAD or OP_POP message is written to shared memory, notifying the monitor to perform an integrity check. Depending on the operation type, the monitor searches for non-return data in the shadow lookup table and for a return address in the shadow stack. If no shadow copy of the safety-critical data is found, or if the safety-critical data does not match the runtime value reported by the program, a conflict is detected. When the OP_FORK message is written to shared memory, the monitor clones all volume shadow copies associated with the parent process to the child process, so that safety-critical data in the branch process is still protected. To prevent use-after-free attacks, when an OP_FREE message is issued, the monitor will remove all relevant shadow copies from the shadow lookup table or shadow stack.