CN107066311B - Kernel data access control method and system - Google Patents
Kernel data access control method and system Download PDFInfo
- Publication number
- CN107066311B CN107066311B CN201710165162.4A CN201710165162A CN107066311B CN 107066311 B CN107066311 B CN 107066311B CN 201710165162 A CN201710165162 A CN 201710165162A CN 107066311 B CN107066311 B CN 107066311B
- Authority
- CN
- China
- Prior art keywords
- module
- address
- kernel
- instruction
- list
- 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.)
- Active
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
- G06F9/45533—Hypervisors; Virtual machine monitors
- G06F9/45558—Hypervisor-specific management and integration aspects
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
- G06F21/55—Detecting local intrusion or implementing counter-measures
- G06F21/56—Computer malware detection or handling, e.g. anti-virus arrangements
- G06F21/566—Dynamic detection, i.e. detection performed at run-time, e.g. emulation, suspicious activities
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
- G06F9/45533—Hypervisors; Virtual machine monitors
- G06F9/45558—Hypervisor-specific management and integration aspects
- G06F2009/45587—Isolation or security of virtual machine instances
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F2221/2141—Access rights, e.g. capability lists, access control lists, access tables, access matrices
Abstract
The invention discloses a kernel data access control method and a kernel data access control system. The method comprises the following steps: 1) establishing a protection list for recording an address area of kernel data needing to be protected; establishing a module list for recording the credible kernel module; 2) storing an address interval corresponding to the code segment which stores the kernel data to be protected and is allowed to be modified into a core method module; the address interval corresponding to the code segment is called a trusted code area; 3) the core method module judges whether the received instruction is legal or not; when the data address of the instruction operation is an address in a protection list, if the instruction is an instruction sent by a module in a module list and the address of the instruction belongs to the trusted code area, the instruction is legal, otherwise, the instruction is illegal; 4) the exception handling module determines whether to execute the instruction according to the judgment result of the core method module, and if the instruction is legal, the instruction is allowed to be executed; otherwise execution is prevented. The method improves the safety and reliability of the operating system.
Description
Technical Field
The invention relates to a kernel data access control method and a kernel data access control system, in particular to a kernel data access control method and a kernel data access control system based on a module white list, and belongs to the field of computer operating system security.
Background
With the development of hacker technology, trojan poses a huge threat to the security of an operating system. The Trojan horse can delete the appointed process or module structure from the process list or the module list by means of DKOM attack, so that the purpose of hiding the malicious process or module is achieved. In other types of DKOM attacks, trojans modify the system call table or the interrupt descriptor table, replacing the normal system call service routine or the interrupt service routine address with a malicious function address. The Trojan horse can also replace the user certificate of the process with the certificate of the super user, so that the authority of the malicious process is improved.
Many current inventions employ virtual machine monitors to protect operating systems from trojan attacks. Virtual machine introspection techniques can be used to detect trojans, but virtual machine introspection detection assumes that kernel data is not modified by trojans, so virtual machine introspection cannot detect DKOM attacks. Some inventions provide methods for detecting DKOM attacks, but detection capabilities are not complete. PatchGuard protects read-only kernel data such as system service descriptor tables and interrupt descriptor tables. UCONKI proposes an access control method for kernel read-only data. And the DKOM can attack kernel non-read-only data, such as processes and module structures. The data can be modified by normal kernel code or Trojan horse.
The Sentry architecture protects kernel data through a designed access control method, but if a trojan is a Loadable Kernel Module (LKM) type trojan (LKM trojan is the most common type of trojan), and an attack code is placed in an LKM initialization code segment (i.e., a module initialization function), Sentry cannot detect the attack code. Because Sentry assumes that the init text code fragment is trusted, while the initialization code of LKM will be placed in the init text code fragment for execution.
Disclosure of Invention
The technical problems solved by the invention are as follows: a kernel data access control method is provided and implemented as a system named Hypro. By using the method, DKOM and system call hijack attacks can be detected. In particular, if the LKM trojan places an attack code in the module initialization code segment, Hypro may reject trojan attacks through the suspicious behavior kernel module tracking algorithm in combination with the module white list.
The technical scheme of the invention is as follows:
a kernel data access control method comprises the following steps:
1) establishing a protection list for recording an address area of kernel data needing to be protected; establishing a module list for recording a credible kernel module, namely allowing the module in the module list to modify the kernel data to be protected;
2) storing an address interval corresponding to the code segment which stores the kernel data to be protected and is allowed to be modified into a core method module; the address interval corresponding to the code segment is called a trusted code area;
3) the core method module judges whether the received instruction is legal or not; when the data address of the instruction operation is the address recorded in the protection list, if the instruction is the instruction sent by the module in the module list and the address of the instruction belongs to the trusted code area, the instruction is legal, otherwise, the instruction is illegal;
4) the exception handling module determines whether to allow the instruction to be executed according to the judgment result of the core method module, and if the instruction is legal, the instruction is allowed to be executed; otherwise, execution of the instruction is prevented.
Further, the trusted code area includes: the address interval corresponding to the kernel core code segment, the address interval corresponding to the core code required by kernel startup and the address interval corresponding to the code for initializing the LKM.
Furthermore, the protection list is an array structure formed by a group of { start _ address, end _ address } elements; wherein, start _ address and end _ address are the start address and the end address of the kernel structure.
Further, the kernel data to be protected is Linux kernel data, and the trusted code region and the address region for protecting the kernel data are obtained by querying a system.
Further, the module list is composed of a kernel module structure body, and records the currently loaded module of the kernel.
Further, when the core method module judges that the instruction is illegal, the exception handling module calls a suspicious behavior kernel module to track the module which sends the instruction by a tracking algorithm; the suspicious behavior kernel module tracking algorithm comprises the following steps: firstly, adding the address of the do _ one _ initial function into a parameter list of the do _ one _ initial function as a second parameter, wherein the first parameter is the address of the module initialization function; reading an ebp register of a client operating system to obtain a base address of a current stack frame; then, comparing the address of the do _ one _ initcall function with the second parameter, and judging whether a stack frame of the do _ one _ initcall function is reached; if the stack frame of the do _ one _ initialization function is reached, storing the address of the LKM initialization function in a first parameter; and then, inquiring in the entry _ name _ map function by using the address of the module initialization function to obtain the module name, and returning.
A kernel data access control system is characterized by comprising a core method module, a protection list, a module list and an exception handling module; wherein the content of the first and second substances,
the protection list is used for recording the address area of the kernel data to be protected;
the module list is used for recording the credible kernel module, namely the module in the module list allows the kernel data to be protected to be modified;
the core method module is used for storing an address interval corresponding to a code segment which allows the kernel data to be protected to be modified, and the address interval corresponding to the code segment is called a trusted code area; judging whether the received instruction is legal or not, if the data address of the instruction operation is the address recorded in the protection list, if the instruction is the instruction sent by the module in the module list and the address of the instruction belongs to the trusted code area, judging that the instruction is legal, otherwise, judging that the instruction is illegal;
the exception handling module is used for determining whether to allow the instruction to be executed according to the judgment result of the core method module, and if the instruction is legal, the instruction is allowed to be executed; otherwise, execution of the instruction is prevented.
Compared with the prior art, the invention has the advantages that:
(1) the kernel data is protected based on the virtual machine monitor, the virtual machine monitor runs between hardware and an operating system and has higher authority than the kernel of the operating system, and the safety scheme designed based on the virtual machine monitor has higher safety and reliability than the safety scheme at the level of the operating system.
(2) The kernel data access control method and system based on the module white list can effectively distinguish whether the access to the kernel dynamic data is legal or not, and isolate illegal access by virtue of the virtual machine monitor.
(3) According to the method, the LKM trojans can be positioned through a suspicious behavior kernel module tracking algorithm, and the existing other Trojan horse detection technologies cannot detect the LKM trojans with attack codes placed in the initialization process. Aiming at a write operation request initiated by LKM, the invention uses a suspicious behavior kernel module tracking algorithm to position the module, and judges whether the write request is legal or not by combining a module white list.
Drawings
FIG. 1 is an overall design implementation of the present invention;
FIG. 2 is a flow chart of exception handling according to the present invention;
FIG. 3 is a flowchart of the suspicious behavior kernel module tracking algorithm of the present invention.
Detailed Description
Specifically, the technical scheme adopted by the invention is as follows:
the Hypro runs in the virtual machine monitor, intercepts the write operation request of the guest operating system to the protected area, and controls and forwards the request. The Hypro system is generally divided into four parts: the system comprises a core method module, a protection list, a module list and an exception handling module. The system architecture is shown in fig. 1.
The core method module determines which code sections with address intervals, called trusted code areas in Hypro, allow modification of kernel protected data. If the write to the kernel protected data is from the untrusted region of code, the write will be blocked. The trusted code region is defined as follows:
the kernel core code segment has the authority of modifying kernel data managed by the kernel core code segment, is a part of the kernel code segment, and ranges from _ text to _ etext in a Linux operating system. Map file can find the virtual address of text and text;
in the Linux operating system kernel, a code segment ranging from __ init _ begin to __ init _ end contains core codes necessary for kernel starting, and the code segment is credible;
③ in the Linux operating system kernel, if the code segment is in the range of __ inical 7_ start to __ initecall 8_ start (the area contains the code for initializing the LKM), the method can obtain the information of the LKM according to the suspicious behavior kernel module tracking algorithm provided by the invention. And if the LKM is in the module white list and the code segment is credible, allowing the kernel protected data to be modified, otherwise, judging the code segment to be credible and rejecting access.
The Hypro method is only applicable to Linux kernels, and the addresses of __ init _ begin, __ init _ end, __ inicall7_ start and __ initcall8_ start can be queried in system.
Protection list:
the protection list contains kernel data to be protected, in Hypro, the kernel data protection granularity is a kernel structure, and the protection list is an array structure composed of a set of { start _ address, end _ address } elements. The start _ address and the end _ address give a start address and an end address of a kernel structure to be protected, both are in a client virtual address format, and the start _ address and the end _ address are queried through a system. The protection list can be dynamically modified, and after the system is started, a user can put objects needing protection into the protection list.
Which kernel data needs to be protected depends on the way the trojan attacks. Some trojans remove specific processes and modules from the process and module lists by modifying the pointing of the prev and next pointers in the process and module structs, so the prev and next pointers of the process and module structs can be added to the protection list. Some trojans change the addresses of the system call service and the interrupt service by modifying the system call table and the interrupt descriptor table so that the system call table and the interrupt descriptor table can be added to the protection list. The user may add more security sensitive kernel data to the protection list.
Module list:
the module list contains trusted kernel modules, i.e. the modules in the module list allow modification of kernel protection data, and the module list is an array structure formed by a group of elements in the shape of { module 1, module 2. For example, Adore-ng is a typical LKM trojan horse that, when loaded, modifies the prev and next pointers in the kernel module structure, hiding them from the user's perception, the kernel module list consisting of the kernel module structure, recording the modules currently loaded by the kernel. If prev and next pointers in the module structure are added to the protection list, when Adore-ng modifies these pointers, the suspicious behavior kernel module tracking algorithm finds that Adore-ng is modifying kernel protection data, and that Adore-ng is not in the protection list, so the modification operation of Adore-ng is rejected. After the Linux operating system is started, an lsmod command is operated, an obtained module list is added into a module white list to serve as an initial module white list, and the module white list is of a linear linked list structure, so that the module white list can be dynamically modified after the system is started: each time a module is loaded, it may be added to the module whitelist.
An exception handling module:
if the core method module of the Hypro judges that the write operation request to the kernel protection area is legal according to the three criteria defined by the trusted code area, the exception handling module completes the legal write operation. If the verification result is illegal, the exception handling module rejects the write request, sends a warning to a client operating system and unloads a corresponding Trojan.
The exception handling module realizes the following modes:
the exception handling module relies on the Intel VT-X virtualization framework. In the Intel VT-X framework, Extended Page Table (EPT) is used to translate guest physical addresses to host physical addresses, and the last three bits in Page Table Entry (PTE) in the EPT structure control the read, write and execute permissions of the Page Table. The protection granularity of the memory in the EPT mechanism is a page table. Hypro converts the address range in the protection list into a Page table number list (PFNL for short) by calculating the Page table number to which the guest virtual address belongs. And sets the page tables in the PFNL all read-only.
The exception handling module is shown in fig. 2. The EXIT _ response records the REASON for causing the VM EXIT event, and there are two cases for causing the EPT _ view: the first case is that there is no mapping of guest-physical addresses to host-physical addresses to be accessed in the EPT structure, when the map _ EPT _ address function is executed to ensure that the mapping exists; the second case is when the EPT page table is accessed by an unauthorized access, such as writing a read-only page table. When the EPT page table is subjected to unauthorized access, whether the write request is legal or not is judged through a core method module of Hypro. If the write request is legal, the page table is reset as writable and the CPU is put into the single-step state, because the page table authority is set as writable, the write operation is executed. If the write request is illegal, a warning is sent to a client operating system, and a module which sends the illegal write request is found out through a suspicious behavior kernel module tracking algorithm and is unloaded. If a single step exception occurs and is caused by Hypro, the accessed page table is reset to read-only and single step debugging is halted. If the single-step exception is caused by another guest, such as debug, then control is transferred to the guest operating system.
The suspicious behavior kernel module tracking algorithm implementation mode comprises the following steps:
if the LKM initiates a write request to the protected area and causes EPT _ VIOLATION, the LKM module causing the suspicious behavior needs to be captured by a suspicious behavior kernel module tracking algorithm. The algorithm traverses the kernel call stack of the guest operating system starting with the function that triggered the EPT _ VIOLATION until a function is found for which the kernel initializes the module. In order to execute the suspicious behavior kernel module tracing algorithm, the kernel of the guest operating system needs to add an option of maintaining a call stack when compiling. When a suspicious behavior kernel module tracing algorithm is executed, the kernel of the guest operating system needs to be suspended so as to keep the consistency of a guest operating system stack frame page table.
The suspicious behavior kernel module tracking algorithm provided by the invention utilizes a mechanism of initializing LKM by a Linux kernel. The Linux kernel initializes the LKM by calling a do _ one _ initcall function, the parameter of the do _ one _ initcall function is the address of the module initialization function, and the do _ one _ initcall function body calls the module initialization function. In order to determine whether the do _ one _ initcall function is traversed or not, the suspicious behavior kernel module tracking algorithm needs to add the address of the do _ one _ initcall to the parameter list of the do _ one _ initcall function as a second parameter of the do _ one _ initcall function. The address of do _ one _ initcall can be looked up in system. The algorithm reads the ebp register of the guest operating system to obtain the base address of the current stack frame. The first parameter of the function corresponding to the current stack frame is stored in the memory pointed by ebp +8, the second parameter is stored in the memory pointed by ebp +12, and the address of the previous stack frame is stored in the memory pointed by ebp. Whether a stack frame of do _ one _ initcall is reached is determined by comparing the address of do _ one _ initcall with the second parameter of the function (the first parameter is the address of the module initialization function). If so, the address of the LKM module initialization function is stored in the first parameter value. The entry _ name _ map records the mapping from the module initialization function address to the module name, the module initialization function address and the module initialization function name are both stored in the module structure, and when the module is loaded by the kernel, the two fields are stored in the entry _ name _ map structure. And querying the entry _ name _ map by using the module initialization function address (argu1) to obtain a module name, and returning.
The invention has not been described in detail and is part of the common general knowledge of a person skilled in the art.
The above description is only an embodiment of the present invention, but the scope of the present invention is not limited thereto, and any person skilled in the art can understand that the modifications or substitutions within the technical scope of the present invention are included in the scope of the present invention, and therefore, the scope of the present invention should be subject to the protection scope of the claims.
Claims (9)
1. A kernel data access control method comprises the following steps:
1) establishing a protection list for recording an address area of kernel data needing to be protected; establishing a module list for recording a credible kernel module, namely allowing the module in the module list to modify the kernel data to be protected;
2) storing an address interval corresponding to the code segment which allows the kernel data to be protected to be modified into a core method module; the address interval corresponding to the code segment is called a trusted code area;
3) the core method module judges whether the received instruction is legal or not; when the data address of the instruction operation is the address recorded in the protection list, if the instruction is the instruction sent by the module in the module list and the address of the instruction belongs to the trusted code area, the instruction is legal, otherwise, the instruction is illegal;
4) the exception handling module determines whether to allow the instruction to be executed according to the judgment result of the core method module, and if the instruction is legal, the instruction is allowed to be executed; otherwise, stopping executing the instruction, and calling a suspicious behavior kernel module tracking algorithm to track the module which sends the instruction; the suspicious behavior kernel module tracking algorithm comprises the following steps: firstly, adding the address of the do _ one _ initial function into a parameter list of the do _ one _ initial function as a second parameter, wherein the first parameter is the address of the module initialization function; reading an ebp register of a client operating system to obtain a base address of a current stack frame; then, comparing the address of the do _ one _ initcall function with the second parameter, and judging whether a stack frame of the do _ one _ initcall function is reached; if the stack frame of the do _ one _ initialization function is reached, storing the address of the LKM initialization function in a first parameter; and then, inquiring in the entry _ name _ map function by using the address of the module initialization function to obtain the module name, and returning.
2. The method of claim 1, wherein the trusted code region comprises: the address interval corresponding to the kernel core code segment, the address interval corresponding to the core code required by kernel startup and the address interval corresponding to the code for initializing the LKM.
3. The method of claim 1, wherein the protection list is an array structure consisting of a set of { start address, end address } elements; wherein, start _ address and end _ address are the start address and the end address of the kernel structure.
4. The method of claim 1, 2 or 3, wherein the kernel data to be protected is Linux kernel data, and the trusted code region and the address region of the protected kernel data are obtained by querying a system.
5. The method of claim 1, wherein the module list is comprised of a kernel module structure, and records the modules currently loaded by the kernel.
6. A kernel data access control system is characterized by comprising a core method module, a protection list, a module list and an exception handling module; wherein the content of the first and second substances,
the protection list is used for recording the address area of the kernel data to be protected;
the module list is used for recording the credible kernel module, namely the module in the module list allows the kernel data to be protected to be modified;
the core method module is used for storing an address interval corresponding to a code segment which allows the kernel data to be protected to be modified, and the address interval corresponding to the code segment is called a trusted code area; judging whether the received instruction is legal or not, if the data address of the instruction operation is the address recorded in the protection list, if the instruction is the instruction sent by the module in the module list and the address of the instruction belongs to the trusted code area, judging that the instruction is legal, otherwise, judging that the instruction is illegal;
the exception handling module is used for determining whether to allow the instruction to be executed according to the judgment result of the core method module, and if the instruction is legal, the instruction is allowed to be executed; otherwise, stopping executing the instruction, and calling a suspicious behavior kernel module tracking algorithm to track the module which sends the instruction; the suspicious behavior kernel module tracking algorithm comprises the following steps: firstly, adding the address of the do _ one _ initial function into a parameter list of the do _ one _ initial function as a second parameter, wherein the first parameter is the address of the module initialization function; reading an ebp register of a client operating system to obtain a base address of a current stack frame; then, comparing the address of the do _ one _ initcall function with the second parameter, and judging whether a stack frame of the do _ one _ initcall function is reached; if the stack frame of the do _ one _ initialization function is reached, storing the address of the LKM initialization function in a first parameter; and then, inquiring in the entry _ name _ map function by using the address of the module initialization function to obtain the module name, and returning.
7. The system of claim 6, wherein the trusted code region comprises: the address interval corresponding to the kernel core code segment, the address interval corresponding to the core code required by kernel startup and the address interval corresponding to the code for initializing the LKM.
8. The system of claim 6, wherein the protection list is an array structure consisting of a set of { start address, end address } elements; wherein, start _ address and end _ address are the initial address and the end address of the kernel structure; the module list is composed of a kernel module structure body and records the modules loaded by the kernel currently.
9. The system of claim 6 or 7 or 8, wherein the kernel data to be protected is Linux kernel data, and the trusted code region and the address region of the protection kernel data are obtained by querying a system.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201710165162.4A CN107066311B (en) | 2017-03-20 | 2017-03-20 | Kernel data access control method and system |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201710165162.4A CN107066311B (en) | 2017-03-20 | 2017-03-20 | Kernel data access control method and system |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN107066311A CN107066311A (en) | 2017-08-18 |
| CN107066311B true CN107066311B (en) | 2020-11-20 |
Family
ID=59620677
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201710165162.4A Active CN107066311B (en) | 2017-03-20 | 2017-03-20 | Kernel data access control method and system |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN107066311B (en) |
Families Citing this family (14)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN107608905B (en) | 2017-09-11 | 2020-05-12 | 杭州中天微系统有限公司 | Method and device for erasing Flash data |
| CN109543400B (en) * | 2017-09-21 | 2022-08-09 | 华为技术有限公司 | Method and equipment for dynamically managing kernel nodes |
| CN108958649B (en) * | 2018-05-17 | 2021-03-23 | 天津飞腾信息技术有限公司 | Security isolation method and device for storage system |
| CN110598405B (en) * | 2018-06-12 | 2022-05-31 | 杨力祥 | Runtime access control method and computing device |
| CN109120618B (en) * | 2018-08-17 | 2021-10-22 | 武汉大学 | Cloud platform controlled side channel attack detection method based on hardware virtualization |
| CN109446755B (en) * | 2018-09-30 | 2021-03-30 | 龙芯中科技术股份有限公司 | Kernel hook function protection method, device, equipment and storage medium |
| CN111382429B (en) * | 2018-12-27 | 2022-12-27 | 华为技术有限公司 | Instruction execution method and device and storage medium |
| CN110598445B (en) * | 2019-09-12 | 2022-05-20 | 金蝶蝶金云计算有限公司 | Database access control method, system and related equipment |
| CN111027072B (en) * | 2019-12-20 | 2024-02-27 | 北京安天网络安全技术有限公司 | Kernel Rootkit detection method and device based on elf binary standard analysis under Linux |
| CN111400702B (en) * | 2020-03-24 | 2023-06-27 | 上海瓶钵信息科技有限公司 | Virtualized operating system kernel protection method |
| CN111949252B (en) * | 2020-07-23 | 2023-09-08 | 网易（杭州）网络有限公司 | Data processing method and device and electronic equipment |
| CN114519186A (en) * | 2020-11-20 | 2022-05-20 | 华为技术有限公司 | Data protection method and device, storage medium and computer equipment |
| CN112347432B (en) * | 2020-11-24 | 2021-10-12 | 广芯微电子（广州）股份有限公司 | Program protection method and system in embedded processor based on RISC-V architecture |
| CN114138362B (en) * | 2021-11-18 | 2024-03-01 | 武汉深之度科技有限公司 | Anti-unloading method and device for kernel module and computing equipment |
Citations (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20090288167A1 (en) * | 2008-05-19 | 2009-11-19 | Authentium, Inc. | Secure virtualization system software |
| CN102194080A (en) * | 2011-06-13 | 2011-09-21 | 西安交通大学 | Rootkit detection mechanism and detection method based on kernel-based virtual machine |
| CN103699839A (en) * | 2013-12-09 | 2014-04-02 | Tcl集团股份有限公司 | Method and device of detection processing of core-level rootkit |
| CN103886259A (en) * | 2014-03-19 | 2014-06-25 | 四川大学 | Kernel-level rootkit detecting and processing method based on Xen virtualization environment |
| CN103907101A (en) * | 2011-10-13 | 2014-07-02 | 迈克菲公司 | System and method for kernel ROOTKIT protection in a hypervisor environment |
| CN104598823A (en) * | 2015-01-21 | 2015-05-06 | 华东师范大学 | Kernel level rootkit detection method and system in Andriod system |
| CN106203108A (en) * | 2016-06-29 | 2016-12-07 | 北京市国路安信息技术股份有限公司 | Linux white list system protection method based on kernel module and device |
| US20170004302A1 (en) * | 2015-06-30 | 2017-01-05 | Emc Corporation | Method and system for malware detection in virtual machines |
-
2017
- 2017-03-20 CN CN201710165162.4A patent/CN107066311B/en active Active
Patent Citations (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20090288167A1 (en) * | 2008-05-19 | 2009-11-19 | Authentium, Inc. | Secure virtualization system software |
| CN102194080A (en) * | 2011-06-13 | 2011-09-21 | 西安交通大学 | Rootkit detection mechanism and detection method based on kernel-based virtual machine |
| CN103907101A (en) * | 2011-10-13 | 2014-07-02 | 迈克菲公司 | System and method for kernel ROOTKIT protection in a hypervisor environment |
| CN103699839A (en) * | 2013-12-09 | 2014-04-02 | Tcl集团股份有限公司 | Method and device of detection processing of core-level rootkit |
| CN103886259A (en) * | 2014-03-19 | 2014-06-25 | 四川大学 | Kernel-level rootkit detecting and processing method based on Xen virtualization environment |
| CN104598823A (en) * | 2015-01-21 | 2015-05-06 | 华东师范大学 | Kernel level rootkit detection method and system in Andriod system |
| US20170004302A1 (en) * | 2015-06-30 | 2017-01-05 | Emc Corporation | Method and system for malware detection in virtual machines |
| CN106203108A (en) * | 2016-06-29 | 2016-12-07 | 北京市国路安信息技术股份有限公司 | Linux white list system protection method based on kernel module and device |
Also Published As
| Publication number | Publication date |
|---|---|
| CN107066311A (en) | 2017-08-18 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN107066311B (en) | Kernel data access control method and system | |
| CA2990343C (en) | Computer security systems and methods using asynchronous introspection exceptions | |
| US10073986B2 (en) | Regulating access to and protecting portions of applications of virtual machines | |
| US9275225B2 (en) | Linear address mapping protection | |
| KR101946982B1 (en) | Process Evaluation for Malware Detection in Virtual Machines | |
| US9361471B2 (en) | Secure vault service for software components within an execution environment | |
| KR102189296B1 (en) | Event filtering for virtual machine security applications | |
| US20120216281A1 (en) | Systems and Methods for Providing a Computing Device Having a Secure Operating System Kernel | |
| CN110383256B (en) | Kernel integrity protection method and device | |
| JP2010517164A (en) | Protect operating system resources | |
| US10114948B2 (en) | Hypervisor-based buffer overflow detection and prevention | |
| WO2020114262A1 (en) | Kernel security detection method, apparatus, and device, and storage medium | |
| KR102494167B1 (en) | A Electronic Device And Method For Protecting The Kernel Space of the Memory | |
| US20230289465A1 (en) | Data Protection Method and Apparatus, Storage Medium, and Computer Device | |
| KR102161770B1 (en) | System and method for obtaining memory information | |
| Suzaki et al. | Kernel memory protection by an insertable hypervisor which has VM introspection and stealth breakpoints | |
| Wang et al. | Hacs: A hypervisor-based access control strategy to protect security-critical kernel data | |
| WO2013074071A1 (en) | Regulating access to and protecting portions of applications of virtual machines |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |