X86 system virtualization Defects

Http://www.mcplive.cn /? Controller = article & id = 5788 & page = 5 privileged level

Most modern computer architectures have two or more privileged levels to separate the kernel and application software. Taking x86 as an example, in order to get higher protection control, the current previleged level (CPL) is defined in the x86 protection mode. There are four levels (0 to 3) it is defined as a ring. The larger the number behind the ring, the smaller the privilege. Our operating systems generally run on ring0, while ring1 and 2 are generally used to support device drivers. ring3 runs on application software. In the current x86 processors, the 64-bit architecture is already very common. Because the 64-bit CPU must support the page table mode, there are only two privileged levels, we can simply understand it as ring0 and ring3 (which are clearly defined in fact). This model is often called the 0/3 model.

Some key operation commands in the system can only be executed at the highest level of privilege. They are generally called privileged commands. Privileged commands are executed only when the current level of privilege is zero (CPL = 0. If you attempt to execute privileged commands at a non-authority level, a general protection exception is generated (this usually generates an application error ), non-privileged commands can be executed at any level of permission.

Ainemo in sensitive instructions

In the vmm model of the virtualization world, we can see that all the client operating systems are running in non-privileged mode, that is, non-ring0. Because the guest OS is no longer in the privileged level, some commands that should be executed at the privileged level must be transferred to vmm for processing due to insufficient level permissions. These commands are sensitive commands.

Obviously, some of the sensitive commands on x86 have loose.

According to the definitions of popek and Goldberg, the premise for the instruction set to support virtualization is that all sensitive commands are privileged commands. Unfortunately, the x86 instruction set does not meet this requirement, which is a disadvantage compared with the RISC architecture.

In the perspective of IBM and some others, because all sensitive commands are privileged commands, the execution of sensitive commands can be captured by vmm. In x86, because some sensitive commands are not privileged commands, they become non-privileged commands, and non-privileged commands can be directly executed at a lower level, that is, vmm will not process these commands. This will inevitably lead to problems. Imagine how a command not controlled by the virtualization software layer works on the virtualization layer? X86 has at least a dozen of sensitive commands that do not cause exceptions. In the IA-32 instruction set, we call these non-privileged sensitive commands as critical commands, they can be divided into two types:

Sensitive register commands: they read or modify the content stored in sensitive registers and/or sensitive memory data areas, such as clock registers and interrupt registers.

1. sgdt, sidt, and sldt
2. smsw
3. pushf and popf

Protection System Command: involves the storage protection system, memory or address location system.

1. Lar, LSL, verr, verw
2. Pop
3. Push
4. Call, JMP, int N, RET
5. Str
6. mov

Critical instruction example

We use an actual example to explain the virtualization vulnerability of the x86 instruction set. Smsw commands (commands that take machine status characters) are designed to be backward compatible with older processors. These commands should be completed by the operating system, that is, they must be ring0, but unfortunately it is not put in privileged commands. In a virtualized environment, the client operating system works at a non-specific level (generally ring1 or ring3 ), as mentioned above, non-privileged commands can be directly executed without being captured by vmm at a lower privilege level.

Different privileged levels meet different program running requirements

When the client operating system executes this command, it directly obtains the value of the real machine (assume that value 1 is the protection mode, and value 0 is the real mode ), currently, vmm generally works in protection mode. If the client operating system runs in real mode, the problem arises. The smsw value is 1, it indicates that the system is running in the protection mode, rather than the return value of 0 in the real mode of the client operating system. This is obviously incorrect.