A kernel stack protection method and system

Abstract

The application provides a kernel stack protection method and system, the method comprising: monitoring an event function in a kernel in a rich execution environment, intercepting the event function related to kernel stack operation, and setting a hook point; receiving an SMC instruction triggered by the event function, judging whether the SMC instruction is an SMC instruction in a preset range requiring kernel stack operation based on a call number contained in the SMC instruction in a monitor mode in a trusted execution environment, returning the hook point to cancel the interception of the event function if not, and performing a legality checking step on the kernel stack operation of the intercepted event function if yes; the legality checking step: checking the legality of the kernel stack operation corresponding to the intercepted event function, the secure memory being allocated in a trusted execution environment in a Linux kernel initialization stage; locking the system when the checked kernel stack operation is illegal, and returning the hook point to cancel the interception of the event function when the checked kernel stack operation is legal. The application can safely and effectively protect the kernel stack.

Description

Technical Field

[0001] This invention relates to the field of operating system kernel security technology, and in particular to a kernel stack protection method and system. Background Technology

[0002] With the rapid development of smart mobile terminal technology, smartphones and other smart mobile terminals have become indispensable devices in people's daily lives and work. However, a wide variety of applications run on smart mobile terminals, involving the privacy and important data of device owners in various aspects such as daily work, life, and finances, making the security issues brought about by smart mobile terminals increasingly prominent. The kernel of the Android operating system of mobile phones is the Linux system (i.e., the Linux kernel). In the Linux system, when a program executes a system call, it uses the kernel stack. The kernel stack contains critical control flow data and non-control flow data. If control flow data, such as function pointers and return addresses, is modified by exploiting kernel vulnerabilities, the control flow will be changed. Attackers can use the control flow to execute privilege escalation code in the kernel, further obtaining root privileges and compromising the Linux kernel. Among these attacks, the kernel stack is most vulnerable to stack overflow attacks. The stack stores the parameters of the called function, the return address after the function is executed, and the local variables of the called function. If a string overflow vulnerability is maliciously exploited, the function return address can be modified to the address of malicious code to achieve an attack.

[0003] Existing kernel stack protection schemes can be divided into two main categories based on the location of the protection tools: kernel stack protection schemes located within the Linux kernel and hypervisor-based kernel stack protection schemes. Kernel stack protection schemes located within the Linux kernel place the protection tools in the same address space and privilege level as the Linux kernel. However, attacks targeting the Linux kernel can also attack these protection tools, making this method insecure. Hypervisor-based kernel stack protection schemes place the protection tools in a hypervisor with a higher privilege level than the Linux kernel. This hypervisor monitors critical events in the Linux kernel stack and, when necessary, uses the hypervisor to set kernel stack memory regions to read-only to prevent modification of kernel stack data. This provides higher security than the first method, but its security depends entirely on the hypervisor, which performs many system administration and resource allocation tasks, making it vulnerable to vulnerabilities. Therefore, this method also has its problems.

[0004] Therefore, how to provide a kernel stack protection method with better security performance is a technical problem that urgently needs to be solved. Summary of the Invention

[0005] In view of this, embodiments of the present invention provide a kernel stack protection method and system to eliminate or improve one or more defects existing in the prior art.

[0006] One aspect of the present invention provides a kernel stack protection method, the method comprising the following steps:

[0007] Monitor event functions in the kernel under rich execution environment, intercept event functions related to kernel stack operations, and set hook points in the intercepted event functions related to kernel stack operations;

[0008] Receive SMC instructions triggered by event functions related to the kernel stack. In the monitor mode of the trusted execution environment, determine whether the SMC instruction is an SMC instruction within the preset range that needs to perform kernel stack operations based on the call number contained in the SMC instruction. If the SMC instruction is not within the preset range that needs to perform kernel stack operations, return to the hook point to cancel the interception of the event function. If the SMC instruction is within the preset range that needs to perform kernel stack operations, perform a legality check step on the kernel stack operations of the intercepted event function.

[0009] The legality check steps are as follows: Based on the thread identifier corresponding to the kernel stack operation of the intercepted event function and the requested kernel stack base address, and the thread identifier and the kernel stack base address corresponding to the thread identifier stored in the safe memory, the legality of the kernel stack operation corresponding to the intercepted event function is checked. The safe memory is allocated in the trusted execution environment during the Linux kernel initialization phase.

[0010] If the kernel stack operation corresponding to the intercepted event function is found to be invalid, the system will be locked; if the kernel stack operation corresponding to the intercepted event function is found to be valid, the hook point will be returned and the interception of the event function will be canceled.

[0011] In some embodiments of the present invention, SMC instructions that do not need to perform kernel stack operations within a preset range correspond to non-scheduled threads. The method further includes: during kernel operation, setting the read / write permissions of the kernel stack region corresponding to the non-scheduled thread in the secure memory to read-only in the Linux kernel under the rich execution environment, and readable and writable in the monitor mode of the trusted execution environment; after the step of canceling the interception of the event function by returning the hook point when the kernel stack operation corresponding to the detected intercepted event function is legal, the method further includes: executing the kernel stack operation corresponding to the intercepted event function in the monitor mode of the trusted execution environment, and switching back from the trusted execution environment to the rich execution environment after completion.

[0012] In some embodiments of the present invention, the step of setting the read / write permissions of the kernel stack corresponding to the non-scheduled thread in the secure memory region during kernel operation to be read-only in the Linux kernel under rich execution environment and readable and writable in the monitor mode under trusted execution environment is implemented by the kernel stack controller.

[0013] In some embodiments of the present invention, the kernel stack operation performed within the preset range includes kernel stack creation, kernel stack switching, and kernel stack writing; the legality check step includes: when the kernel stack operation of the intercepted event function is kernel stack creation, obtaining the thread identifier corresponding to kernel stack creation and the requested kernel stack base address, checking whether the created kernel stack base address conflicts with the kernel stack base address already stored in the secure memory; if a conflict occurs, the kernel stack creation is deemed invalid; if no conflict occurs, the kernel stack creation is deemed valid; when the kernel stack operation of the intercepted event function is kernel stack switching, obtaining the kernel stack base address... The stack switching process involves obtaining the corresponding thread identifier and the requested kernel stack base address. It checks whether the switched kernel stack base address is the same as the kernel stack base address already stored in the secure memory. If they are different, the kernel stack creation is deemed invalid; if they are the same, the kernel stack creation is deemed valid. When the kernel stack operation of the intercepted event function is a kernel stack write, the process obtains the thread identifier and the requested kernel stack base address corresponding to the kernel stack write. It checks whether the written kernel stack base address is the same as the kernel stack base address of the writing thread stored in the secure memory. If they are different, the kernel stack write is deemed invalid; if they are the same, the kernel stack write is deemed valid.

[0014] In some embodiments of the present invention, SMC instructions that need to perform kernel stack operations within a preset range correspond to scheduling threads. The method further includes: the kernel stack corresponding to the kernel stack operations that need to be performed within the preset range is set to writable or executable permissions in the secure memory, and simultaneous kernel stack writing and kernel stack execution are not allowed on the kernel stack of any thread.

[0015] In some embodiments of the present invention, when the kernel stack operation of the intercepted event function is a kernel stack write in the legality check step, the method further includes: checking the legality of the kernel stack write in combination with forward control flow integrity protection and / or backward control flow integrity protection.

[0016] In some embodiments of the present invention, after the step of returning to the hook point to cancel the interception of the event function if the SMC instruction is not within the preset range of kernel stack operations to be performed, the method further includes: returning to the hook point and performing the kernel stack operation corresponding to the SMC instruction in the monitor mode of the trusted execution environment based on the SMC instruction; after the kernel stack operation is completed, switching the trusted execution environment to the rich execution environment; the kernel stack operation not within the preset range to be performed includes kernel stack release.

[0017] In some embodiments of the present invention, the method further includes: unlocking the system from a locked state based on a preset key.

[0018] Another aspect of the present invention provides a kernel stack protection system, the system comprising:

[0019] Safe memory is used to allocate safe memory in a trusted execution environment during the Linux kernel initialization phase. The safe memory is used to store thread identifiers and the kernel stack base address corresponding to the thread identifiers.

[0020] The kernel stack operation interception module is used to monitor event functions in the kernel in a rich execution environment, intercept event functions related to kernel stack operations, and set hook points in the intercepted event functions related to kernel stack operations.

[0021] The instruction processing module is used to receive SMC instructions triggered by event functions related to the kernel stack. In the monitor mode of the trusted execution environment, it determines whether the SMC instruction is an SMC instruction that needs to perform kernel stack operations within a preset range based on the call number contained in the SMC instruction. If the SMC instruction is not an SMC instruction that needs to perform kernel stack operations within the preset range, it returns to the hook point to cancel the interception of the event function. If the SMC instruction is an SMC instruction that needs to perform kernel stack operations within the preset range, it performs a legality check step on the kernel stack operations of the intercepted event function.

[0022] The legality check module is used to check the legality of the kernel stack operation corresponding to the intercepted event function based on the thread identifier and the requested kernel stack base address corresponding to the kernel stack operation of the intercepted event function and the thread identifier and kernel stack base address stored in the secure memory.

[0023] The exception handling module is used to lock the system when the kernel stack operation corresponding to the intercepted event function is found to be invalid, and to return to the hook point and cancel the interception of the event function when the kernel stack operation corresponding to the intercepted event function is found to be valid.

[0024] In some embodiments of the present invention, the system further includes: a kernel stack protection module, used to set the read and write permissions of the kernel stack corresponding to the non-scheduled thread in the secure memory region to read-only in the Linux kernel under rich execution environment, and readable and writable in the monitor mode under trusted execution environment during kernel operation.

[0025] The kernel stack protection method and system provided by this invention can monitor and intercept kernel stack-related event functions. In a monitor mode within a trusted execution environment, a subset of kernel stack-related event functions are filtered. Based on thread identifiers and kernel stack base addresses stored in pre-allocated secure memory, the legality of the filtered kernel stack-related event functions is verified. For legal kernel stack operations, interception is canceled and execution is performed; for illegal kernel stack operations, the system is locked. Compared to existing technologies, this invention uses a monitor mode within a trusted execution environment to avoid being in the same address space and privilege level as the Linux kernel, while also avoiding dependence on a hypervisor, thereby improving the security protection performance of the operating system kernel stack.

[0026] Additional advantages, objects, and features of the invention will be set forth in part in the description which follows, and will also become apparent in part to those skilled in the art upon studying the description, or may be learned by practice of the invention. The objects and other advantages of the invention can be realized and obtained by means of the structures specifically pointed out in the specification and drawings.

[0027] Those skilled in the art will understand that the objectives and advantages achievable with the present invention are not limited to those specifically described above, and that the above and other objectives achievable with the present invention will become clearer from the following detailed description. Attached Figure Description

[0028] The accompanying drawings, which are included to provide a further understanding of the invention and form part of this application, are not intended to limit the scope of the invention. In the drawings:

