RU2609761C1 - Method for code performance in hypervisor mode - Google Patents

Abstract

FIELD: physics, computer engineering.

SUBSTANCE: invention refers to the field of computer security. The method is proposed, including hypervisor code loading to the random-access memory prior to operating system booting; a trusted module to call the hypervisor code execution is loaded to RAM during operating system booting; the first request to the hypervisor from the trusted module in order to obtain the hypervisor address in RAM is sent; a cryptographic key is generated using the hypervisor; the specified key is saved in the hypervisor memory; a memory page is allocated; the specified key and hypervisor address in RAM are recorded in the selected memory page; protection for the allocated memory page is set; a request to the hypervisor at the address recorded in the page selected in step g) is sent from the trusted module in order to call hypervisor code execution, at that, the request contains the key, recorded in the allocated page; the key is checked by means of the hypervisor by comparing the key transmitted in the request sent to the hypervisor from the trusted module to the key stored in the hypervisor memory; if the result is positive, the code is executed in the hypervisor mode.

EFFECT: code execution is provided in the hypervisor mode.

5 dwg

Description

Technical field

The invention relates to antivirus technologies, and more particularly to systems and methods for ensuring the execution of code in hypervisor mode.

State of the art

Currently, computer threats (such as Trojans, viruses, worms) are developing more rapidly and are using an increasing number of ways to bypass anti-virus applications. One of these methods is to hide certain resources of a computer system (for example, files or registry branches) from an anti-virus application that performs anti-virus scanning. According to the classification of antivirus companies, malicious programs that use this method are called rootkits or using rootkit technology. Rootkit technologies turn out to be even more dangerous if it is possible to exploit vulnerabilities in components of the operating system (OS) that operate at the kernel level (English kernel level). This prevents modern anti-virus applications from detecting malicious programs that use similar technologies.

One of the solutions in this situation is to use a hypervisor that isolates operating systems from each other, shares resources between different running operating systems, and manages resources. At the same time, code execution in hypervisor mode is carried out even at a lower level than code execution at the kernel level. It is not surprising that companies that produce anti-virus applications are interested in this approach. Patent application US 20140053272 describes the execution of code in hypervisor mode to control memory changes that could be introduced by malicious code.

However, this publication does not disclose a solution to the problem of ensuring the integrity of such a solution as a whole, since there are threats (malicious applications) that allow access to the code working in hypervisor mode.

An analysis of the prior art allows us to conclude about the inefficiency and, in some cases, the impossibility of applying previous technologies, the disadvantages of which are solved by the present invention, namely, the system and method for invoking code execution in hypervisor mode.

Disclosure of invention

The technical result of the present invention is to ensure that the code runs in hypervisor mode. This technical result is achieved using the method of executing the code in the hypervisor mode, in which the hypervisor code is loaded into the RAM before the operating system loads; load the trusted module into RAM during the boot of the operating system, while the trusted module is an application that runs on the operating system and is designed to invoke the execution of the hypervisor code; make the first request to the hypervisor from the trusted module in order to obtain the address of the hypervisor in RAM; generating a cryptographic key using a hypervisor; save the specified key in the memory of the hypervisor; allocate a page of RAM; write the specified key and the address of the hypervisor in the random access memory into a dedicated page of the RAM; set protection for the selected memory page; make a request to the hypervisor at the address recorded in the dedicated page from the trusted module to call the execution of the hypervisor code, the request includes a key recorded in the selected page; verify the key with the hypervisor by comparing the cryptographic key transmitted in the request to the hypervisor from the trusted module with the cryptographic key in the memory of the hypervisor; if the test result is positive, the hypervisor code is executed in the hypervisor mode.

According to one embodiment, the hypervisor allocates a memory page.

In yet another embodiment, a trusted module allocates a memory page.

According to another embodiment, the memory protection includes an execution-only bit, upon installation of which the page cannot be rewritten.

According to one embodiment, the protection for the allocated memory page is set by a trusted module.

In yet another embodiment, the hypervisor sets protection for the allocated memory page.

Brief Description of the Drawings

Additional objectives, features and advantages of the present invention will be apparent from reading the following description of an embodiment of the invention with reference to the accompanying drawings, in which:

FIG. 1 gives an example of a system in which a mechanism for trusted code invocation in hypervisor mode is implemented.

FIG. 2 illustrates an embodiment of providing a hypervisor call address for a trusted module.

FIG. Figure 3 shows an example of a memory page where the address of the hypervisor for calling from the trusted module is stored.

FIG. 4 illustrates a method for protecting memory pages using a hypervisor.

FIG. 5 shows an example of a general purpose computer system with which the present invention can be implemented.

Description of Embodiments

The objects and features of the present invention, methods for achieving these objects and features will become apparent by reference to exemplary embodiments. However, the present invention is not limited to the exemplary embodiments disclosed below, it can be embodied in various forms. The essence described in the description is nothing more than the specific details necessary to assist the specialist in the field of technology in a comprehensive understanding of the invention, and the present invention is defined in the scope of the attached claims.

We introduce several notation that will be used in the framework of the present description.

A hypervisor program that provides simultaneous, parallel execution of several operating systems (OS) on the same computer. There are two types of hypervisors - the first has its own built-in device drivers, a scheduler, and therefore does not depend on any OS, while the second type works in the same ring with the core of the main OS (kernel mode or zero ring, English ring 0). The first type of hypervisor is also called bare-metal and is the preferred embodiment of the hypervisor in the present invention. Code execution in hypervisor mode occurs at an even lower level than code execution in kernel mode (kernel mode or ring 0).

Calling code executing in hypervisor mode (hypercall) - switching to code execution in hypervisor mode (another definition is execution), which requires hardware support for virtualization technology from the processor.

A trusted OS is an operating system that uses sufficient hardware and software to provide simultaneous processing of information of varying degrees of secrecy by a group of users without violating access rights. Roughly speaking, a trusted OS allows for the confidentiality and integrity of user data. For a more detailed description of trusted systems, see A Guide to Understanding Configuration Management in Trusted Systems (1988).

Trusted code call - a third-party code call during which it is guaranteed that the call is made from a trusted source (a memory page that belongs to the trusted application process), which eliminates the possibility of calling third-party code from malicious or untrusted programs. A trusted application is an application whose executable file is digitally signed and which is not malicious.

In FIG. Figure 1 shows an example of a system that implements a mechanism for trusted code invocation in hypervisor mode. Various applications 130, trusted module 150 work in operating system 110, and malware 140 may also be located. Applications 130 include various user applications, such as a browser, text editor, and others. Malicious program 140 can use various methods of hiding its presence in the operating system (rootkit technology, English rootkit), which avoids detection by antivirus applications (not shown in Fig. 1, can be part of applications 130). This fact does not allow OS 110 to be trusted and jeopardizes user data. You can read about ways to hide the presence of malware in the operating system in various sources, for example, http://www.z-oleg.com/secur/articles/rootkit.php.

In order to detect the presence of malicious program 140, as well as to prevent the malicious program 140 from accessing user information, the trusted module 150 and the hypervisor 120 are used. The trusted module 150 can be executed either as a standalone application or as part of an anti-virus program. A key feature of trusted module 150 is its ability to make calls to execute hypervisor code 120. As noted above, code execution in hypervisor mode is even lower than code execution in kernel mode, which allows you to ignore possible rootkits used by the malware 140. Code that runs in kernel mode (ring 0) does not have the ability to access code that runs in hypervisor mode. In the same way, code executed in user mode (ring 3 or user mode) does not have access to code that runs in kernel mode. More details about protection rings can be found in various publications, such as Russinovich, Mark E .; David A. Solomon (2005). Microsoft Windows Internals (4 ed.). Microsoft Press. Additionally, note that code execution in ring 0 is also called kernel-level execution, and code execution in ring 3 is user-level execution.

As already noted, the trusted module 150 makes calls to execute the code of the hypervisor 150 (whose code will be executed in hypervisor mode), i.e. makes hypercalls. In the framework of the present description, it is assumed that the OS 110 is initially trusted, but the malware 140 compromises the OS's power of attorney. It is also understood that the malware 140 has complex logic (for example, rootkit functionality), which avoids its detection by the anti-virus application installed in OS 110 (not shown in Fig. 1). Thus, it is required to ensure the protection of the user information from malware 140.

Within the framework of modern operating systems, information can be protected in several ways: use encryption, control access to storage media, and protect the virtual memory of those processes that work with this information. Technologies aimed at encrypting and controlling access to storage media (as a rule, these are technologies for preventing data leakage, the English Data Leak Prevention) do not belong to this technology, the present invention addresses the protection of virtual memory of processes.

The very method of protecting virtual memory of nen processes. For example, the NX-bit allows you to set the execution inhibit bit for the memory page, to realize the possibility of preventing the execution of data as executable code. In the patent US 8990934 describes the ability to control the mutually exclusive setting of the execution and recording bits for the memory page in order to prevent recording and exploit execution (English exploit).

However, these technologies have the disadvantage that they work at the kernel level of the OS, which leaves it possible to execute malicious code at the same privilege level, but with an earlier start of work during the OS startup (initialization) after turning on the computer. Such malicious code can disable, or even worse, control the memory protection algorithms described above, which again does not allow protecting user information in such cases. For more information about the OS start (initialization) after turning on the computer, see various publications, such as Russinovich, Mark E .; David A. Solomon (2005). Microsoft Windows Internals (4 ed.). Microsoft Press.

As noted above (patent application US 20140053272), code execution in hypervisor mode allows you to control memory changes by malicious code, even if the latter is executed in kernel mode. However, to call code execution in hypervisor mode — to make hypercalls — a separate application is required, the code of which will make such hypercalls. In the present invention, such an application is a trusted module 150. In one embodiment, the trusted module 150 may be an antivirus.

It is important to note that code in hypervisor mode 120 in the form of a monolithic section of code that will contain checks of the virtual memory pages of processes running in OS 110 is very difficult to do for several reasons:

- the hypervisor code is "overloaded" (it turns out to be too complicated for writing and debugging), it begins to consume too many system resources, in particular, processor time;

- The hypervisor code is too "low", i.e. he doesn’t “know” the OS operating mechanism that works “above” the hypervisor, a similar problem is typical for bare-metal hypervisors.

It becomes clear that it is necessary to transfer part of the present invention to the trusted module 150, leaving only the function of checking memory pages in the hypervisor 120. The trusted module 150 should be implemented taking into account the specifics of the implementation of OS 110 (for example, taking into account the page organization of the memory of the Windows OS), allowing the hypervisor 120 to be cross-platform.

The basis of the present invention is a secure communication channel between the trusted module 150 and the hypervisor 120. To provide such a communication channel, it is necessary that only the trusted module 150 can call the code of the hypervisor 120 (hyper call). Given that the code of the hypervisor 120 is stored in RAM, it is required to ensure the confidentiality of the address at which this code is called.

FIG. 2 illustrates the option of providing the call address of the hypervisor 120 for the trusted module 150. At step 205, immediately after the start of the computer system, the hypervisor 120 is loaded before the OS 110 is initialized. As a rule, bare-metal hypervisors are initialized before the guest OS starts. A guest OS means any OS that starts after the initialization of the hypervisor — in this case, OS 110. At step 207, the trusted module 150 is loaded, which is usually implemented as an OS 110 driver and is loaded as soon as possible. Such a requirement is necessary so that at step 207 OS 110 is still trusted, since the early start of trusted module 150 allows it to be launched before malicious program 140 is launched. At step 210, trusted module 150 makes the first call to hypervisor 120 (hypercall) ), after which the address of the hypervisor 120 is returned in memory (the so-called address of the safe hyper-call). Next, this address should be protected from unauthorized access, for which, at step 220, a memory page 300 is allocated, whose structure is shown in FIG. 3. The memory page itself consists of a set of addresses in memory at which the code will be called. In the framework of this implementation, only one call will directly lead to a hypercall, while the rest will cause an exception (English exception) and an error in the operation of OS 110 with subsequent reboot. This memory page 300 is allocated either by the trusted module 150, or directly by the hypervisor 120 upon its first call. Filling the page with the call code is performed by the hypervisor 150 at step 230. The memory page is additionally protected - it is set (either by the trusted module 150 or by the hypervisor 120) only for execution, which occurs at step 240, during the installation of which the page cannot be overwritten.

