Intel CPU aeration BUG: force the redesign of Linux and Windows

Other operating systems will need to be updated, and the performance will be affected. According to TPU, Amazon, Microsoft and Google are the three most affected by cloud computing vendors, if the vulnerability is exploited, then the virtual user A in the same physical space can be any access to another virtual user B data, including protected password, application keys etc..

Intel processor chip has a fundamental design flaw, which has forced the industry to redesign the Linux kernel and Windows kernel, aiming to eliminate the security flaws on the chip level.

The vast number of programmers are competing to completely change the virtual memory system of the open source Linux kernel. At the same time, Microsoft is expected to be in the upcoming patch Tuesday (Patch Tuesday) publicly announced necessary for its Windows operating system changes: these updates have been issued in November last year and December fast update channel (fast-ring) beta Windows Insider version of the test personnel.

It is essential that these updates to Linux and Windows will affect the performance of Intel products. The actual impact is still in the test, but we estimate that the performance will probably be reduced by 5% to 30%, depending on the specific task and the model of the processor. The recent Intel chip, which has the features of PCID and other features, can mitigate the impact of performance.

A similar operation system, such as Apple's 64 bit macOS, is also needed to update. This flaw exists in Intel x86 hardware, and micro code update seems unable to solve this defect. It is necessary to use software to fix it at the operating system level, or to buy a new processor without this design error.

Secret about Intel chip details of this vulnerability: requirements will be lifted in the early this month on these details confidential ban, may be in next week's Microsoft patch Tuesday before and after. Indeed, the patch for the Linux kernel can be viewed by everyone, but the annotations in the source code have been edited and deliberately blurred the problem.

However, some details of the defect have come to the surface, and the following are the information we have mastered.

Influence

It is reported that the defect exists in the modern Intel processor that has been produced in the past ten years. It enables ordinary user programs (from database application software to JavaScript in Internet browsers) to find data in protected kernel memory to some extent.

The solution is to separate the kernel's memory from the user process using the so-called kernel page table isolation (KPTI) function. Linux kernel development team once considered Forcefully Unmap Complete Kernel With Interrupt Trampolines (also known as FUCKWIT), let you know how much annoying this problem is for developers.

As long as the running program needs to perform any useful operation, such as writing to a file or building a network connection, it will temporarily transfer the control power of the processor to the kernel to perform the task. In order to switch from user mode to kernel mode as fast and efficiently as possible, and then switch back to user mode, kernel exists in all virtual memory address spaces of all processes, but these programs cannot see the core. When the kernel is needed, the program calls the system, the processor switches to the kernel mode and enters the kernel. After completion, CPU is told to switch back to the user mode and reenter the process. In the user mode, the kernel's code and data are still invisible, but exist in the page table of the process.

Think of the core as a God sitting on a cloud, looking down on the earth. God is there, and all the people can't see it, but they can pray to God.

These KPTI patches move the kernel to a completely separate address space, so that not only can the running process fail to see it, it is not even there at all. In fact, this should not be needed, but the defects in the Intel chip obviously allow the kernel access protection mechanism to be bypassed by people in some way.

The disadvantage of this separation is that for every system call and every interruption from hardware, it switches back and forth between two independent address spaces, which is quite expensive in terms of time. This context switch does not occur instantaneously, forcing the processor to reverse the cached data and reload the information from the memory. This increases the overhead of the kernel and slows down the speed of the computer.

So, your machine that carries a Intel chip will slow down.

How can this security leak be abused?

As a matter of fact, malware and hackers may be able to drill the loopholes in this vulnerability and make use of other security vulnerabilities more easily.

As a result, users of the program and logon may abuse the vulnerability and read the data inside the kernel's memory. In a word, this is not a good thing. The kernel memory space is hidden, and user processes and programs can't be seen, because it contains all kinds of secret information, such as passwords, login keys, cache files from disk, etc. Imagine that if a JavaScript running on the browser or malicious software running on shared public cloud servers can sniff the sensitive data of kernel protection, the consequences will be unthinkable.

Specifically, in the most ideal case, someone may use this defect to frustrate KASLR: kernel address spatial layout randomization. Many operating systems use this defense mechanism to place kernel components in random locations in virtual memory. This mechanism can be foiled attempt to abuse other defects in the kernel plot: exploit code (especially the return oriented programming loophole, https://blog.skullsecurity.org/2013/ropasaurusrex-a-primer-on-return-oriented-programming) usually rely on the repeated use of computer instructions placed in memory of the known location.

If you place the kernel code in memory at random, the attacker can't find the internal components or components needed to completely destroy the system. Some people may use this processor vulnerability to figure out how the kernel in memory determines the location of data and code, and therefore needs to quickly launch a software patch.

However, this vulnerability in Intel chips may be worse than the mitigation bypass. In the email (https://lkml.org/lkml/2017/12/27/2) sent to the Linux kernel mailing list at Christmas, AMD says the AMD processor is not affected. However, the wording of this email or the secret, that what's wrong with the bottom end:

The AMD processor is not affected by the type of attack that is defended by the kernel page table isolation function. AMD microarchitecture does not allow memory access to high privileged data when running in a low privileged mode, including speculative reference. If such access occurs, it will lead to page errors.

The key word here is "speculative". Modern processors such as the Intel processor perform speculative execution. In order to keep the internal pipe plug has the instructions waiting to be executed, the CPU kernel will try to guess the code that will run next, take out the code, and execute the code.

From the suggestion given by AMD Software Engineer Tom Randaki (Tom Lendacky), we can see that Intel's CPU may presumably execute code without executing security check. It seems possible to design software in this way, so that the processor starts executing instructions that are usually blocked, such as reading kernel memory data from user mode, and completes the instruction before the privilege level check is carried out.

That will allow the ring-3 level user code to read the kernel data of the ring-0 level. And that's not a good thing.

The details of the vulnerability remain to be confirmed, but consider this: the changes to Linux and Windows are significant and are rapidly deploying in place. This indicates that the vulnerability is more serious than the KASLR bypass.

In addition, the update of independent kernel space and user address space on Linux is inseparable from a set of KAISER patch patches, which are developed by researchers from Graz University of Technology, Austria. These researchers found that (https://gruss.cc/files/kaiser.pdf), as long as the side-channel attack is launched for the CPU virtual memory system, the memory layout information from the kernel can be defeated, and KASLR can be defeated. The research team suggested separating kernel space and user space to prevent such information leaks. Anders Foggo (Anders Fogh) to review their research work, he wrote this interesting blog in July last year (https://cyber.wtf/2017/07/28/negative-result-reading-kernel-memory-from-user-mode/).

The article describes his attempt to read the data in the kernel's memory from the user mode by drilling speculates. Although the fogo can not give any practical proof of concept code, but he pointed out in particular:

My results show that, although the separation between the kernel mode and the user mode is violated, speculative execution does continue.

KAISER this work seems to be related to the study design in addition to fogo; a practical method of drilling through virtual memory layout loopholes to KASLR defeat, the team also proved that Foggo is right, that is the Intel x86 can drill chip on the speculative execution of the loopholes, access kernel memory data inside.

sharing system

A blogger named Python Sweetness software developers on Monday published an article reproduced and retweeted the article, he said in the text, the defects will affect the major cloud computing environment, including Amazon EC2, Microsoft Azure and Google compute engine.

At present, a security flaw under a ban is affecting the modern Intel CPU architecture, which obviously realizes all virtual memory. Hardware is needed to solve the problem completely. Outside is developing emergency development software mitigation measures. This achievement has recently entered the Linux kernel. In November last year, similar mitigation measures began to appear in the NT kernel. In the worst case, software fixes can lead to a significant slowdown in typical workloads.

It has been suggested that the attack affects the common virtualization environment, including Amazon EC2 and Google computing engines...

Microsoft's Azure cloud is not only running Windows, but also running a large number of Linux. The Azure cloud will be maintained and restarted in January 10th, and it will probably launch the above repair program.

Amazon network services (AWS) also warned customers by email that it was expected to release major security updates on Friday, but without details.

The rumor of a serious hole in virtual machine management, which might involve Xen, was rumoured by the end of 2017. This hardware defect is probably a loophole in that rumor: through kernel memory access defects, it can attack the virtual machine management program, so we need to patch up, forcing a large number of guests to start the virtual machine.