[0029] Figure 1 This is a flowchart of a kernel stack protection method in one embodiment of the present invention.

[0030] Figure 2 This is an ARM architecture diagram that includes a kernel stack protection system according to an embodiment of the present invention.

[0031] Figure 3A This is an architecture diagram of a kernel stack protection system in one embodiment of the present invention.

[0032] Figure 3B This is an architecture diagram of a kernel stack protection system in another embodiment of the present invention.

[0033] Figure 4 This is a flowchart of the kernel stack initialization process in one embodiment of the present invention.

[0034] Figure 5 This is a flowchart of kernel stack release in one embodiment of the present invention.

[0035] Figure 6 This is a flowchart illustrating the kernel stack creation process in one embodiment of the present invention.

[0036] Figure 7 This is a flowchart of kernel stack switching in one embodiment of the present invention. Detailed Implementation

[0037] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the embodiments and accompanying drawings. Here, the illustrative embodiments and descriptions of this invention are used to explain the invention, but are not intended to limit the invention.

[0038] It should also be noted that, in order to avoid obscuring the invention with unnecessary details, only the structures and / or processing steps closely related to the solution according to the invention are shown in the accompanying drawings, while other details that are not closely related to the invention are omitted.

[0039] It should be emphasized that the term "including / comprises" as used herein refers to the presence of a feature, element, step, or component, but does not exclude the presence or addition of one or more other features, elements, steps, or components.

[0040] It should also be noted that, unless otherwise specified, the term "connection" in this article can refer not only to a direct connection, but also to an indirect connection involving an intermediary.

[0041] In the following description, embodiments of the invention will be illustrated with reference to the accompanying drawings. In the drawings, the same reference numerals represent the same or similar parts, or the same or similar steps.

[0042] In the Arm architecture, instruction execution permissions have four exception levels: (1) EL0, running user-level applications; (2) EL1, running the operating system kernel and related functions; (3) EL2, running the Hypervisor, the virtualization management program; and (4) EL3, running secure firmware, Secure Monitor. The switching between the Rich Execution Environment (REE) and the Trusted Execution Environment (TEE) is completed in EL3. The exception level determines the corresponding permission level; from EL0 to EL3, the higher the exception level, the higher the permission level.

[0043] Arm incorporated a hardware virtualization technology called TrustZone into its chips. This technology divides the CPU's operating state into two states: Normal World and Secure World. In Normal World, no component or application can access secure hardware resources or data, nor can they access caches, memory, or other peripheral secure hardware resources or data belonging to the Secure World state. Switching between Normal World and Secure World states is achieved using the SMC (Secure Monitor Call) instruction. When an SMC instruction is invoked, the system enters Monitor Mode. The secure monitor, acting as the highest-level execution authority running secure firmware, operates within a trusted execution environment and processes the call number (ID) contained in the SMC instruction differently. The Rich Execution Environment (REE) is also known as the Normal World, and the Trusted Execution Environment (TEE) is also known as the Secure World. Furthermore, while the Linux kernel runs in the normal world, some high-security behaviors, such as fingerprint comparison and private key signing during payments, need to be executed in the secure world. The relationship between ARM architecture and Linux systems: ARM is the mobile processor architecture, Android is the mobile operating system, and Linux is the kernel of the Android operating system. The Linux kernel uses the kernel stack, and iterations of the ARM architecture do not affect the fact that the secure monitor always ranks higher than the hypervisor. Trusted Execution Environment (TEE), as a chip enhancement technology, is widely deployed in smart mobile terminals to provide effective security for the various applications and data running and used within it, preventing them from being accessed by other programs from the outside at the software or hardware level, thus ensuring the confidentiality and security of code and data within the TEE.

[0044] This invention provides a kernel stack protection method based on a security monitor in the monitor mode of the trusted execution environment in the Arm architecture. The tool for protecting the kernel stack (kernel stack protection system) is placed in the monitor mode of instruction execution EL3 privilege in the Arm architecture. The security monitor is used to protect sensitive data that needs protection, avoid kernel stack overflow and other anomalies, protect the kernel stack of the operating system, and provide the highest level of security guarantee for the operating system.

[0045] Figure 1 This is a flowchart of a kernel stack protection method according to an embodiment of the present invention. The method includes the following steps:

[0046] Step S110: Monitor event functions in the kernel under rich execution environment, intercept event functions related to kernel stack operations, and set hook points in the intercepted event functions related to kernel stack operations.

[0047] The kernel stack event functions include kernel stack creation, release, switching, and initialization. Hook points are used to record the location where intercepted event functions stop. Kernel stack creation, switching, and writing occur on the scheduled thread's kernel stack, while kernel stack release occurs on the non-scheduled thread's kernel stack. A validity check is performed on the scheduled thread's kernel stack. The above event functions are merely examples, and this invention is not limited to them.

[0048] Step S120: Receive the SMC instruction triggered by the event function related to the kernel stack. In the monitor mode of the trusted execution environment, determine whether the SMC instruction is within the preset range of SMC instructions that need to perform kernel stack operations based on the call number contained in the SMC instruction. If the SMC instruction is not within the preset range of SMC instructions that need to perform kernel stack operations, return to the hook point to cancel the interception of the event function. If the SMC instruction is within the preset range of SMC instructions that need to perform kernel stack operations, perform a legality check step on the kernel stack operation of the intercepted event function.

[0049] The SMC instructions requiring kernel stack operations within the preset range refer to the fact that some SMC instructions do not require legality checks for their corresponding kernel stack operations, while others do. This invention predefines a range of SMC instructions requiring legality checks, distinguished based on the SMC instruction's call number (ID). Specifically, the kernel stack operations (corresponding to the scheduled thread) requiring execution within the preset range in step S120 include, but are not limited to, kernel stack creation, kernel stack switching, and kernel stack writing. Kernel stack operations (corresponding to non-scheduled threads) not requiring execution within the preset range include, but are not limited to, kernel stack initialization and kernel stack release.

[0050] After step S120, where the SMC instruction is not within the preset range requiring kernel stack operations, and the interception of the event function is cancelled by returning to the hook point, the method further includes: returning to the hook point and executing the kernel stack operation corresponding to the SMC instruction in the monitor mode of the trusted execution environment based on the SMC instruction; and switching the trusted execution environment to a rich execution environment after the kernel stack operation is completed. Here, kernel stack operations not within the preset range include kernel stack release. When the kernel stack operation of the intercepted event function is kernel stack release, the hook point is returned, and the corresponding thread identifier and kernel stack base address are deleted in the monitor mode of the trusted execution environment based on the SMC instruction; the trusted execution environment is then switched to a rich execution environment.

[0051] Step S130: Legality check step: Based on the thread identifier corresponding to the kernel stack operation of the intercepted event function and the requested kernel stack base address, and the thread identifier and the kernel stack base address corresponding to the thread identifier stored in safe memory, check the legality of the kernel stack operation corresponding to the intercepted event function. The safe memory is allocated in a trusted execution environment during the Linux kernel initialization phase.

[0052] In this invention, the relationship between threads and the kernel stack is that threads possess their own kernel stacks, and therefore each kernel stack has a corresponding thread identifier. During the Linux kernel initialization phase, this invention allocates secure memory in a trusted execution environment. This secure memory stores thread identifiers and the corresponding kernel stack base addresses. By comparing the thread identifiers and their corresponding kernel stack base addresses stored in secure memory with the thread identifiers and kernel stack base addresses corresponding to the kernel stack operations of the intercepted event function, the legality of the intercepted event function's kernel stack operations is determined, i.e., whether the intercepted event function will put the kernel stack at risk. Furthermore, in the Linux kernel, processes and threads are no longer distinguished and are unified in `task_struct`. A thread is merely considered a process that shares certain resources with other processes, and whether or not they share address space is almost the only difference between a process and what is called a thread in Linux. Therefore, the thread identifier in this invention can also be understood as a process identifier.

[0053] Optionally, the kernel stacks corresponding to the kernel stack operations required within the preset range in step S130 are set to writable or executable permissions in secure memory, and simultaneous kernel stack write and kernel stack execution are not allowed on the kernel stack of any thread. Threads can only modify their own kernel stacks. The read / write permissions of the kernel stack memory area of ​​non-scheduled threads are set to Linux kernel read-only to prevent the kernel stack data of non-scheduled threads from being tampered with. The kernel stack of scheduled threads adopts the W⊕X protection mechanism, and the kernel stack memory is marked as writable or executable, but cannot exist simultaneously. This way, even if an attacker injects code into the writable memory, it cannot be executed. Here, non-scheduled threads are those whose kernel stack operations are not required within the preset range in S130, such as kernel stack release; scheduled threads are those whose kernel stack operations are required within the preset range in step S130, such as kernel stack creation and kernel stack switching.

[0054] The legality verification step S130 can effectively prevent attacks such as modification and reuse of the kernel stack base address.

[0055] Step S140: If the kernel stack operation corresponding to the intercepted event function is invalid, the system will be locked; if the kernel stack operation corresponding to the intercepted event function is valid, the hook point will be returned to cancel the interception of the event function.

[0056] After step S140, the present invention further includes the following steps: performing kernel stack operations corresponding to the intercepted event function in monitor mode of trusted execution environment, and switching back from trusted execution environment to rich execution environment after completion.

[0057] In one embodiment of the present invention, during kernel execution, the method further includes: setting the read / write permissions of the kernel stack corresponding to the non-scheduled thread in the secure memory region to read-only in the Linux kernel under a rich execution environment, and readable and writable in the monitor mode under a trusted execution environment. This step is implemented through a kernel stack controller, the model of which includes, but is not limited to, the TZC-400 controller. This kernel stack controller model is merely an example, and the present invention is not limited thereto.

[0058] Figure 4 This is a flowchart of kernel stack initialization in one embodiment of the present invention. Kernel stack initialization is performed on a non-scheduled thread, eliminating the need for the legality check step S130. The kernel stack initialization process is as follows: First, in a rich execution environment, the kernel is initialized, and the instruction processing module is called to process SMC instructions, entering a trusted execution environment. In the trusted execution environment, the corresponding operation is performed according to the SMC instruction call number (ID), and then the thread identifier and corresponding kernel stack stored in secure memory are initialized. The process then returns to the rich execution environment to continue executing other tasks.

[0059] Figure 5 This is a flowchart of kernel stack release in one embodiment of the present invention. Kernel stack release is a non-scheduled thread, so the legality check step S130 is not required. The kernel stack initialization process is as follows: First, in the rich execution environment, the thread exits, the kernel stack is released, and the SMC instruction is triggered to jump to the trusted execution environment; then, according to the call number (ID) of the SMC instruction, the operation is performed to delete the thread identifier and the corresponding kernel stack base address in safe memory, and return to the rich execution environment to continue executing other tasks.

[0060] In one embodiment of the present invention, the kernel stack operations performed within the preset range, i.e., instructions that need to be executed in the monitor mode of the trusted execution environment, include kernel stack creation, kernel stack switching, and kernel stack writing. The validity check step in step S130 must have at least the following conditions:

[0061] (1) When the kernel stack operation of the intercepted event function is kernel stack creation, obtain the thread identifier corresponding to the kernel stack creation and the requested kernel stack base address, check whether the created kernel stack base address conflicts with the kernel stack base address already stored in safe memory. If a conflict occurs, the kernel stack creation is deemed illegal; if no conflict occurs, the kernel stack creation is deemed legal. Figure 6 This is a flowchart of kernel stack creation in one embodiment of the present invention. Releasing the kernel stack to schedule threads requires executing the legality check step S130. The kernel stack initialization process is as follows: First, in a rich execution environment, a thread is created, a kernel stack is allocated, and the SMC instruction is triggered, jumping to the trusted execution environment; then, operations are performed according to the SMC instruction's call number (ID), checking whether the kernel stack base address is valid. If invalid, the system is locked; if valid, the thread identifier and the corresponding kernel stack base address are stored, and the process returns to the rich execution environment to continue executing other tasks.

[0062] (2) When the kernel stack operation of the intercepted event function is a kernel stack switch, obtain the thread identifier corresponding to the kernel stack switch and the requested kernel stack base address, and check whether the switched kernel stack base address is the same as the kernel stack base address already stored in safe memory. If they are different, the kernel stack creation is considered illegal; if they are the same, the kernel stack creation is considered legal. In simple terms, the kernel stack switch should be performed by the same thread. Figure 7 This is a flowchart of kernel stack switching in one embodiment of the present invention. Releasing the kernel stack to a scheduled thread requires executing the legality check step S130. The kernel stack initialization process is as follows: First, in a rich execution environment, thread switching triggers the SMC instruction, jumping to the trusted execution environment; then, according to the SMC instruction's call number (ID), the operation is executed, checking whether the kernel stack base address has been modified. If so, the system is locked; otherwise, the read / write permissions of the non-scheduled process's kernel stack memory area are set to read-only, and the process returns to the rich execution environment to continue executing other tasks.

[0063] (3) When the kernel stack operation of the intercepted event function is a kernel stack write, obtain the thread identifier corresponding to the kernel stack write and the requested kernel stack base address, check whether the written kernel stack base address is the same as the kernel stack base address of the writing thread stored in the safe memory. If they are different, the kernel stack write is considered illegal; if they are the same, the kernel stack write is considered legal.

[0064] Furthermore, in the legality check step of step S130, when the kernel stack operation of the intercepted event function is a kernel stack write, the method further includes: checking the legality of the kernel stack write in combination with forward control flow integrity protection and / or backward control flow integrity protection.

[0065] In one embodiment of the present invention, the method further includes: the kernel stack corresponding to the kernel stack operation to be performed within a preset range is set to writable or executable permissions in safe memory, and simultaneous kernel stack writing and kernel stack execution are not allowed on the kernel stack of any thread at the same time.

[0066] In one embodiment of the present invention, SMC instructions that need to perform kernel stack operations within a preset range correspond to scheduling threads. The method further includes: the kernel stack corresponding to the kernel stack operations that need to be performed within the preset range is set to writable or executable permissions in the secure memory, and simultaneous kernel stack writing and kernel stack execution are not allowed on the kernel stack of any thread.

[0067] In one embodiment of the present invention, the method further includes: when the system is in a locked state, unlocking the system based on a preset key.

[0068] This invention provides a kernel stack protection scheme that can protect all data (including control flow data and non-control flow data) in the kernel stack of a thread in real time. Unlike other kernel stack protection methods, this invention stores the thread identifier and its corresponding kernel stack base address in a trusted execution environment under the Arm architecture, which is an isolated environment with EL3 privilege level. By intercepting the Linux kernel's creation, modification, and release operations on the kernel stack and transferring them to the trusted execution environment of the Arm architecture, the legality of kernel stack operations is verified. This enables the secure storage of critical data structures, and if they are legal, they are processed to achieve fine-grained monitoring of the kernel stack and prevent attacks such as modification and reuse of the kernel stack base address. At the same time, it ensures that a thread can only modify its own kernel stack. The read and write permissions of the kernel stack memory area of ​​non-scheduled threads are set to read-only by the Linux kernel to prevent the kernel stack data of non-scheduled threads from being tampered with. The kernel stack of scheduled threads adopts the W⊕X protection mechanism, and the kernel stack memory is marked as writable or executable, but cannot exist simultaneously. In this way, even if an attacker injects code into writable memory, it cannot be executed. Compared to other kernel stack protection schemes, this invention offers higher security and serves as a framework that can be combined with other forward and backward control flow integrity schemes to provide more granular protection for kernel control flow integrity. The method provided by this invention only requires support for TEE versions of the Linux operating system, demonstrating good scalability.

[0069] Figure 2 The diagram shows an ARM architecture diagram of a kernel stack protection system according to an embodiment of the present invention. The hardware virtualization Trustzone technology under the ARM architecture is divided into a rich execution environment (REE or Normal World) and a trusted execution environment (TEE or Secure World). The rich execution environment is divided into user mode and privileged mode. The trusted execution environment includes user mode, privileged mode and monitor mode. In privileged mode, the Linux kernel contains a Trustzone driver and a kernel stack operation interception module. In the monitor mode of the trusted execution environment, there are instruction processing module, kernel stack protection module, legality check module and exception handling module.

[0070] Figure 3A Figure 3A This is an architecture diagram of a kernel stack protection system in one embodiment of the present invention. According to the execution order starting from the SMC instruction trigger, the modules are kernel stack operation interception module, instruction processing module, legality check module, and exception handling module. Figure 3BThis is an architecture diagram of the kernel stack protection system in another embodiment of the present invention. According to the execution order starting from the SMC instruction trigger, the modules are kernel stack operation interception module, instruction processing module, kernel stack protection module, legality check module, and exception handling module.