Consider the mechanism for transmitting the correct hypervisor call address 120 to trusted module 150. Since storing the address itself in the process memory of trusted module 150 can be unsafe, as malicious software 140 is not excluded from receiving it, the trusted module 150 also stores a token that represents a randomly generated key, using which you can make a hyper call. The token itself is generated by the hypervisor 120 at the time of its first call (step 210 in Fig. 2) and transmitted to the side of the trusted module 150 in order to compare the value of the token during a hyper call, which avoids the situation with a malicious call to the hypervisor 120. The token is generated once per the operating time of the computer system (after turning on the power) and for OS 110 it is unique. Thus, if there are other guest OSs in the system, hypervisor 120 will generate its own token for each of them.

FIG. 4 illustrates a method for protecting memory pages using a hypervisor. At step 410, the trusted module 150 makes a hyper call, after which, at step 420, the token is checked and, if the token from the protected module 150 matches the stored token of the hypervisor 120 (check at step 430), then at step 450, the trusted module 150 transmits the addresses of the memory pages, which require protection. Memory protection involves setting bits to prohibit / enable various operations - reading (Read), writing (Write), code execution (eXecute). At step 460, a checksum (Cyclic redundancy check, CRC) is assigned to the data that is stored in the protected memory pages. At step 470, a periodic check is scheduled on the part of the hypervisor 120 to calculate the checksums for the protected memory pages due to the possibility of an attack associated with working at linear addresses. A periodic check can be initialized by either the hypervisor 120 or the trusted module 150 by using hyper-calls at regular intervals. The hypervisor 120 may also check the integrity of the control module 150 in order to make sure that the latter has not been altered by the malware 140. The integrity check includes calculating the checksum and comparing it with a previously saved value to determine the change in the control module 150. This check proceeds at step 420 In the event that the code of the control module 150 has been changed, the hypervisor can restore it to memory by loading it from disk.

Let's give an example of an attack related to working at linear addresses. For example, the IDT (Interrupt Dispatch Table) of OS 110 is located at the linear address 0 × F1D10000, which is a mapping (i.e., mapping the address of a virtual memory page to the address of a physical) physical address 0 × 123000. Hypervisor 120 can establish the above protection (without loss of performance) on the physical page at 0 × 123000. But malware 140 can select a physical page, for example 0 × 321000, copy the contents of the original page 0 × 123000 there, swapping the necessary elements there (in this case it will be an interrupt handler), and set the display to 0 × F1D10000-> 0 × 321000, so the hypervisor 120 itself will not be able to notice the substitution, since it does not have information about the logic of the virtual memory in OS 110. Therefore, the trusted module 150 must periodically check the correctness of the page tables from within the OS 110, as in the above example, that 0 × F1D1000 action tionary is 0 × 123000, and nothing else.

Consider storage options for hypervisor 120 until it is loaded. Hypervisor 120 code is stored either as a UEFI service (Unified Extensible Firmware Interface), or in a separate device on a PCI-card that is not defined in OS 110 (for example, hypervisor 120 or trusted module 150 independently handle interrupts from this device), or using disk virtualization (hypervisor 120 excludes sectors of the disk on which its code is stored, changing the functionality of the disk driver).

FIG. 5 is an example of a general purpose computer system, a personal computer or server 20 comprising a central processor 21, a system memory 22, and a system bus 23 that contains various system components, including memory associated with the central processor 21. The system bus 23 is implemented as any prior art bus structure comprising, in turn, a bus memory or a bus memory controller, a peripheral bus and a local bus that is capable of interacting with any other bus architecture. The system memory contains read-only memory (ROM) 24, random access memory (RAM) 25. The main input / output system (BIOS) 26 contains the basic procedures that ensure the transfer of information between the elements of the personal computer 20, for example, at the time of loading the operating system using ROM 24.

