KR102183648B1 - Method and apparatus for protecting kernel without nested paging - Google Patents

Abstract

A method and apparatus for protecting a kernel without overlapping paging are disclosed. It includes a memory bus monitoring value that monitors a system bus and a memory including a security area in which the user application and the kernel cannot access and is accessible by the hypervisor, and detects write events for the monitoring area in the memory.

Description

Method and apparatus for protecting kernel without nested paging TECHNICAL FIELD

The present invention relates to a kernel protection method and apparatus, and more particularly, to a method and apparatus for protecting a kernel from malicious attacks without using overlapping paging.

In general, in a System on Chip (SoC), a processor, memory, and various devices are interconnected through a kind of communication channel called a system bus. When the code executed by the processor tries to write a value to the memory, the processor transmits a memory write event to the memory through the system bus, and the memory controller performs an operation according to the memory write event.

1 is a diagram illustrating an example of a conventional system architecture including overlapping paging.

Referring to FIG. 1, the conventional system architecture includes a user level 100, a kernel level 110, and a hypervisor level 120. In the ARM architecture, the privilege level is called an exception level (EL) and is classified into EL0, EL1, and EL2. The user level EL0 and the kernel level EL1 are levels used by the user application and the kernel, respectively. The hypervisor operates at level EL2.

For efficient implementation of hypervisor mode, a dedicated command that allows you to enter the hypervisor mode from the OS kernel mode (e.g., hypercall), the ability to monitor the execution of certain commands in the OS kernel (command trap), and nesting There is nested paging and the like.

For example, the virtualization extension of the ARM architecture provides several features that enable the hypervisor to operate efficiently in the EL2 120. First, the hypervisor can do instruction traps by setting the HCR-EL2 register. Using this register, the hypervisor can trap several kernel events, such as updating the Translation Table Base Resister (TTBR) register. In addition, it can support a hypercall called HVC, and by doing this, you can enter the hypervisor mode from the kernel mode. Overlapping paging is used for virtual address translation in EL0 (100) and EL1 (110). A memory management unit (MMU) supports overlapping pages to simultaneously manage two levels of the stage-1 page table 112 and the stage-2 page table 124. The stage-1 table 112, which is a page table used in the EL1 110, is used by the kernel, and is used to convert a virtual address into an intermediate physical address (IPA). The stage-2 page table 124 is used to convert the intermediate physical address converted by the stage-1 table 112 into a physical address. The EL2 page table 122 is used by the hypervisor for the virtual address of the EL2 120.

Nested paging is utilized by various kernel protection security solutions in that it allows monitoring of various memory events of the OS kernel. However, when the processor converts a virtual address into a physical address, the overlapping paging has a problem in that a performance load occurs because two page tables must be referred to.

A technical problem to be achieved by an embodiment of the present invention is to provide a method and apparatus for protecting a kernel without overlapping paging.

An example of a kernel protection method according to an embodiment of the present invention for achieving the above technical problem is that a monitoring module residing in a secure area of a memory that is accessible to a user application and a kernel and accessible to a hypervisor is performed. A kernel protection method, comprising: upon receiving a request to update a page table from a kernel, verifying the update request and updating the page table; And monitoring the update using a hypervisor mode command trap function when a system control register indicating the page table is updated.

Another example of a kernel protection method according to an embodiment of the present invention for achieving the above technical problem is, in the kernel protection method performed by a memory bus monitoring device connected to a system bus, a memory write event is transmitted through the system bus. Monitoring; Determining whether a write event for the surveillance area has occurred based on a bitmap displaying the surveillance area using bits mapped to each area of the memory divided by a predetermined size unit; And when a write event for the monitoring area occurs, storing the memory address of the write event in the secure area of the memory, and generating an interrupt.

In order to achieve the above technical problem, an example of a memory bus monitoring device for kernel protection according to an embodiment of the present invention includes: a traffic snooper that monitors a system bus and detects a memory write event; A bitmap conversion unit that determines whether a write event for the surveillance area has occurred based on the surveillance area information stored as a bitmap in the security area of the memory; And a determination unit for storing a memory address of the write event in the secure area of the memory and generating an interrupt when a write event for the monitoring area occurs.

