KR20110024987A - Method for kernel hardening of usb device driver in linux operating system and apparatus thereof - Google Patents

Abstract

PURPOSE: A system and a device for performing kernel hardening of a usb device driver in a system based on a Linux operating system are provided to perform kernel hardening of the USB device by using a DLM(Dynamic Linking Module) in the Linux operating system. CONSTITUTION: A system loads USB(Universal Serial Bus) device driver module to a system kernel(510). The system performs kernel hardening about an error of a system kernel(520). If an error occurrence case is a value type, the system forcibly set a variable value which expresses an error based on a condition value of a normal state(530,540). If the error occurrence case is an address type, the system displays an error file name and an execution code line(550). The system generates a system panic(560).

Description

Method and kernel hardening of USB device driver in Linux operating system and apparatus

The present invention provides a USB device driver using the DLM (Dynamic Linking Module) technology in the Linux operating system to prevent system panic and improve system stability when using a USB device in a Linux operating system-based system. A method and apparatus for implementing kernel hardening.

Linux is a computer-based operating system that allows Unix, an operating system that used to work on large machines, to run on small PCs. Linux has the advantage that the program source code is freely available, so that programmers can analyze and modify it as they wish, and even port it to any platform.

The Linux operating system is widely used in the embedded system field by using an open source feature, and a company is used as a web server, a file server, a DB server, and the like. In the Linux operating system, you can modify the Linux kernel source to add file systems, device drivers, etc. to the kernel.

However, incorrectly modifying the Linux operating system kernel source or writing a kernel kernel program can lead to system failure. If the wrong code is in the kernel, the system hangs. In other words, the system may hang due to an incorrect operation or wrong program in the Linux operating system kernel. This phenomenon is called a system panic. If the system is stopped for a while due to the system panic, a big problem may occur while using various services. In serious cases, data can be destroyed.

Kernel hardening technology is a technology that allows a system to operate normally by recovering from a system hang due to incorrect code in an operating system kernel.

In the operating system operating kernel hardening technology, if the current process enters the panic, the current process is examined without stopping the system to determine whether the recovery is possible or not. Only when it is determined that the recovery is possible, the system can be restored so that the system can operate normally without stopping.

SUMMARY OF THE INVENTION An object of the present invention is to provide a method and an apparatus capable of stably operating a system and reducing system panic caused by a USB device when using a USB device in a Linux operating system.

Kernel hardening method according to an embodiment of the present invention for achieving the above object is a method for performing kernel hardening of the USB device driver in a Linux operating system (OS) based system, the connection of the USB device Recognizing and dynamically loading the USB device driver module into the system kernel; And performing kernel hardening by using a kernel hardening function for an error of a system kernel provided in the loaded module.

On the other hand, kernel hardening apparatus according to another embodiment of the present invention for achieving the above object is an I / O interface unit for recognizing the connection of the USB device to dynamically load the USB device driver module into the system kernel; And a kernel hardening unit that performs kernel hardening by using a kernel hardening function for an error of a system kernel included in the loaded module.

In addition, the present invention also includes a recording medium on which a program for executing kernel hardening of a USB device driver on a computer in a Linux operating system-based system is recorded.

DETAILED DESCRIPTION In order to fully understand the present invention, the operational advantages of the present invention, and the objects achieved by the practice of the present invention, reference should be made to the accompanying drawings which illustrate preferred embodiments of the present invention and the contents described in the drawings.

Hereinafter, with reference to the accompanying drawings will be described in detail a preferred embodiment of the present invention.

The present invention proposes a kernel hardening technique that allows a system to operate normally by controlling a panic when a USB device is connected to a system of a Linux operating system.

The kernel is the most important core of a computer operating system, providing several basic services to all other parts of the operating system. In general, the kernel has an interrupt handler that handles all requests that competitively require kernel services, such as terminated I / O operations, a scheduler that determines which programs share the kernel's processing time, and in what order. In fact, it includes a supervisor that grants each computer a license. The kernel also has a memory manager that manages the operating system's address space in memory or storage and distributes it evenly among all peripherals and other users of the kernel's services. Kernel services are requested through different parts of the operating system or through a set of program interfaces known as system call functions. Because the code to maintain the kernel is used continuously (statically), the kernel is usually loaded in an area of memory that is protected from being corrupted by being overwritten by the rest of the operating system.