The personal computer 20 in turn contains a hard disk 27 for reading and writing data, a magnetic disk drive 28 for reading and writing to removable magnetic disks 29, and an optical drive 30 for reading and writing to removable optical disks 31, such as a CD-ROM, DVD -ROM and other optical information carriers. The hard disk 27, the magnetic disk drive 28, the optical drive 30 are connected to the system bus 23 through the interface of the hard disk 32, the interface of the magnetic disks 33 and the interface of the optical drive 34, respectively. Drives and associated computer storage media are non-volatile means of storing computer instructions, data structures, software modules and other data of a personal computer 20.

The present description discloses an implementation of a system that uses a hard disk 27, a removable magnetic disk 29, and a removable optical disk 31, but it should be understood that other types of computer storage media 56 that can store data in a form readable by a computer (solid state drives, flash memory cards, digital disks, random access memory (RAM), etc.) that are connected to the system bus 23 through the controller 55.

Computer 20 has a file system 36 where the recorded operating system 35 is stored, as well as additional software applications 37, other program modules 38, and program data 39. The user is able to enter commands and information into personal computer 20 via input devices (keyboard 40, keypad “ the mouse "42). Other input devices (not displayed) can be used: microphone, joystick, game console, scanner, etc. Such input devices are, as usual, connected to the computer system 20 via a serial port 46, which in turn is connected to the system bus, but can be connected in another way, for example, using a parallel port, a game port, or a universal serial bus (USB). A monitor 47 or other type of display device is also connected to the system bus 23 via an interface such as a video adapter 48. In addition to the monitor 47, the personal computer may be equipped with other peripheral output devices (not displayed), such as speakers, a printer, and the like.

The personal computer 20 is capable of operating in a networked environment, using a network connection with another or more remote computers 49. The remote computer (or computers) 49 are the same personal computers or servers that have most or all of the elements mentioned earlier in the description of the creature the personal computer 20 of FIG. 5. Other devices, such as routers, network stations, peer-to-peer devices, or other network nodes may also be present on the computer network.

Network connections can form a local area network (LAN) 50 and a wide area network (WAN). Such networks are used in corporate computer networks, internal networks of companies and, as a rule, have access to the Internet. In LAN or WAN networks, the personal computer 20 is connected to the local area network 50 via a network adapter or network interface 51. When using the networks, the personal computer 20 may use a modem 54 or other means of providing communication with a global computer network such as the Internet. The modem 54, which is an internal or external device, is connected to the system bus 23 via the serial port 46. It should be clarified that the network connections are only exemplary and are not required to display the exact network configuration, i.e. in reality, there are other ways to establish a technical connection between one computer and another.

In conclusion, it should be noted that the information provided in the description are examples that do not limit the scope of the present invention defined by the claims.

Claims (12)

A method of executing code in hypervisor mode, in which: a) load the hypervisor code into the RAM before loading the operating system, while the hypervisor code is executed in the hypervisor mode; b) load the trusted module into the RAM during the loading of the operating system, while the trusted module is an application running in the operating system and is designed to call the execution of the hypervisor code; c) make the first request to the hypervisor from the side of the trusted module in order to obtain the address of the hypervisor in RAM; d) generate a cryptographic key using a hypervisor; d) save the specified key in the memory of the hypervisor; e) allocate a page of RAM; g) write down the specified key and the address of the hypervisor in the random access memory in the allocated page of the RAM; h) establish protection for the selected memory page; i) make a request to the hypervisor at the address recorded in the dedicated page in step g), from the side of the trusted module to call the execution of the hypervisor code, the request includes a key recorded in the selected page; j) verify the key using the hypervisor, by comparing the cryptographic key transmitted in the request to the hypervisor from the trusted module with the cryptographic key in the memory of the hypervisor; k) if the verification result is positive, the hypervisor code is executed in the hypervisor mode.

Images