In order to achieve the above technical problem, an example of a system capable of protecting a kernel according to an embodiment of the present invention includes a memory including a security area in which a user application and a kernel cannot access and a hypervisor can access; And a memory bus monitoring device that monitors the system bus and detects a write event for the monitoring area in the memory, wherein a monitoring module implemented as software resides in the security area of the memory, and the monitoring module is a page from the kernel. Upon receiving a table update request, the page table is updated after verifying the update request.

According to an embodiment of the present invention, it is possible to protect the kernel without overlapping paging in which a performance load occurs. Since overlapping paging operates based on the MMU (Memory Management Unit), the memory monitoring area must be designated in units of pages (4Kbytes), which are the basic units for the MMU to manage the memory. It can be specified, so that memory events with smaller units than pages (eg, 8 bytes) can be monitored more efficiently. In addition, since a separate hardware module connected to the system bus is included for memory monitoring, there is an advantage that there is no performance addition to a program running in the processor.

1 is a diagram showing an example of a system architecture including a conventional overlapping paging;
2 is a diagram illustrating an example of a framework for kernel protection according to an embodiment of the present invention;
3 is a diagram illustrating an example of a separate execution environment of a memory for kernel protection according to an embodiment of the present invention;
4 is a diagram showing an example of a kernel protection method according to an embodiment of the present invention;
5 is a diagram showing an example of a configuration of a memory bus monitoring device according to an embodiment of the present invention;
6 is a flowchart showing an example of a kernel protection method using a monitoring module according to an embodiment of the present invention;
7 is a flow chart showing another example of a kernel protection method using a monitoring module according to an embodiment of the present invention, and,
8 is a flowchart illustrating an example of a kernel protection method performed by a memory bus monitoring apparatus according to an embodiment of the present invention.

Hereinafter, a method and apparatus for protecting a kernel without overlapping pages according to an embodiment of the present invention will be described in detail with reference to the accompanying drawings.

2 is a diagram illustrating an example of a framework for protecting a kernel according to an embodiment of the present invention.

Referring to FIG. 2, for kernel protection, the memory 200 is divided into a normal space 210 accessible by an OS kernel or a user application and a secure space 220 accessible only by a hypervisor. . A monitoring module 230 and at least one security solution 250 may exist in the security area 220. As another method for protecting the kernel, the memory bus monitoring device 240, which is a hardware module, may be used. An example of a method of protecting the kernel using the monitoring module 230 is shown in FIG. 3, and an example of a method of protecting the kernel using the memory bus monitoring device 240 is shown in FIG. 4.

The monitoring module 230 may be initialized when the system is booted. For example, when the system is implemented with the ARM architecture, the monitoring module 230 sets the EL2 system control register during the initialization process. Also, the monitoring module 230 creates an EL2 page table (122 in FIG. 1) to be used in the security area 220. For example, if the EL2 page table 122 uses a linear mapping strategy, the EL2 virtual address is the same as the physical address, and the stage-2 page page 124 is not required. The monitoring module 230 initializes the stack pointer register SP_EL2 for the EL2 120. The monitoring module 230 sets an exception vector of the EL2 120 so that exceptions (calling functions, traps) occurring during kernel operation can be simultaneously handled. The monitoring module 230 may activate the TVM bit of the HCR_EL2 register to trap an attempt to change a register related to the virtual memory configuration. The monitoring module 230 monitors the update of TTBR1_EL2 having a base address of the EL2 page table 122 so that the kernel can use only the valid EL1 page table 110.

In order to prevent the kernel from interfering with the EL1 page table 110, the kernel code can be changed. Also, the kernel can be changed to allocate memory blocks in units of 4KB pages rather than in units of 2MB sections. In the case of the ARM architecture, the size of each page table is 4KB, but the kernel allocates memory blocks in 2MB sections in the kernel linear region. Due to the mismatch between the size of the memory block and the page table, the memory section may contain both the page table and unrelated data. Therefore, this problem can be solved by changing the kernel to allocate the memory area in 4KB pages.

When the size of the page table and the size of the memory block match, the read-only policy for the page table page can be effectively executed without the intervention of the monitoring module 230. In addition, the kernel may be changed so that the kernel page table is changed through the monitoring module 230 instead of the kernel directly changing the page table. The monitoring module 230 verifies the write operation, and if the write request is valid, performs a write operation on behalf of the kernel. This will be described again in FIG. 3.

3 is a diagram illustrating an example of a separate execution environment of a memory for kernel protection according to an embodiment of the present invention.

Referring to FIG. 2, the memory is divided into a general area 210 and a security area 220. Access from the security area 220 to the general area 210 is possible, but access from the general area 210 to the security area 220 is impossible. Accordingly, a user application or kernel located in the general area 210 cannot access the security area 220, and the monitoring module 230 located in the security area 220 can access the general area 210.

The monitoring module 230 located in the security area 220 is a software module and resides in the security area 220 of the memory when the system is booted. The monitoring module 230 directly monitors the kernel page table, and does not use a separate overlapping paging unlike FIG. 1. In other words, a separate page table (eg, stage-2 page table 124 of FIG. 1) for mapping the memory area of the security area 220 is not generated.

In the conventional case, since the kernel manages the page table of the general area 210, there is a risk that the damaged kernel may touch the page table. For example, an attacker may attempt to access the security area 220 by changing a kernel page table that creates a mapping for the memory area of the security area 220. Therefore, in order to protect the kernel page table, in the present embodiment, the kernel code for updating the kernel page is changed to a command (hereinafter, referred to as a'call function') 310 for calling a monitoring module. Due to this change, the monitoring module 230 may update the kernel page table 350 instead of the kernel.

When the monitoring module 230 receives a kernel page update request from the kernel through the call function 310, it verifies whether the update request is a legitimate request. For example, the monitoring module 230 may verify whether the kernel page update request is a legitimate request from the kernel or an update request from a malicious third party through various conventional verification methods. In the present embodiment, various conventional methods of verifying kernel page update requests can be applied.

정책을 적용하여 커널 페이지 테이블을 위해 사용되는 메모리 영역(340)을 읽기 전용으로 설정하고, 커널이 보안 영역에 대한 메모리 영역(350)에 접근 불가능하도록 만들 수 있다. The monitoring module 230 is in the kernel page area.

By applying a policy, the memory area 340 used for the kernel page table may be set as read-only, and the kernel may make the memory area 350 for the security area inaccessible.

Privileged instruction 330 may be performed to read or update the configuration of the system. For example, the privilege command 330 may be used to change a value of a page table base register. However, an attacker may use the privileged command 330 to make an isolated execution environment impossible using the previously salpin monitoring module. In other words, an attacker may use a maliciously created page table for address translation or may disable address translation.

Accordingly, the monitoring module 230 of the present embodiment traps 320 a privileged instruction to prevent malicious execution of the privileged instruction 330. When the privileged command 330 is executed, the trap 320 is generated, and the monitoring module 230 checks whether a setting required for its normal operation is changed.

It is necessary to monitor the kernel memory region to protect kernel integrity. To this end, a conventional hypervisor-based approach uses an overlapping page in which an entry in the stage-2 page table 124 for a surveillance area is marked as read-only as shown in FIG. 1. If a permission fault is issued due to an attempt to update the surveillance area, the hypervisor intervenes to verify the validity of the memory write event. However, such overlapping paging may have overhead for page table work, and monitoring through overlapping paging may incur overhead due to a protection granularity gap problem.

As an example for solving this problem, a memory bus monitoring device (MBM, Memory Bus Monitor) implemented as hardware is included in addition to the monitoring module 230 implemented in software and residing in the security area as shown in FIG. 2. The main function of the memory bus monitoring device is to monitor a fine-grained memory region that is smaller than a page-granularity. However, such a hardware module has a problem that internal information of the processor cannot be known. For example, since the memory address to which the kernel data object is actively allocated cannot be known, it can only be used when monitoring restricted kernel objects. Moreover, since mapping information between physical and virtual addresses is not exposed to the memory bus monitoring device, it is vulnerable to an address translation relocation attack (ATRA). To solve this problem, the monitoring module 230 provides the internal state of the processor to the memory bus monitoring device.

4 is a diagram illustrating an example of a kernel protection method according to an embodiment of the present invention.

Referring to FIG. 4, a method of monitoring kernel memory using the monitoring module 230 and the memory bus monitoring device 240 is shown. In this embodiment, the security solution 250 resides in the security area 220 and informs the monitoring module 230 of the monitoring area 400 through a monitoring module call function inserted in the kernel code.

