CN115729771A - Kernel thread protection method, terminal and computer readable storage medium - Google Patents
Kernel thread protection method, terminal and computer readable storage medium Download PDFInfo
- Publication number
- CN115729771A CN115729771A CN202111022540.6A CN202111022540A CN115729771A CN 115729771 A CN115729771 A CN 115729771A CN 202111022540 A CN202111022540 A CN 202111022540A CN 115729771 A CN115729771 A CN 115729771A
- Authority
- CN
- China
- Prior art keywords
- thread
- monitoring
- kernel
- state
- task
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/30—Monitoring
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Quality & Reliability (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Debugging And Monitoring (AREA)
Abstract
The embodiment of the application relates to the technical field of communication, in particular to a kernel thread protection method, a terminal and a computer readable storage medium. The kernel thread at least comprises: the protection method of the first thread and the second thread and the kernel thread comprises the following steps: executing work to be protected through the first thread; monitoring the second thread through the first thread, and monitoring the first thread through the second thread; if the first thread is monitored to be abnormal or the second thread is monitored to be abnormal, the memory read-write operation during the execution of the work to be protected is intercepted, and the safety of kernel thread protection can be improved.
Description
Technical Field
The embodiment of the application relates to the technical field of communication, in particular to a kernel thread protection method, a terminal and a computer readable storage medium.
Background
In modern computer operating systems, multi-threaded operations play a very important role, allowing a user to control multiple tasks at the same time. In an operating system kernel, there are many kernel threads, which are processes that are directly initiated by the kernel itself, which in effect delegate kernel functions to separate processes for execution. Kernel threads can be viewed as an avatar of the kernel, and an avatar can handle a particular thing. The kernel thread can only run in the kernel mode and cannot run in the user mode, and the kernel thread can only access the kernel part of the virtual address space and cannot access the user space. If a user needs to perform a task that needs to be automatically performed immediately after system startup and wants the task to run continuously during system operation, using kernel threads to perform the task is a good option.
The existing kernel thread protection scheme mainly comprises the following steps: single-threaded monitoring, i.e. creating a thread and monitoring other threads, has a serious drawback that if an attacker kills the monitoring thread first, the protection measure is disabled, i.e. the security of kernel thread protection is low.
Disclosure of Invention
The main purpose of the embodiments of the present application is to provide a method, a terminal, and a computer-readable storage medium for protecting a kernel thread, which can improve security of kernel thread protection.
In order to achieve at least the above object, an embodiment of the present application provides a method for protecting a kernel thread, where the kernel thread at least includes: a first thread and a second thread, the method comprising: executing work to be protected through the first thread; monitoring the second thread through the first thread, and monitoring the first thread through the second thread; and if the first thread is monitored to be abnormal or the second thread is monitored to be abnormal, intercepting the memory read-write operation during the execution of the work to be protected.
In order to achieve the above object, an embodiment of the present application further provides a terminal, including: at least one processor; and a memory communicatively coupled to the at least one processor; wherein the memory stores instructions executable by the at least one processor to enable the at least one processor to perform the above-described kernel thread protection method.
To achieve at least the above object, an embodiment of the present application further provides a computer-readable storage medium storing a computer program, where the computer program, when executed by a processor, implements the method for protecting a kernel thread described above.
In this embodiment, the kernel thread at least includes: the system comprises a first thread and a second thread, wherein the first thread executes work to be protected; monitoring the second thread through the first thread, and monitoring the first thread through the second thread; and if the first thread is monitored to be abnormal or the second thread is monitored to be abnormal, intercepting the memory read-write operation when the work to be protected is executed. The first thread is regarded as a working thread, the first thread performs the work to be done, namely the work to be protected, and the second thread is regarded as a monitoring thread, the first thread monitors the second thread, and the second thread monitors the first thread to form a monitoring ring. And when the abnormity is monitored, the read-write operation of the memory is intercepted, namely the system is directly locked to prevent the system from being further damaged. If an attacker wants to break the monitoring ring and is not detected, the attacker needs to break the first thread and the second thread simultaneously in one period of monitoring ring protection, and the difficulty of breaking the first thread and the second thread simultaneously in the same period is very high, so that the breaking difficulty of the kernel thread protection method in the embodiment of the application is high, and the safety of kernel thread protection can be improved.
Drawings
FIG. 1 is a flow chart illustrating a kernel thread protection method according to an embodiment of the present disclosure;
fig. 2 is a schematic flowchart of an implementation manner of monitoring a second thread by a first thread and monitoring a first thread by a second thread in the embodiment of the present application;
fig. 3 is a flowchart illustrating an implementation process of monitoring a running status of a second thread by a first thread to determine whether the running status of the second thread is a dead status or a permanently suspended status according to an embodiment of the present application;
fig. 4 is a flowchart illustrating an implementation process of monitoring the running status of the first thread through the second thread to determine whether the running status of the first thread is a dead status or a permanently suspended status according to an embodiment of the present application;
FIG. 5 is a schematic view of a monitoring ring as referred to in the embodiments of the present application;
FIG. 6 is a diagram illustrating a kernel execution mode according to an embodiment of the present application;
FIG. 7 is a schematic diagram of the TEE execution mode mentioned in the embodiments of the present application;
FIG. 8 is a schematic diagram of a hybrid execution mode referred to in the embodiments of the present application;
fig. 9 is a schematic structural diagram of a terminal mentioned in the embodiment of the present application.
Detailed Description
To make the objects, technical solutions and advantages of the embodiments of the present application clearer, the embodiments of the present application will be described in detail below with reference to the accompanying drawings. However, it will be appreciated by those of ordinary skill in the art that in the examples of the present application, numerous technical details are set forth in order to provide a better understanding of the present application. However, the technical solutions claimed in the present application can be implemented without these technical details and various changes and modifications based on the following embodiments. The following embodiments are divided for convenience of description, and should not constitute any limitation to the specific implementation manner of the present application, and the embodiments may be mutually incorporated and referred to without contradiction.
With the rapid development of mobile communication and internet technologies, intelligent terminals play more and more important roles in various fields, and the security of the intelligent terminals becomes more and more important. If a relatively Trusted operating Environment can be provided in the system, the critical data or application of the user can be used and operated in the relatively Trusted Environment, so that even if the system is broken, an intruder cannot directly acquire important information of the user, which is the main role and concept of a Trusted Execution Environment (TEE). In order to provide a safe operating environment for a terminal, a TrustZone technology is introduced into an Advanced RISC Machines (ARM), which divides the working state of a Central Processing Unit (CPU) into a Normal World and a Secure World, and when the CPU works in the Normal World state, a user cannot access any resource in the Secure World state even if the user has root authority. The system can realize the switching between the Secure World state and the Normal World state of the ARM core by calling a Secure Monitor Call (SMC) instruction, and when the system calls an SMC instruction, the system can be trapped in the Monitor Mode. In the embodiment of the application, by combining with a Trusted Execution Environment (TEE) technology, the work code executed by the kernel thread can be protected in the TEE.
In one embodiment of the present application, the kernel thread includes a first thread and a second thread, the first thread is regarded as a working thread, which performs both the work to be performed, i.e., the work to be protected, and the monitoring work, and the second thread is regarded as a monitoring thread, the first thread monitors the second thread, and the second thread monitors the first thread to form a monitoring loop. Referring to fig. 1, a method for protecting a kernel thread provided in an embodiment of the present application includes:
step 101: executing work to be protected through a first thread;
step 102: monitoring the second thread through the first thread, and monitoring the first thread through the second thread;
step 103: and if the first thread is monitored to be abnormal or the second thread is monitored to be abnormal, intercepting the memory read-write operation when the work to be protected is executed.
In the embodiment of the application, when the abnormality is monitored, the memory read-write operation is intercepted, namely, the system is directly locked to prevent the system from being further damaged. If an attacker wants to break the monitoring exchange formed between the first thread and the second thread and make the attack behavior undetected, the attacker needs to break the first thread and the second thread simultaneously in one period of the monitoring ring protection, and the difficulty of breaking the first thread and the second thread simultaneously in the same period is very high, so that the breaking difficulty of the kernel thread protection method in the embodiment of the application is very high, and the safety of kernel thread protection can be improved, so that the safety of work to be protected is ensured.
In one example, after the kernel boot is completed, such as after the Linux kernel boot is completed, the terminal may automatically execute a function that will sequentially create and activate the first thread and the second thread.
In step 101, a work code that needs to perform a work to be protected may be written into the first thread, so that the terminal may perform the work to be protected through the first thread. The work to be protected may be, for example: payment work, face recognition work, fingerprint recognition work, and the like. The protection method for the kernel thread in this embodiment can finally protect the security of the work to be protected in the execution process through the monitoring of the monitoring ring.
In step 102, code for monitoring the second thread may be written to the first thread, such that the terminal may monitor the second thread via the first thread. The code for monitoring the first thread may be written to the second thread so that the terminal may monitor the first thread through the second thread. That is, the first thread and the second thread may monitor each other.
In step 103, if the terminal monitors that the first thread is abnormal or monitors that the second thread is abnormal, the memory read-write operation is intercepted, that is, when the abnormality is monitored, the memory read-write operation is not executed any more, and the system is directly locked to prevent the system from being further damaged.
Wherein monitoring for exceptions of the first thread may include: the running state of the first thread is a dead state or a permanent suspension state, and the function code segment of the first thread is tampered. And monitoring that the exception of the second thread is similar to the exception of the first thread, and the detailed description is omitted here for avoiding repetition. That is to say, in this step, the running state of the second thread may be monitored by the first thread, and it is determined whether the running state of the second thread is a death state or a permanent suspension state; and monitoring the running state of the first thread through the second thread, and determining whether the running state of the first thread is a dead state or a permanent suspension state.
In one example, intercepting a memory read-write operation when performing a work to be protected includes: a TrustZone address space control component is called in a Monitor Mode of a Secure World security World, so that the memory read-write operation during the execution of the work to be protected is intercepted, and the efficient and accurate interception of the memory read-write operation is facilitated. The TrustZone address space control component may be a TZC400 controller or a TZC380 controller, and the like, which is not specifically limited in this embodiment.
In one embodiment, considering that the current attacks on kernel threads can be classified into the following two types: 1) And permanently suspending or killing the kernel thread, wherein an attacker can acquire the task _ struct structure of the attacked kernel thread through various malicious means and then kill or permanently suspend the kernel thread, so that the attacked kernel thread can not continue to execute tasks. 2) The working code executed by the kernel thread is tampered, an attacker can find out the memory address of the working code executed by the attacked kernel thread, and then the working code execution flow is directly modified or the working code executed by the kernel thread is tampered, so that the purpose of attacking is achieved. Based on this, the present embodiment provides two monitoring manners for the kernel thread, 1) monitoring whether the running state of the kernel thread is a dead state or a permanent suspension state, that is, monitoring whether the running states of the first thread and the second thread included in the kernel thread are a dead state or a permanent suspension state. 2) The method comprises the steps of monitoring whether the working codes executed by the kernel thread are tampered, namely monitoring whether the working codes executed by at least a first thread and a second thread included by the kernel thread are tampered. Two monitoring modes are described below:
in one embodiment, in the case that the working codes executed by the first thread and the second thread are stored in the read-only code segment of the kernel space, the first thread and the second thread may be subjected to code read-only detection, wherein the executed working codes are considered not to be tampered when the code read-only detection is passed, and the executed working codes are considered to be tampered when the code read-only detection is not passed. The implementation manner of monitoring the second thread by the first thread and monitoring the first thread by the second thread may refer to fig. 2, and includes:
step 201: acquiring a first address interval of a working code executed by a first thread in a kernel space, and acquiring a second address interval of a working code executed by a second thread in the kernel space;
step 202: verifying a working code executed by a first thread and a working code executed by a second thread according to the content of the first address interval and the content of the second address interval to obtain a first verification result corresponding to the first thread and a second verification result corresponding to the second thread;
step 203: monitoring whether the working code executed by the first thread is tampered or not according to the first verification result and a first standard verification result corresponding to the first thread;
step 204: and monitoring whether the working code executed by the second thread is tampered or not according to the second check result and a second standard check result corresponding to the second thread.
In one example, the implementation of step 202 may be: and carrying out byte-based XOR according to the content of the first address interval to obtain an XOR result, and taking the XOR result as a first check result corresponding to the first thread. The byte exclusive or mode may be: and performing XOR on the content of the first byte and the content of the second byte in the first address interval to obtain an XOR value, continuously performing XOR on the XOR value and the content of the third byte to obtain a latest XOR value, performing XOR on the new XOR value and the content of the third byte to obtain a latest XOR value, and so on until the XOR with the last byte is completed to obtain a last XOR value, wherein the last XOR value is the first check result. The obtaining manner of the second check result is similar to that of the first check result, and is not repeated here to avoid repetition.
In one example, the implementation of step 202 may be: and obtaining a first hash value according to the content of the first address interval, using the first hash value as a first check result corresponding to the first thread, obtaining a second hash value according to the content of the second address interval, and using the second hash value as a second check result corresponding to the second thread.
In step 203, if the first verification result is the same as the first standard verification result corresponding to the first thread, it may be determined that the working code executed by the first thread is not tampered, so as to determine that the code read-only detection performed on the first thread passes. If the first verification result is different from the first standard verification result corresponding to the first thread, the working code executed by the first thread can be determined to be tampered, and therefore the code read-only detection of the first thread is determined not to pass.
In one example, the first check result is an exclusive-or result and the first standard check result is a first standard exclusive-or result. The first standard exclusive-OR result is an exclusive-OR result obtained by performing code read-only detection on the first thread for the first time. When code read-only detection is executed for the first time, an SMC instruction is called in the first thread to switch the system to Monitor Mode, a first address interval of a work code of the first thread in an inner core space is obtained, the content of the first address interval is subjected to exclusive OR operation according to bytes, an exclusive OR result is obtained, and the initially obtained exclusive OR result can be used as a first standard check result.
In one example, the first verification result is a first hash value and the first standard verification result is a first standard hash value. The first standard hash value is a hash value obtained by performing code read-only detection on the first thread for the first time. When code read-only detection is executed for the first time, an SMC instruction is called in a first thread to switch the system to Monitor Mode, a first address interval of a working code of the first thread in a kernel space is obtained, a first hash value is obtained from the content of the first address interval, and the first hash value obtained for the first time can be used as a first standard hash value.
In step 204, if the second check result is the same as the second standard check result corresponding to the second thread, it may be determined that the working code executed by the second thread has not been tampered, and thus it is determined that the code read-only detection performed on the second thread passes. And if the second check result is different from a second standard check result corresponding to the second thread, the working code executed by the second thread can be determined to be tampered, so that the code read-only detection of the second thread is determined not to pass.
In one example, the second check result is an exclusive-or result and the second standard check result is a second standard exclusive-or result. And the second standard exclusive-OR result is an exclusive-OR result obtained by carrying out code read-only detection on the second thread for the first time. The determination manner of the second xor result is similar to that of the first xor result, and is not repeated here to avoid repetition.
In one example, the second verification result is a second hash value, and the second standard verification result is a second standard hash value. The second standard hash value is a hash value obtained by performing code read-only detection on the second thread for the first time. The determination method of the second standard hash value is similar to the determination method of the first standard hash value, and is not described herein again to avoid repetition.
In one example, the first thread and the second thread may be periodically tested for code read-only, and the first thread and the second thread may be periodically determined whether to pass the code read-only test. And when the code read-only detection fails, triggering a defense measure card system, wherein the defense measure intercepts the memory read-write operation.
In one example, before step 201, the method further includes: intercepting a target SMC instruction sent from the Normal World to the Secure World; and the target SMC instruction is used for detecting whether the function code segment is tampered. In a specific implementation, a target SMC _ fid corresponding to the target SMC instruction may be preset, and the target SMC _ fid may be understood as an instruction identifier of the target SMC instruction. When an SMC instruction sent from a Normal World to a Secure World is received, the SMC _ fid of the received SMC instruction is obtained, if the SMC _ fid of the received SMC instruction is the same as the target SMC _ fid, the received SMC instruction is considered as a target SMC instruction, and therefore the target SMC instruction sent from the Normal World to the Secure World can be determined to be intercepted, and code read-only detection on a kernel thread can be carried out continuously.
In this embodiment, a TEE technology is combined, the read-only performance of the work code executed by the kernel thread can be periodically checked and protected in the TEE, that is, in the Secure World, and the detection of whether the work code executed by the kernel thread is tampered or not can be performed in time by intercepting the target SMC instruction, so that the read-write operation of the memory can be intercepted in time after the work code is detected to be tampered, and the system is prevented from being further damaged.
In one embodiment, monitoring the running state of the second thread by the first thread to determine whether the running state of the second thread is a dead state or a permanent suspension state comprises: detecting whether a first pointer of a task _ struct type created by a first thread is a valid pointer; wherein the first pointer points to a first task _ struct structure of the second thread; detecting the value of a state variable of the first task _ struct structure under the condition that the first pointer is an effective pointer; under the condition that the value of the state variable of the first task _ struct structure body is a preset first class value, determining that the running state of the second thread is a death state; and when the duration of the state variable of the first task _ struct structure is greater than the preset duration, determining that the running state of the first thread is a permanent suspension state. The preset first class value may be used to characterize the death status, for example, the first class value may include: 4. 16, 32 or 128, etc., the preset second class of values may be used to characterize the uninterruptible suspend state, such as the second class of values may include: 2. the preset duration may be set according to actual needs, which is not specifically limited in this embodiment.
In a specific implementation, a code for monitoring the running state of the second thread may be run in the first thread, so that the terminal may monitor the running state of the second thread through the first thread. The second thread may run a code for monitoring the running state of the first thread, so that the terminal may monitor the running state of the first thread through the second thread. When a kernel thread ring, namely a monitoring ring, has a thread killed or suspended permanently (namely the running state of a certain thread in the kernel thread ring is monitored to be a dead state or a permanently suspended state), the kernel thread ring starts a defensive measure blocking system.
In one example, the implementation process of monitoring the running state of the second thread by the first thread to determine whether the running state of the second thread is a dead state or a permanent suspension state may refer to fig. 3, which includes:
step 301: acquiring a first pointer of a task _ struct type created by a first thread;
wherein the first pointer points to a first task _ struct structure of the second thread.
Step 302: while (1);
step 303: detecting whether the acquired first pointer is a valid pointer; if yes, go to step 304, otherwise go to step 311;
step 304: judging whether the value of the state variable of the first task _ struct structure is 4, 16, 32 or 128; if yes, go to step 311, otherwise go to step 305;
step 305: acquiring a current time point 1;
step 306: judging whether the value of the state variable of the first task _ struct structure is 2 or not; if yes, go to step 307, otherwise go to step 302;
step 307: acquiring a current time point 2, and acquiring a time difference between the current time point 1 and the current time point 2;
step 308: judging whether the time difference exceeds a preset time length or not; if yes, go to step 309, otherwise go to step 310;
the determination of whether the time difference exceeds the preset time duration may be understood as determining whether the duration of the second thread in the uninterruptible suspended state exceeds the preset time duration.
Step 309: determining the running state of the second thread as a permanent suspension state;
step 310: delaying for 100 milliseconds, and continuing to execute the step 306;
step 311: the running state of the second thread is determined to be a dead state.
In a specific implementation, after steps 309 and 311, i.e., it has been determined that the second thread is abnormal, a memory read/write operation may be intercepted.
In one embodiment, monitoring the running state of the first thread by the second thread to determine whether the running state of the first thread is a dead state or a permanently suspended state comprises: detecting whether a second pointer of the task _ struct type created by the second thread is a valid pointer; the second pointer points to a second task _ struct structural body of the first thread; detecting the value of a state variable of a second task _ struct structure under the condition that the second pointer is an effective pointer; under the condition that the value of the state variable of the second task _ struct structure body is a preset first-class value, determining that the running state of the first thread is a death state; and under the condition that the value of the state variable of the second task _ struct structure body is a preset second type value, determining that the running state of the first thread is an uninterruptible suspended state, and when the duration of the uninterruptible suspended state of the running state of the first thread exceeds a preset duration, determining that the running state of the first thread is a permanent suspended state. The descriptions of the first class value, the second class value, and the preset duration may refer to the above descriptions, and are not repeated here to avoid repetition.
In one example, the implementation process of monitoring the running state of the first thread by the second thread to determine whether the running state of the first thread is a dead state or a permanent suspension state may refer to fig. 4, which includes:
step 401: acquiring a second pointer of a task _ struct type created by a second thread;
and the second pointer points to a second task _ struct structure of the first thread.
Step 402: while (1);
step 403: detecting whether the obtained second pointer is a valid pointer; if yes, go to step 404, otherwise go to step 411;
step 404: judging whether the value of the state variable of the second task _ struct structure is 4, 16, 32 or 128; if yes, go to step 411, otherwise go to step 405;
step 405: acquiring a current time point 1;
step 406: judging whether the value of the state variable of the second task _ struct structural body is 2 or not; if yes, go to step 407, otherwise go to step 402;
step 407: acquiring a current time point 2, and acquiring a time difference between the current time point 1 and the current time point 2;
step 408: judging whether the time difference exceeds a preset time length or not; if yes, go to step 409, otherwise go to step 410;
step 409: determining that the running state of the first thread is a permanent suspension state;
step 410: delaying for 100 milliseconds and continuing to execute step 406;
step 411: the running state of the first thread is determined to be a dead state.
In a specific implementation, after steps 409 and 411, i.e. it is determined that the first thread is abnormal, a memory read-write operation may be intercepted.
In the embodiment of the application, an attacker can be timely detected to acquire the task _ struct structure of the attacked kernel thread by various malicious means, and by monitoring the working state of the kernel thread, when the running state is monitored to be a death state or a permanent suspension state, the memory read-write operation can be timely intercepted, so that the system is prevented from being further damaged.
In one embodiment, the second thread comprises: the first monitoring thread and the second monitoring thread monitor the second thread through the first thread and monitor the first thread through the second thread, and the method comprises the following steps: the method comprises the steps of monitoring a first monitoring thread through a first thread, monitoring a second monitoring thread through the first monitoring thread, and monitoring the first thread through the second monitoring thread. That is, the kernel thread includes: the monitoring system comprises a first thread, a first monitoring thread and a second monitoring thread, wherein the three threads form a monitoring ring.
In an example, the first thread is denoted as a working thread a, the first monitoring thread is denoted as a monitoring thread B, the second monitoring thread is denoted as a monitoring thread C, and a monitoring ring formed by the working thread a, the monitoring thread B, and the monitoring thread C can refer to fig. 5, in fig. 5, the working thread a is used for monitoring the running state of the monitoring thread B, the monitoring thread B is used for monitoring the running state of the monitoring thread C, the monitoring thread C is used for monitoring the running state of the working thread a, and the working thread a is further used for performing code read-only detection. The code read-only detection work comprises the following steps: detecting whether the working code to be executed by the working thread A is tampered, detecting whether the working code to be executed by the monitoring thread B is tampered, and detecting whether the working code to be executed by the monitoring thread C is tampered.
In one example, after the Linux kernel is started, the terminal may automatically execute a function, and the function sequentially creates and activates the working thread a, the monitoring thread B, and the monitoring thread C. The working thread a executes both the work to be done and the monitoring work, and the monitoring thread B and the monitoring thread C execute the monitoring work. The monitoring relationship of the three threads is shown in fig. 5, the working thread a monitors the monitoring thread B, the monitoring thread B monitors the monitoring thread C, and the monitoring thread C monitors the working thread a to form a monitoring loop.
In the embodiment of the application, the monitoring ring formed by the three kernel threads has higher attack difficulty, that is, if an attacker wants to break the monitoring ring and cannot detect the monitoring ring, the attacker must simultaneously break the working thread and the two monitoring threads in one period of the monitoring ring protection, that is, the attacker must simultaneously break the three kernel threads in one period, however, the simultaneous breaking of the three kernel threads in one period is very difficult, so that the attack difficulty of the kernel thread protection method provided in the embodiment is higher, and the security of the kernel threads is greatly improved.
It is worth mentioning that, in the specific implementation, the number of kernel threads in the monitoring ring can be further increased on the basis of 3 according to the actual needs, so as to further increase the attack difficulty, thereby improving the security of the kernel threads.
In one embodiment, the operating mode when the first thread performs the work includes: a kernel execution mode, a TEE execution mode and a hybrid execution mode; in the kernel execution mode, a working code executed when a first thread works is written into the first thread; in the TEE execution mode, a working code executed when a first thread works is written into a Trusted Application (TA) created in the Secure World, and the first thread executes the working code by calling the TA; in the mixed execution mode, a first working code executed when a first thread works is written into the first thread, a second working code executed when the first thread works is written into a TA created in a Secure World, and the first thread executes the second working code by calling the TA. Three modes of operation are described in detail below:
if the amount of the work code to be executed is large and the execution efficiency is high, if the kernel mode execution can meet the security requirement, the work code to be executed can be directly written in the first thread, which is the kernel execution mode. Assuming that the monitoring loop in this embodiment adopts the monitoring loop shown in fig. 5, a schematic diagram of the kernel execution mode may refer to fig. 6, that is, the work code to be executed is written in the worker thread a.
If the amount of work code to be executed is small and the security requirements for the work are high, the kernel-mode execution is not sufficient to meet the security requirements, then the work may be selected to be executed in the TEE. Creating a TA in SecureWorld, writing work code with high safety requirement in the TA, calling SMC instruction by the first thread through TEE driver and the like to make the TA in SecureWorld execute work, namely the TEE execution mode. Assuming that the monitoring loop in this embodiment is the monitoring loop shown in fig. 5, the schematic diagram of the TEE execution mode may refer to fig. 7, that is, the work code to be executed is written in TA, and the worker thread a makes TA in SecureWorld execute the work code by calling SMC instruction. The task with high safety requirement is completed by calling TA in SecurWorld by the working thread A. Thus, the working code executed by the working thread A is essentially run in the TEE, and even if an attacker obtains the root authority under the Normal World, the attacker cannot know what task the working thread A executes, so that the confidentiality is extremely high.
If the amount of the work code to be executed is large, but only a part of the code has extremely high security requirements, the kernel mode is not enough to meet the security of the execution of the code, and the execution of the other part of the code can be completely executed by the kernel mode, then the code with extremely high security requirements (the second kind of work code) can be selected to use the TEE execution mode, and the other part of the code (the first kind of work code) uses the kernel execution mode, which is the mixed execution mode. Assuming that the monitoring loop in this embodiment adopts the monitoring loop shown in fig. 5, referring to fig. 8, a schematic diagram of the hybrid execution mode may be that a first working code is written in the working thread a, a second working code is written in the TA, and when the working thread a needs to execute the second working code, the TA in SecureWorld may execute the second working code by calling an SMC instruction. That is to say, in the hybrid execution mode, the work code that really has a high requirement on security is put into the TEE for execution, and the work code that does not have a high requirement on security is put into the work thread a for execution, and considering that putting all the work codes into the TEE for execution may affect the execution efficiency, therefore, the hybrid execution mode in this embodiment may give consideration to both security and execution efficiency.
In a specific implementation, when the working code is written in a TA created in Secure World, the working code is difficult to be tampered, and the security is high. Therefore, in the TEE execution mode, since the work code executed when the first thread works is written in the TA created in Secure World, the code readonly detection may not be performed on the first thread. In the hybrid execution mode, since the second type of work code in the first thread is written in the TA created in Secure World, no code-read-only detection may be performed on the second type of work code in the first thread. By not performing code read-only detection, the execution efficiency of the system can be improved to a certain extent.
The embodiment has the advantage of enabling the user to flexibly select the task execution mode. If the task code amount is large and the requirement efficiency is high, the user can select to execute the task in the kernel mode; if the task code amount is not large, the requirement on safety is high, and a user can select to execute the task in a TEE mode; if security and task execution efficiency are to be compromised, the user may choose to execute the task in the hybrid mode. In addition, the embodiment is not limited to the Linux operating system, and can also be used in the Android operating system and other operating systems providing trusted execution environments, so that the portability is better. Moreover, the present embodiment does not limit the version of the Linux operating system, as long as the Linux operating system provides a trusted execution environment.
In specific implementation, an operating system manufacturer and a TEE provider can respectively update an operating system and a TEE according to the method provided by the embodiment of the application, a terminal of a user downloads an update package through a network and then installs the update, and when the operating system and the TEE are updated, the terminal of the user can automatically run the kernel thread protection method in the embodiment of the application.
It should be noted that the foregoing examples in the embodiments of the present application are only for convenience of understanding, and do not limit the technical solutions of the present invention.
The steps of the above methods are divided for clarity, and the implementation may be combined into one step or split some steps, and the steps are divided into multiple steps, so long as the same logical relationship is included, which are all within the protection scope of the present patent; it is within the scope of the patent to add insignificant modifications to the algorithms or processes or to introduce insignificant design changes to the core design without changing the algorithms or processes.
An embodiment of the present application further provides a terminal, as shown in fig. 9, including at least one processor 901; and, memory 902 communicatively connected to at least one processor 901; the memory 902 stores instructions executable by the at least one processor 901, and the instructions are executed by the at least one processor 901, so that the at least one processor 901 can execute the protection method for the kernel thread in the above embodiment.
The memory 902 and the processor 901 are coupled by a bus, which may comprise any number of interconnected buses and bridges that interconnect one or more of the various circuits of the processor 901 and the memory 902. The bus may also connect various other circuits such as peripherals, voltage regulators, power management circuits, etc., which are well known in the art, and therefore, will not be described any further herein. A bus interface provides an interface between the bus and the transceiver. The transceiver may be one element or a plurality of elements, such as a plurality of receivers and transmitters, providing a means for communicating with various other apparatus over a transmission medium. The data processed by the processor 901 is transmitted over a wireless medium via an antenna, which further receives the data and transmits the data to the processor 901.
The processor 901 is responsible for managing the bus and general processing and may also provide various functions including timing, peripheral interfaces, voltage regulation, power management, and other control functions. And memory 902 may be used for storing data used by processor 901 in performing operations.
An embodiment of the present application further provides a computer-readable storage medium storing a computer program. The computer program realizes the above-described method embodiments when executed by a processor.
That is, as can be understood by those skilled in the art, all or part of the steps in the method for implementing the embodiments described above may be implemented by a program instructing related hardware, where the program is stored in a storage medium and includes several instructions to enable a device (which may be a single chip, a chip, or the like) or a processor (processor) to execute all or part of the steps of the method described in the embodiments of the present application. And the aforementioned storage medium includes: a U-disk, a removable hard disk, a Read-Only Memory (ROM), a Random Access Memory (RAM), a magnetic disk, or an optical disk, and various media capable of storing program codes.
It will be understood by those of ordinary skill in the art that the foregoing embodiments are specific examples for carrying out the invention, and that various changes in form and details may be made therein without departing from the spirit and scope of the invention in practice.
Claims (10)
1. A kernel thread protection method, wherein the kernel thread at least comprises: a first thread and a second thread, the method comprising:
executing work to be protected through the first thread;
monitoring the second thread through the first thread, and monitoring the first thread through the second thread;
and if the first thread is monitored to be abnormal or the second thread is monitored to be abnormal, intercepting the memory read-write operation during the execution of the work to be protected.
2. The kernel thread protection method according to claim 1, wherein in a case where the working codes executed by the first thread and the second thread are stored in a read-only code section of a kernel space, said monitoring the second thread by the first thread and monitoring the first thread by the second thread comprises:
acquiring a first address interval of a working code executed by the first thread in the kernel space, and acquiring a second address interval of a working code executed by the second thread in the kernel space;
checking the working code executed by the first thread and the working code executed by the second thread according to the content of the first address interval and the content of the second address interval to obtain a first checking result corresponding to the first thread and a second checking result corresponding to the second thread;
monitoring whether a working code executed by the first thread is tampered or not according to the first verification result and a first standard verification result corresponding to the first thread;
and monitoring whether the working code executed by the second thread is tampered or not according to the second check result and a second standard check result corresponding to the second thread.
3. The method according to claim 2, further comprising, before the obtaining the first address interval of the working code executed by the first thread in the kernel space and obtaining the second address interval of the working code executed by the second thread in the kernel space:
intercepting a target SMC instruction sent from the Normal World to the Secure World; wherein the target SMC instruction is used for detecting whether the work code is tampered.
4. The kernel thread protection method according to claim 1, wherein the monitoring the second thread by the first thread and the monitoring the first thread by the second thread comprises:
monitoring the running state of the second thread through the first thread, and determining whether the running state of the second thread is a death state or a permanent suspension state;
and monitoring the running state of the first thread through the second thread, and determining whether the running state of the first thread is a dead state or a permanent suspension state.
5. The method according to claim 4, wherein the monitoring the running state of the second thread by the first thread to determine whether the running state of the second thread is a dead state or a permanent suspension state comprises:
detecting whether a first pointer of a task _ struct type created by the first thread is a valid pointer; wherein the first pointer points to a first task _ struct structure of the second thread;
detecting a value of a state variable of the first task _ struct structure under the condition that the first pointer is an effective pointer;
determining that the running state of the second thread is a death state under the condition that the value of the state variable of the first task _ struct structure body is a preset first-class value;
determining that the running state of the second thread is an uninterruptible suspended state under the condition that the value of the state variable of the first task _ struct structure is a preset second type value, and determining that the running state of the second thread is a permanent suspended state when the duration of the uninterruptible suspended state of the running state of the second thread exceeds a preset duration;
the monitoring, by the second thread, the running state of the first thread to determine whether the running state of the first thread is a dead state or a permanent suspension state includes:
detecting whether a second pointer of a task _ struct type created by the second thread is a valid pointer; wherein the second pointer points to a second task _ struct structure of the first thread;
detecting a value of a state variable of the second task _ struct structure under the condition that the second pointer is an effective pointer;
determining that the running state of the first thread is a death state under the condition that the value of the state variable of the second task _ struct structure is a preset first-class value;
and when the duration of the state variable of the second task _ struct structure body is longer than the preset duration, determining that the running state of the first thread is in a permanent suspension state.
6. The kernel thread protection method according to claim 1, wherein the operation mode of the first thread when performing the operation to be protected includes: a kernel execution mode, a TEE execution mode and a hybrid execution mode;
in the kernel execution mode, work code executed by the first thread is written into the first thread;
in the TEE execution mode, the working code executed by the first thread is written into a trusted application TA created in the Secure World, and the first thread executes the working code by calling the TA;
in the mixed execution mode, a first working code executed by the first thread is written into the first thread, a second working code executed by the first thread is written into a trusted application TA created in a Secure World, and the first thread executes the second working code by calling the TA.
7. A method for kernel thread protection according to any one of claims 1 to 6 wherein the second thread comprises: the monitoring of the second thread by the first thread and the monitoring of the first thread by the second thread include:
and monitoring the first monitoring thread through the first thread, monitoring the second monitoring thread through the first monitoring thread, and monitoring the first thread through the second monitoring thread.
8. The method according to any one of claims 1 to 6, wherein intercepting the memory read-write operation while executing the work to be protected includes:
calling a TrustZone address space control component in a monitoring Mode Monitor Mode of the Secure World Security World, and intercepting the memory read-write operation when the work to be protected is executed.
9. A terminal, comprising: at least one processor; and (c) a second step of,
a memory communicatively coupled to the at least one processor; wherein, the first and the second end of the pipe are connected with each other,
the memory stores instructions executable by the at least one processor to enable the at least one processor to perform the method of kernel thread protection as claimed in any one of claims 1 to 8.
10. A computer-readable storage medium, storing a computer program, wherein the computer program, when executed by a processor, implements the method for kernel thread protection of any one of claims 1 to 8.
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202111022540.6A CN115729771A (en) | 2021-09-01 | 2021-09-01 | Kernel thread protection method, terminal and computer readable storage medium |
| PCT/CN2022/108692 WO2023029835A1 (en) | 2021-09-01 | 2022-07-28 | Method for protecting kernel thread, and terminal and computer readable storage medium |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202111022540.6A CN115729771A (en) | 2021-09-01 | 2021-09-01 | Kernel thread protection method, terminal and computer readable storage medium |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN115729771A true CN115729771A (en) | 2023-03-03 |
Family
ID=85292186
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202111022540.6A Pending CN115729771A (en) | 2021-09-01 | 2021-09-01 | Kernel thread protection method, terminal and computer readable storage medium |
Country Status (2)
| Country | Link |
|---|---|
| CN (1) | CN115729771A (en) |
| WO (1) | WO2023029835A1 (en) |
Family Cites Families (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US9305167B2 (en) * | 2014-05-21 | 2016-04-05 | Bitdefender IPR Management Ltd. | Hardware-enabled prevention of code reuse attacks |
| CN106933658A (en) * | 2015-12-29 | 2017-07-07 | 北京明朝万达科技股份有限公司 | The method and apparatus of the anti-kill of background process in a kind of operating system |
| CN106201690A (en) * | 2016-07-07 | 2016-12-07 | 乐视控股（北京）有限公司 | Application progress control method and device |
| CN106599690A (en) * | 2016-12-21 | 2017-04-26 | 哈尔滨安天科技股份有限公司 | Method and system for managing and controlling mobile medium access authority in domestic operating system |
-
2021
- 2021-09-01 CN CN202111022540.6A patent/CN115729771A/en active Pending
-
2022
- 2022-07-28 WO PCT/CN2022/108692 patent/WO2023029835A1/en unknown
Also Published As
| Publication number | Publication date |
|---|---|
| WO2023029835A1 (en) | 2023-03-09 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN109918916B (en) | Dual-system trusted computing system and method | |
| US8621628B2 (en) | Protecting user mode processes from improper tampering or termination | |
| JP6706273B2 (en) | Behavioral Malware Detection Using Interpreted Virtual Machines | |
| EP3391274B1 (en) | Dual memory introspection for securing multiple network endpoints | |
| RU2698776C2 (en) | Method of maintaining database and corresponding server | |
| RU2522019C1 (en) | System and method of detecting threat in code executed by virtual machine | |
| US11438349B2 (en) | Systems and methods for protecting devices from malware | |
| US10984096B2 (en) | Systems, methods, and apparatus for detecting control flow attacks | |
| JP2018524756A (en) | System and method for tracking malicious behavior across multiple software entities | |
| CN111353162B (en) | TrustZone kernel-based asynchronous execution active trusted computing method and system | |
| US20210303658A1 (en) | Hardware-Assisted System and Method for Detecting and Analyzing System Calls Made to an Operating System Kernel | |
| Yamauchi et al. | Additional kernel observer to prevent privilege escalation attacks by focusing on system call privilege changes | |
| CN115879099A (en) | DCS controller, operation processing method and protection subsystem | |
| WO2014004212A1 (en) | Timer for hardware protection of virtual machine monitor runtime integrity watcher | |
| CN115729771A (en) | Kernel thread protection method, terminal and computer readable storage medium | |
| WO2017131679A1 (en) | System management mode test operations | |
| CN111480160B (en) | System, method, and medium for process verification | |
| CN110008001B (en) | Security reinforcement method and system for virtual machine monitor and hardware security monitoring card | |
| CN113821790A (en) | Industrial credible computing dual-system architecture implementation method based on Trustzone | |
| Atamli et al. | IO-Trust: an out-of-band trusted memory acquisition for intrusion detection and forensics investigations in cloud IOMMU based systems | |
| CN112269995A (en) | Trusted computing platform for parallel computing and protection of smart power grid environment | |
| CN112269996A (en) | Dynamic measurement method of block chain main node-oriented active immune trusted computing platform | |
| Ling et al. | Prison Break of Android Reflection Restriction and Defense | |
| Liao et al. | A stack-based lightweight approach to detect kernel-level rookits | |
| Moula et al. | ROPK++: an enhanced ROP attack detection framework for Linux operating system |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication |