Tag Archives: kernel

Intel processors revealed to have major flaw, only addressable by OS updates


UPDATE: I’ve been trying to find out more, but Intel is now claiming it has a fix for the vulnerabilities affecting its chips that it will be rolling out by the end of next week. Details are slim, and I will hold off final judgment of course, but I’ll be surprised if it’s completely effective; these microcode patches can be tricky – it’s not a straight firmware update as it impacts the fundamental operation of the CPU. Additionally, it appears the fixes only address the last five year’s worth of processors. Better than nothing if it works.

Original post follows:

This is bad. It has been announced that Intel processors going back approximately ten years have a major flaw in how they separate the system and software. The details have not been released, but the general idea of the problem is already understood for the most part. To give a very high-level overview of what is going on and the impact of how it needs to be addressed, there is a component of every operating system known as a kernel, that separates the hardware from the software. When a program needs to open a port or save a file to disk or access a printer, or utilize hardware in any other way, it hands off that request to the kernel using what’s known as a system call, and the kernel completes the request (user mode to system mode). The catch is, the kernel is hidden from the program, even distributed in various memory locations to further hide it so that it can’t be exploited by malicious actors; it has to be loaded at system boot, however, in order for programs to use it.

Intel processors, though, use a kind of predictive processing, similar to client side prediction in games, in which a guess is made as to what will most likely happen next. In the case of Intel processors, they try to guess what code will be run next and load it up in the queue, however they apparently do this without any security procedures. The kernel is kept separate because it can contain confidential information such as passwords (which is why you can’t even get your own passwords back and there is no way to recover them if lost), however if the CPU provides no security check when loading up predictive code, it could, theoretically, run code that would ordinarily be blocked, which could then give savvy attackers access to low-level system processes and data.

But wait, there’s more bad news! Because this can’t be fixed with a firmware update or anything similar, OSs have to be written to address the problem. Linux, Windows, and OSX will all require updates that relocate the kernel in memory. Normally, it’s available to each program in their own process, but that will no longer be the case, and having to go back and forth between user mode and system mode in this manner will incur a possibly-significant performance hit on a PC after these updates, estimated by some to be as high as 30 percent.

Again, the details aren’t yet fully known, and the impact isn’t either, but if proven true it could be the worst design flaw I have ever seen. I’ll update when more is known.