When the kernel executes the call function 410 for setting the monitoring area 400, the monitoring module 230 receives the identifier of the security solution 250 and the base address and size information of the monitoring area (①).

The monitoring module 230 converts the virtual address of the monitoring area 400 into a physical address and provides it to the memory bus monitoring bus device 240. The surveillance area 400 is expressed in word granularity through a bitmap 420 that maps a certain size of the memory (eg, 1 word (=8 bytes)) to 1 bit. The monitoring module 230 sets a bit corresponding to the monitoring area in the bitmap 420 (for example, set to '1'), and the memory bus monitoring device 240 uses the bitmap 420 to (400) can be seen (②).

In order that the memory bus monitoring device 240 can monitor all memory events for the monitoring area 400, the monitoring module 230 is a kernel page table so that a cache entry for a page including the monitoring area 400 is not generated. Change (350). Whenever a memory write event for the kernel memory area occurs (③), the memory bus monitoring device 240 checks whether a bit of a memory area corresponding to a memory event is set in the bitmap 420 (④).

If the bit is set, the memory bus monitoring device 240 stores event information (e.g., address, value) in the ring buffer (⑤), and sends a memory event to the monitoring area 400 to the monitoring module 230. An interrupt is generated to inform that a has occurred (⑥).

The monitoring module 230 fetches event information from the output buffer (⑦) and delivers the event information to the security solution 250 (⑧). Since all the memory areas used by the memory bus monitoring device 240 such as the ring buffer and the bitmap 420 are located in the security area, the kernel cannot damage the operation of the memory bus monitoring device 240.

5 is a diagram illustrating an example of a configuration of a memory bus monitoring apparatus according to an embodiment of the present invention.

Referring to FIG. 5, the memory bus monitoring device 240 includes a slave interface 500, a traffic snopper 510, a FIFO 520, a bitmap conversion unit 530, a determination unit 540, and It includes a cache 550, a master interface 560, and the like. In addition, the memory bus monitoring device 240 is connected to the system bus 570. A system including the memory bus monitoring device 240 is a computing device including a processor, memory, and the like.

The slave interface 500 receives memory events transmitted and received between the memory controller and the system bus 570. The master interface 560 is connected to the system bus 570 to receive bitmap data and the like from the main memory.

The traffic snooper 510 monitors the traffic of the system bus 570 and captures memory write/value pairs. The FIFO 520 temporarily stores a memory write/value pair captured by the traffic snooper 510.

The bitmap conversion unit 530 loads data from the FIFO 520 and calculates a bitmap address corresponding to the address of the loaded memory event data. The bitmap converter 530 may read bitmap data from the main memory. However, it may be inefficient to access main memory and fetch bitmap data whenever there is a write event for the same area. Therefore, as an example, bitmap data may be stored in the cache 550. The cache 550 follows a read-allocation cache policy and may be updated when a memory write event for a bitmap is detected.

After the bitmap data is loaded, the bitmap conversion unit 530 transmits it to the determination unit 540. The determination unit 540 determines whether a bit of the bitmap data for the memory area of the write event is set. If the bit of the bitmap data is set to the monitoring area, the determination unit 540 transmits an interrupt to the processor to inform the monitoring module 230 that an event for the monitoring area has occurred. The monitoring module 230 intercepts the interrupt and processes the corresponding event.

6 is a flowchart illustrating an example of a kernel protection method using a monitoring module according to an embodiment of the present invention. For the present embodiment, it is assumed that the kernel code accessing the page table is replaced with a command for calling the monitoring module.

Referring to FIG. 6, when the monitoring module 230 receives a page table update request from the kernel (S600), it verifies whether the corresponding update request is valid (S610). If the update request is valid, the monitoring module 230 updates the page table on behalf of the kernel (S620). Here, the monitoring module 230 resides in a secure area of a memory in which the kernel cannot access.

7 is a flowchart showing another example of a kernel protection method using a monitoring module according to an embodiment of the present invention

Referring to FIG. 7, when an update of the system control register indicating a page table occurs (S700), the monitoring module 230 determines that the update has occurred using a trap function in the hypervisor mode (S710).

8 is a flowchart illustrating an example of a kernel protection method performed by a memory bus monitoring apparatus according to an embodiment of the present invention.