USB devices, on the other hand, are a type of serial port that solves the slow speed and limited device connectivity issues of traditional external expansion ports, allowing connections between computers and peripherals such as audio players, keyboards, mice, Internet phones, scanners, and printers. Is a plug-and-play interface. Therefore, it is not always plugged in, but various peripheral devices can be attached / removed and used according to the situation and needs, so that the USB device driver is also loaded into the OS kernel each time.

The present invention proposes a method of controlling a system panic that may occur when a USB device is connected to a system by using a dynamic linking module (DLM) of the Linux OS kernel. Dynamic Load Module (DLM) is one of the most important innovations in the Linux kernel. The DLM module allows the Linux OS kernel to dynamically expand the kernel's functionality as needed.

Another one of the kernel hardening functions is to use the ASSERT () function to force the correct value for the variable with the wrong value in the case of the value type according to the variable type used in the kernel. And address type may cause system panic.

Figure 1 shows the source code of the USB_ASSERT () macro function to recover from a situation where panic may occur in the usb-uhci.c source code of the USB driver. 5 is a flowchart illustrating a method of performing kernel hardening of a USB device driver.

First, referring to FIG. 5, an operation process according to an embodiment of the present invention will be described. First, when a USB device is connected to a Linux OS-based system, a USB device driver module is dynamically recognized by a USB device driver module. In step 520, kernel hardening of an error of the system kernel is performed using a kernel hardening function provided in the loaded module (520). Recovers the system if an error occurs with the data value necessary to execute the system kernel through the kernel hardening process, and recovers the system if an error occurs with the memory address. Generate panic. Looking at the operation process in more detail, by determining the type of the variable in which the error occurs (530), in the case of the value type (value type) case using the condition value of the normal state of the argument value input to the function The system recovers by forcing the argument value indicated (540), but if the determination result is an address type, the file name and executable code line in which the error occurred are displayed to the user (550), and a system panic is generated. 560.

An example of actual program code in which such kernel hardening is implemented is described below with reference to FIG. 1. In S110 of FIG. 1, "expr1" is a variable in which a panic is generated, "expr2" is a condition value in a normal state without a panic, and "expr3" is an address indicating whether the USB_ASSERT () function is a value type. It is an argument that indicates whether it is an address type. Therefore, the variable type of "expr2" is distinguished by the value of "expr3".

Referring to S120, when the third argument value "expr3" is "1", "expr2" is a variable type of address, and when an error occurs because an incorrect value is passed to "expr1", recovery is impossible. Therefore, the panic () function is called internally, at this time, "printk (" \ n error USB_ASSERT3. \ N ", _ FILE_":% d: Assertion ", #" expr2 "" failed! \ N ", _ LINE_);" Is printed at the kernel level.

Here, "_FILE_" means the name of the file in which the current error occurred, and "_LINE_" means the corresponding line in the file in which the error occurred. The source code of Figure 1 prints the number of the line containing the printk () function in the usb-uhci-deu.c file so that when the error occurs, it is easy to find out which line of the file the error occurred. Do it.

In addition, referring to S130, when the value of "expr3" is "2", the value of "expr2" can be corrected even if an incorrect value of "expr1" is entered as the variable type of "expr2" is value. Is possible and no panic will occur. That is, recovery is possible by forcibly assigning the normal value "expr2" to "expr1".

Hereinafter, in FIG. 2, in order to test whether the USB_ASSERT () macro added to the usb-uhci-deu.c file operates normally, the USB_ASSERT () macro function is implemented in the uhci_interrupt () function that operates when the USB device is connected to the system. An example is shown.

Referring to FIG. 2, a variable t causing an error is first declared (S210), which is then used as a USB_ASSERT () macro function (S250) below the portion (S220) denoted by “--- USB kernel hardening ---”. ) Are treated as important variables.

First, an incorrect value of “0” is assigned to the variable “t” (S230), and “t” is input as the first argument value of the USB_ASSERT () macro function. As the second parameter value of the USB_ASSERT () macro, an example value "5", which is a normal condition value, is input. If the USB_ASSERT () macro works normally, the "t" value changes to "5" after the USB_ASSERT () macro function. To check this, the value of the "t" variable can be checked using the printk () function before (S240) and after (S260) before executing the USB_ASSERT () macro function.

3 illustrates a USB_ASSERT_INW () macro function that prevents an error of the inw () function in the usb-uhci-deu.c file by using the USB_ASSERT () macro function.

Referring to FIG. 6, a method of preventing an error of an inw () function using the USB_ASSERT_INW () macro function is described first. When a USB device is connected to a Linux operating system, the USB device is recognized and dynamically connected. The USB device driver module is loaded into the system kernel (610), and kernel hardening for an error of the system kernel is performed using the kernel hardening function included in the loaded module (620). In the process of performing kernel hardening, a USB device connected to an input / output (I / O) port is read using a system call function such as an inw () function (630), and the result value of the read system call function is read. In operation 640, the flag value is selectively set. That is, by determining whether the marked flag value is "0" or "1" (650), for example, when the flag value is "1", the panic () function may be called (660).

An example of the actual program code in which the above operation is implemented will be described with reference to FIG. 3. In FIG. 3, the USB_ASSERT_INW () macro also has three parameter values in the same manner as the USB_ASSERT () macro (S310).

First, "expr1" is a variable to check for errors, and "expr2" is an argument to the inw () function. The inw () function is a system call function whose prototype is unsigned short inw (unsigned short port) for the I / O interface. "expr3" is a panic flag value.

Referring to S320, the result of the inw () function having "expr2" as an argument value is assigned to "expr1". If the value of "expr1" is an abnormal value (that is, NULL) in the conditional statement, "expr3" is replaced with " 1 ". If it is a normal value, it assigns" 0 "to" expr3 ".

That is, "expr3" serves as a flag by having a value of "1" if the result of the inw () function is abnormal and a value of "0" if it is normal.

Referring to FIG. 4, example code using the USB_ASSERT_INW () macro function is shown.

First, the flag value "P_flag" is initialized to "0" (S410), and then the USB_ASSERT_INW () macro function is called. The three argument values of the USB_ASSERT_INW () macro function are passed in order of "status", "io_addr + USBSTS", and "P_flag".

"status" is the first parameter and the variable reflects the result of the INW () function. Therefore, the third argument value "P_flag" is marked as "0" (normal) and "1" (abnormal) depending on the result of the INW () function, that is, the "status" value.

Therefore, the value of the "P_flag" variable determines whether to call the panic () function internally. In other words, when "P_flag" is "1", the panic () function is called.

7 is a diagram illustrating an apparatus for performing kernel hardening of a USB device driver according to one embodiment of the present invention.

Referring to FIG. 7, an embodiment of an apparatus for performing kernel hardening of a USB device driver in a Linux operating system 740 based system recognizes a connection of a USB device 710 and dynamically converts a USB device driver module into a system kernel. The kernel hardening unit 730 performs kernel hardening on an error of the system kernel by using the kernel hardening function provided in the loaded module. .

According to various embodiments of the above-described kernel hardening method and apparatus, a kernel hardening scheme is designed and implemented when a panic occurs when a USB device device is connected to a Linux operating system.

According to various embodiments of the present invention, it can be seen that the kernel hardening technology and the DLM technology of the Linux operating system are normally applied to the USB device device. This has the advantage of increasing the stability of systems using USB device devices. In addition, there is an advantage that the kernel hardening module can be implemented to be detachably attached during system operation.

On the other hand, the above-described kernel hardening method of the present invention can be written as a program that can be executed in a computer, it can be implemented in a general-purpose digital computer to operate the program using a computer-readable recording medium.

In addition, as described above, the structure of the data used in the present invention may be recorded on a computer-readable recording medium through various means.

The computer-readable recording medium may include a storage medium such as a magnetic storage medium (eg, a ROM, a floppy disk, a hard disk, etc.) and an optical reading medium (eg, a CD-ROM, a DVD, etc.).