[0071] Corresponding to the above method, the present invention also provides a kernel stack protection system, which includes the following modules:

[0072] (1) Secure memory, used to allocate secure memory in a trusted execution environment during the Linux kernel initialization phase. The secure memory is used to store thread identifiers and the kernel stack base address corresponding to the thread identifiers.

[0073] During kernel initialization, the `memblock_phys_alloc` and `memblock_reserve` functions reserve a sufficiently large block of memory as safe memory. The starting physical address of this memory is obtained, and in Secure World, the TZC-400 controller sets the read / write permissions of this memory to be read-only for the Linux kernel. This memory is used to store thread identifiers and kernel stack base addresses, and is then initialized. The kernel stack operation flow is shown in the figure. When a thread's kernel stack is allocated, the SMC instruction is triggered to check if the created kernel stack base address is within the kernel stack memory range stored in safe memory. The thread identifier (PID) and kernel stack base address are stored in the TEE. When a thread's kernel stack is released, the SMC instruction is triggered again, deleting the thread identifier and kernel stack base address from the TEE. When a thread switches, the kernel stack base address of the scheduled thread is checked to see if it is a stored kernel stack base address and if it is within the already stored kernel stack range to prevent kernel stack base address reuse or tampering. Simultaneously, the W⊕X mechanism is enabled to protect the kernel stack region. When the kernel stack operation fails the legality check, the exception handling module will be invoked to lock the system, preventing further damage to the system and consequences such as malicious code execution and control flow hijacking.

[0074] (2) Kernel stack operation interception module, used to monitor event functions in the kernel in rich execution environment, intercept event functions related to kernel stack operations, and set hook points in the intercepted event functions related to kernel stack operations.

[0075] This module is located in, as Figure 2 The Linux kernel shown includes kernel stack event functions such as kernel stack creation, release, and switching operations. Hook points are set in the functions where kernel stack operations occur, and the SMC instruction processing module is called when a kernel stack operation occurs. Specifically, the SMC instruction is triggered when the application calls the OP-TEE driver.

[0076] (3) The instruction processing module receives SMC instructions triggered by event functions related to the kernel stack. In monitor mode under the Trusted Execution Environment (TEE or Secure World), it determines whether the SMC instruction is within a preset range that requires kernel stack operations based on the call number contained in the SMC instruction. If the SMC instruction is not within the preset range that requires kernel stack operations, it returns to the hook point and cancels the interception of the event function. If the SMC instruction is within the preset range that requires kernel stack operations, it performs a legality check on the kernel stack operations of the intercepted event function. In Monitor Mode, the call number (SMC_fid) in the incoming SMC instruction is compared. If it is an SMC instruction that requires kernel stack operations, the operation is processed; otherwise, no processing is performed, and the normal process continues (i.e., it returns to the hook point and continues to execute other operations). The SMC (Secure Monitor Command) instruction is part of Trustzone technology. When switching from the normal world to the secure world, it is necessary to enter the secure monitor for operation. Under the ARM architecture, the SMC instruction is used to enter the TrustZone. The content of the SMC instruction contains at least the call number of the triggered event function. The call number contains information such as the corresponding kernel stack operation and the function to be implemented. The instruction processing module can determine whether to perform a legality check on the intercepted event function based on the call number.

[0077] (4) A legality check module is used to check the legality of the kernel stack operation corresponding to the intercepted event function based on the thread identifier corresponding to the kernel stack operation of the intercepted event function and the requested kernel stack base address and the thread identifier and kernel stack base address stored in the secure memory.

[0078] This module is responsible for checking the legality of kernel stack creation or write operations, and works in conjunction with the kernel stack protection module to protect the kernel stack. To protect the kernel stack, the kernel stack operation legality checking module enables the W⊕X protection mechanism, marking the kernel stack memory of the scheduled thread as either writable or executable, but not both simultaneously. This prevents an attacker from executing code even if they inject it into writable memory. The kernel stack operation legality check is performed when the following events occur:

[0079] ① When the kernel stack is created, check whether the base address of the created kernel stack is within the protected kernel stack range. If so, call the exception handling module.

[0080] ② When switching kernel stacks, check whether the kernel stack base address being switched to is the same as the kernel stack base address corresponding to the thread identifier stored in Secure World. If they are different, call the exception handling module.

[0081] ③ When writing to the kernel stack, if the kernel stack being written is not the current kernel stack, the exception handling module is called. The operation of writing to the current kernel stack is protected by the W⊕X mechanism, and its legality can be checked by combining some forward and backward control flow integrity protection methods. If it is illegal, the exception handling module is called.

[0082] (5) The exception handling module is used to lock the system when the kernel stack operation corresponding to the intercepted event function is found to be invalid, and to return to the hook point and cancel the interception of the event function when the kernel stack operation corresponding to the intercepted event function is found to be valid. This module is responsible for handling exceptions in the kernel stack operation validity check module. When the kernel stack operation validity check module detects that the kernel stack base address is reused or modified, it will enter the exception handling module to lock the system, preventing further damage to the system and consequences such as malicious code execution and control flow hijacking. The system lock can be lifted through preset tools, methods or channels.

[0083] Optionally, the system also includes:

[0084] (6) A kernel stack protection module is used to set the read / write permissions of the kernel stack region corresponding to non-scheduled threads in the secure memory to read-only in the Linux kernel under rich execution environment, and readable and writable in monitor mode under trusted execution environment during kernel operation. The kernel stack protection module is implemented based on a kernel stack controller, specifically a TZC-400 controller.

[0085] The kernel stack protection module protects the kernel stack by modifying its read and write permissions. The TZC-400 controller is used to modify read-only permissions. The TZC-400 controller can set a filtering unit for each ACE-Lite bus accessing the Dynamic Memory Controller (DMC), strictly controlling its access permissions to DRAM. The TZC-400 controller has the following functions: allows the definition of 8 memory address regions; the default base region (Region 0) covers the entire memory address space; allows defining security access permissions for these regions in the secure world; the filtering unit only allows data transmission via ACE-Lite buses that comply with security access control; and the filtering unit can share the security configuration of each address region. During kernel initialization, space is allocated in the Secure World to store thread identifiers and their corresponding kernel stack base addresses. During runtime, the read and write permissions for the kernel stack memory region of non-scheduled threads are set to Linux read-only. When attempting to write to the kernel stack of a non-scheduled thread, the TZC-400 controller will intercept and reject the operation.

[0086] The kernel stack protection method and system provided by this invention can monitor and intercept kernel stack-related event functions. In a monitor mode within a trusted execution environment, a subset of kernel stack-related event functions are filtered. Based on thread identifiers and kernel stack base addresses stored in pre-allocated secure memory, the legality of the filtered kernel stack-related event functions is verified. For legal kernel stack operations, interception is canceled and execution is performed; for illegal kernel stack operations, the system is locked. Compared to existing technologies, this invention uses a monitor mode within a trusted execution environment to avoid being in the same address space and privilege level as the Linux kernel, while also avoiding dependence on a hypervisor, thereby improving the security protection performance of the operating system kernel stack.

[0087] Unlike existing kernel stack protection methods, this invention incorporates TEE (Trusted Execution Environment) technology. It stores thread identifiers and corresponding kernel stack base addresses in pre-defined secure memory, places hook points in Linux kernel stack creation, release, and switching functions, and jumps to a trusted execution environment to check the legality of these operations. This effectively avoids attacks such as modification and reuse of the kernel stack base address. Furthermore, the kernel stack controller enables a W⊕X mechanism on the kernel stack of non-scheduled threads, marking the kernel stack memory as writable or executable, preventing modification of non-scheduled thread kernel stack data. This completes kernel stack protection; even if an attacker injects code into writable memory, it cannot be executed. Moreover, this invention can combine with other forward and backward control flow integrity protection schemes during the kernel stack operation legality detection process to protect control flow integrity.

[0088] Corresponding to the above method, the present invention also provides an apparatus comprising a computer device, the computer device including a processor and a memory, the memory storing computer instructions, and the processor executing the computer instructions stored in the memory. When the computer instructions are executed by the processor, the apparatus implements the steps of the method as described above. This apparatus can be used to run the program code or instructions corresponding to the above method.

[0089] Optionally, device manufacturers can modify and release the Linux operating system and TEE code based on the method provided by this invention. Device users can download and update the new version via the network, and after restarting the kernel, the protection of this invention can be enabled.

[0090] This invention also provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the steps of the method described above. The computer-readable storage medium can be a tangible storage medium, such as random access memory (RAM), main memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, floppy disks, hard disks, removable storage disks, CD-ROMs, or any other form of storage medium known in the art. This computer-readable storage medium can be used to store program code or instructions corresponding to the above-described methods.

[0091] Those skilled in the art will understand that the exemplary components, systems, and methods described in conjunction with the embodiments disclosed herein can be implemented in hardware, software, or a combination of both. Whether implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this invention. When implemented in hardware, it can be, for example, electronic circuits, application-specific integrated circuits (ASICs), appropriate firmware, plug-ins, function cards, etc. When implemented in software, the elements of this invention are programs or code segments used to perform the desired tasks. The programs or code segments can be stored in a machine-readable medium or transmitted over a transmission medium or communication link via data signals carried in a carrier wave.

[0092] It should be clarified that the present invention is not limited to the specific configurations and processes described above and shown in the figures. For the sake of brevity, detailed descriptions of known methods are omitted here. In the above embodiments, several specific steps are described and shown as examples. However, the method process of the present invention is not limited to the specific steps described and shown. Those skilled in the art can make various changes, modifications, and additions, or change the order of steps, after understanding the spirit of the present invention.

[0093] In this invention, features described and / or illustrated for one embodiment may be used in the same or similar manner in one or more other embodiments, and / or combined with or in place of features of other embodiments.

[0094] The above description is merely a preferred embodiment of the present invention and is not intended to limit the present invention. For those skilled in the art, various modifications and variations of the embodiments of the present invention are possible. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A kernel stack protection method, characterized in that, The method includes the following steps: Monitor event functions in the kernel under rich execution environment, intercept event functions related to kernel stack operations, and set hook points in the intercepted event functions related to kernel stack operations; Receive SMC instructions triggered by event functions related to the kernel stack. In the monitor mode of the trusted execution environment, determine whether the SMC instruction is an SMC instruction within the preset range that needs to perform kernel stack operations based on the call number contained in the SMC instruction. If the SMC instruction is not within the preset range that needs to perform kernel stack operations, return to the hook point to cancel the interception of the event function. If the SMC instruction is within the preset range that needs to perform kernel stack operations, perform a legality check step on the kernel stack operations of the intercepted event function. The legality check steps are as follows: Based on the thread identifier corresponding to the kernel stack operation of the intercepted event function and the requested kernel stack base address, and the thread identifier and the kernel stack base address corresponding to the thread identifier stored in the safe memory, the legality of the kernel stack operation corresponding to the intercepted event function is checked. The safe memory is allocated in the trusted execution environment during the Linux kernel initialization phase. If the kernel stack operation corresponding to the intercepted event function is found to be invalid, the system will be locked; if the kernel stack operation corresponding to the intercepted event function is found to be valid, the hook point will be returned and the interception of the event function will be canceled. The method further includes: setting the read / write permissions of the kernel stack region corresponding to the non-scheduled thread in the secure memory area to read-only in the Linux kernel under the rich execution environment, and readable and writable in the monitor mode of the trusted execution environment during kernel operation; after the step of canceling the interception of the event function by returning the hook point when the kernel stack operation corresponding to the intercepted event function is found to be legal, the method further includes: executing the kernel stack operation corresponding to the intercepted event function in the monitor mode of the trusted execution environment, and switching back from the trusted execution environment to the rich execution environment after completion; The kernel stack operations performed within the preset range include kernel stack creation, kernel stack switching, and kernel stack writing; The legality check steps include: when the kernel stack operation of the intercepted event function is kernel stack creation, obtaining the thread identifier corresponding to kernel stack creation and the requested kernel stack base address, checking whether the created kernel stack base address conflicts with the kernel stack base address already stored in the safe memory; if a conflict occurs, the kernel stack creation is deemed invalid; if no conflict occurs, the kernel stack creation is deemed valid. When the kernel stack operation of the intercepted event function is kernel stack switching, obtaining the thread identifier corresponding to kernel stack switching and the requested kernel stack base address, checking whether the switched-in kernel stack base address is the same as the kernel stack base address already stored in the safe memory; if they are different, the kernel stack creation is deemed invalid; if they are the same, the kernel stack creation is deemed valid. When the kernel stack operation of the intercepted event function is kernel stack writing, obtaining the thread identifier corresponding to kernel stack writing and the requested kernel stack base address, checking whether the written kernel stack base address is the same as the kernel stack base address of the writing thread stored in the safe memory; if they are different, the kernel stack writing is deemed invalid; if they are the same, the kernel stack writing is deemed valid.

2. The kernel stack protection method according to claim 1, characterized in that, The step of setting the read / write permissions of the kernel stack corresponding to the non-scheduled thread in the secure memory region during kernel operation to be read-only in the Linux kernel under rich execution environment and readable and writable in the monitor mode under trusted execution environment is implemented through the kernel stack controller.

3. The kernel stack protection method according to claim 1, characterized in that, The method also includes: SMC instructions that require kernel stack operations within a preset range correspond to scheduling threads; Within the preset range, the kernel stack corresponding to the kernel stack operation to be performed is set to writable or executable in the secure memory, and simultaneous kernel stack writing and kernel stack execution are not allowed for any thread's kernel stack.

4. The kernel stack protection method according to claim 1, characterized in that, In the legality check step, when the kernel stack operation of the intercepted event function is a kernel stack write, the method further includes: The legitimacy of the kernel stack write is checked by combining forward control flow integrity protection and / or backward control flow integrity protection.

5. The kernel stack protection method according to claim 1, characterized in that, If the SMC instruction is not within the preset range that requires kernel stack operations, then after returning to the hook point to cancel the interception of the event function, the method further includes: returning to the hook point and executing the kernel stack operation corresponding to the SMC instruction in the monitor mode of the trusted execution environment based on the SMC instruction, and switching the trusted execution environment to the rich execution environment after the kernel stack operation is completed. The kernel stack operations that need to be performed outside the preset range include kernel stack release.

6. The kernel stack protection method according to claim 1, characterized in that, The method also includes: unlocking the system's locked state based on a preset key.

7. A kernel stack protection system, characterized in that, This system is used to implement the kernel stack protection method according to any one of claims 1-6, and the system comprises: Safe memory is used to allocate safe memory in a trusted execution environment during the Linux kernel initialization phase. The safe memory is used to store thread identifiers and the kernel stack base address corresponding to the thread identifiers. The kernel stack operation interception module is used to monitor event functions in the kernel in a rich execution environment, intercept event functions related to kernel stack operations, and set hook points in the intercepted event functions related to kernel stack operations. The instruction processing module is used to receive SMC instructions triggered by event functions related to the kernel stack. In the monitor mode of the trusted execution environment, it determines whether the SMC instruction is an SMC instruction that needs to perform kernel stack operations within a preset range based on the call number contained in the SMC instruction. If the SMC instruction is not an SMC instruction that needs to perform kernel stack operations within the preset range, it returns to the hook point to cancel the interception of the event function. If the SMC instruction is an SMC instruction that needs to perform kernel stack operations within the preset range, it performs a legality check step on the kernel stack operations of the intercepted event function. The legality check module is used to check the legality of the kernel stack operation corresponding to the intercepted event function based on the thread identifier and the requested kernel stack base address corresponding to the kernel stack operation of the intercepted event function and the thread identifier and kernel stack base address stored in the secure memory. The exception handling module is used to lock the system when the kernel stack operation corresponding to the intercepted event function is found to be invalid, and to return to the hook point and cancel the interception of the event function when the kernel stack operation corresponding to the intercepted event function is found to be valid.

8. The kernel stack protection system according to claim 7, characterized in that, The system also includes: The kernel stack protection module is used to set the read and write permissions of the kernel stack corresponding to non-scheduled threads in the secure memory area to read-only in the Linux kernel under rich execution environment, and readable and writable in monitor mode under trusted execution environment during kernel operation.

Images