Referring to FIG. 8, the memory bus monitoring device 240 monitors a memory write event for the monitoring area (S800). For example, the memory bus monitoring device 240 may determine whether a write event for the monitoring area has occurred through a bitmap displaying information on the monitoring area as bits.

When a memory write event for the monitoring area occurs (S810), the memory bus monitoring device 240 stores the address of the write event in the memory and generates an interrupt (S820). Then, the monitoring module 230 intercepts the interrupt and transmits the address information of the memory write event to the security solution so that appropriate measures can be taken.

The present invention can also be implemented as a computer-readable code on a computer-readable recording medium. The computer-readable recording medium includes all types of recording devices that store data that can be read by a computer system. Examples of computer-readable recording media include ROM, RAM, CD-ROM, magnetic tapes, floppy disks, and optical data storage devices. In addition, the computer-readable recording medium can be distributed over a computer system connected through a network to store and execute computer-readable codes in a distributed manner.

So far, the present invention has been looked at around its preferred embodiments. Those of ordinary skill in the art to which the present invention pertains will be able to understand that the present invention can be implemented in a modified form without departing from the essential characteristics of the present invention. Therefore, the disclosed embodiments should be considered from an illustrative point of view rather than a limiting point of view. The scope of the present invention is shown in the claims rather than the above description, and all differences within the scope equivalent thereto should be construed as being included in the present invention.

Claims (13)

In a method of protecting the kernel by using a monitoring module residing in a secure area of memory that is inaccessible to a user application and kernel and accessible to a hypervisor,
The monitoring module, upon receiving a request to update a page table from a kernel through a call function, verifying the update request and updating the page table; And
The monitoring module monitoring the update using a command trap function of a hypervisor mode when a system control register indicating the page table is updated;
The monitoring module receiving information about the monitoring area in the memory from the kernel;
The monitoring module displaying the monitoring area using a bitmap representing each area of the memory divided by a predetermined size unit;
When a memory write event for the kernel memory area occurs, the memory bus monitor determines whether the area where the write event has occurred is the monitoring area using the bitmap. If the area where the write event occurs is the monitoring area, the write event Storing information in the buffer of the security area and notifying the monitoring module; And
Including, the monitoring module fetches the information on the write event stored in the buffer and provides it to a security solution residing in the security area; and
A kernel code for updating a kernel page in the kernel is changed to the calling function that calls the monitoring module, and the bitmap is located in the security area. delete delete The method of claim 1, wherein the step of notifying the monitoring module,
The memory bus monitor monitoring a memory write event through a system bus;
Determining whether a write event for the monitoring area has occurred, based on a bitmap displaying the monitoring area using bits mapped to each area of the memory divided by a predetermined size unit; And
And generating an interrupt by storing the memory address of the write event in the secure area of the memory when the write event for the monitoring area occurs, and the memory bus monitoring value. The method of claim 4, wherein the step of determining whether the write event has occurred,
Calculating a bitmap address corresponding to the memory address of the write event; And
And determining whether a bit of the bitmap corresponding to the bitmap address is set as a surveillance region. The method of claim 5,
Reading a bitmap located in the secure area of the memory and storing it in its own cache; And
And when a write event for the bitmap occurs, updating the cache. delete delete delete A memory including a security area in which the user application and the kernel are inaccessible and accessible to the hypervisor; And
Including; a memory bus monitoring device for monitoring the system bus to determine a write event for the monitoring area in the memory,
When the monitoring module receives a page table update request from the kernel through a call function, it verifies the update request and updates the page table, and when the system control register pointing to the page table is updated, a command trap function in hypervisor mode To monitor the update,
When the monitoring module receives the monitoring area information in the memory from the kernel, the monitoring area is displayed using a bitmap representing each area of the memory divided by a predetermined size unit,
When a memory write event for the kernel memory area occurs, the memory bus monitor determines whether the area where the write event occurs is the monitoring area using the bitmap, and if the area where the write event occurs is the monitoring area, the write event Information is stored in the buffer of the security area and then notified to the monitoring module,
The monitoring module fetches the information of the write event stored in the buffer and provides it to a security solution residing in the security area,
The kernel code for updating a kernel page in the kernel is changed to the calling function that calls the monitoring module, and the bitmap is located in the security area. delete delete A computer-readable recording medium on which a program code for performing the method according to claim 1 is recorded.

Images