So far I looked at the center of the preferred embodiment for the present invention. Those skilled in the art will appreciate that the present invention can be implemented in a modified form without departing from the essential features of the present invention. Therefore, the disclosed embodiments should be considered in an illustrative rather than a restrictive sense. The scope of the present invention is shown in the claims rather than the foregoing description, and all differences within the scope will be construed as being included in the present invention.

FIG. 1 is a diagram illustrating a source code of a USB_ASSERT () macro function that can recover a situation in which a panic may occur in a usb-uhci.c source code of a USB driver according to an embodiment of the present invention. .

Figure 2 implements the USB_ASSERT () macro function in the uhci_interrupt () function for the USB device to test whether the USB_ASSERT () macro added to the usb-uhci-deu.c file operates according to another embodiment of the present invention Source code showing an example.

FIG. 3 is a source code illustrating a USB_ASSERT_INW () macro function that prevents an error of an inw () function in a usb-uhci-deu.c file by using a USB_ASSERT () macro function according to another embodiment of the present invention.

4 is a diagram illustrating example code using a USB_ASSERT_INW () macro function according to another embodiment of the present invention.

5 is a flowchart illustrating a method of performing kernel hardening of a USB device driver according to an embodiment of the present invention.

6 is a flowchart illustrating a method of performing kernel hardening of a USB device driver according to another exemplary embodiment of the present invention.

7 is a diagram illustrating an apparatus for performing kernel hardening of a USB device driver according to one embodiment of the present invention.

Corresponding reference numerals in the several drawings indicate corresponding parts. Although the drawings show embodiments of the invention, the drawings are not to scale and certain features may be exaggerated to better illustrate and explain the invention.

Claims (10)

How to perform kernel hardening of USB device driver in Linux operating system based system, Recognizing a connection of the USB device and dynamically loading a USB device driver module into a system kernel; And And performing kernel hardening by using a kernel hardening function on an error of a system kernel included in the loaded module. The method of claim 1, wherein performing kernel hardening Recovering the system when an error occurs with respect to a data value required to execute the system kernel, and generating a panic for the system when an error occurs with a memory address. How to feature. 3. The method of claim 2, wherein performing kernel hardening Receiving a plurality of factor values; Determining whether a type of a variable in which an error occurs is a value type or an address type using the input argument value; Restoring the system using a condition value of a steady state among the inputted factor values in the case of a value type; And And displaying a file name and an executable code line in which an error occurs in the case of an address type as a result of the determination. The method of claim 3, The plurality of parameter values include a first parameter value, which is a variable value representing an error of a system kernel, a second parameter value, which is a steady state condition value, and a third parameter value, which distinguishes a type of a variable. And as a result of determining the third factor value, assigning the second factor value to the variable of the first factor value when the type of the variable is a value type. The method of claim 1, wherein performing kernel hardening Receiving a plurality of factor values; Reading the USB device through a system call function of the Linux operating system using the input argument value; And Selectively setting a flag value among the argument values according to a result value of the read system call function. The method of claim 5, The plurality of argument values include a fourth argument value which is a variable value for checking an error of a system kernel, a fifth argument value that is a transfer argument value of the system call function, and a sixth argument value that is a flag value indicating whether an error occurs. , Assigning a result value of the system call function receiving the fifth argument value to a variable of the fourth argument value; And And assigning a value of 0 or 1 to the sixth factor value according to whether the fourth factor value is normal or abnormal. The method of claim 6, Selectively calling a panic function according to the sixth argument value that is the flag value. In a device that performs kernel hardening of a USB device driver in a Linux operating system-based system, An I / O interface unit recognizing a connection of the USB device and dynamically loading a USB device driver module into a system kernel; And And a kernel hardening unit configured to perform kernel hardening by using a kernel hardening function on an error of a system kernel included in the loaded module. The method of claim 8, wherein the kernel hardening unit Recovering the system when an error occurs with respect to a data value required to execute the system kernel, and generating a panic for the system when an error occurs with a memory address. Characterized in that the device. In a recording medium having a program recorded thereon for executing on a computer a method of performing kernel hardening of a USB device driver in a Linux operating system-based system, Recognizing a connection of the USB device and dynamically loading a USB device driver module into a system kernel; And And performing kernel hardening by using a kernel hardening function for an error of a system kernel included in the loaded module.

Images