Slashdot Mirror
'Kernel Memory Leaking' Intel Processor Design Flaw Forces Linux, Windows Redesign (theregister.co.uk)
According to The Register, "A fundamental design flaw in Intel's processor chips has forced a significant redesign of the Linux and Windows kernels to defang the chip-level security bug." From the report: Programmers are scrambling to overhaul the open-source Linux kernel's virtual memory system. Meanwhile, Microsoft is expected to publicly introduce the necessary changes to its Windows operating system in this month's Patch Tuesday: these changes were seeded to beta testers running fast-ring Windows Insider builds in November and December. Crucially, these updates to both Linux and Windows will incur a performance hit on Intel products. The effects are still being benchmarked, however we're looking at a ballpark figure of five to 30 per cent slow down, depending on the task and the processor model. More recent Intel chips have features -- specifically, PCID -- to reduce the performance hit. Similar operating systems, such as Apple's 64-bit macOS, will also need to be updated -- the flaw is in the Intel x86 hardware, and it appears a microcode update can't address it. It has to be fixed in software at the OS level, or buy a new processor without the design blunder. Details of the vulnerability within Intel's silicon are under wraps: an embargo on the specifics is due to lift early this month, perhaps in time for Microsoft's Patch Tuesday next week. Indeed, patches for the Linux kernel are available for all to see but comments in the source code have been redacted to obfuscate the issue. The report goes on to share some details of the flaw that have surfaced. "It is understood the bug is present in modern Intel processors produced in the past decade," reports The Register. "It allows normal user programs -- from database applications to JavaScript in web browsers -- to discern to some extent the contents of protected kernel memory. The fix is to separate the kernel's memory completely from user processes using what's called Kernel Page Table Isolation, or KPTI."
Linux Weekly News has been covering this for quite a while.
5% slowdown on average, with up to 30% for some particularly bad network operations.
ARM64 is also affected, so it's not just intel
-- Sometimes you have to turn the lights off in order to see.
Some PostgreSQL results have just been released: up to 23% performance loss. This is indeed huge.
I find it hard to believe that a virtual memory change will result in a 5-30% slowdown for Intel processors. Maybe for a few extremely specific (likely edge-case) tasks, but if there was a legitimate 5-30% performance decrease, you can bet there would be a far different solution in the works that would suitably fix the problem.
Virtual memory access is used in every single memory access cached or not. 5% would be lucky for trying to work around a broken system. I am guessing the flaw is probably in the TLB which is meant to accelerate these things.
Looks like you missed this commit from Tom Lendacky at AMD.
Doesn't look like it's everybody. https://lkml.org/lkml/2017/12/...
And what is interesting, AMD is immune to that, proof: https://lkml.org/lkml/2017/12/...
The summary is not fully explicit: this is not a flaw in Intel x86 ISA, but specific to CPUs made by Intel. AMD processors don't have the problem, so they should not need the patch.
https://lkml.org/lkml/2017/12/...
This could be a huge win for AMD, because the patch incurs a measurable slowdown. At the moment, though, the Linux fix doesn't seem to distinguish between manufacturers. I expect the distinction will appear later -- better safe than sorry.
Escher was the first MC and Giger invented the HR department.
some of my sys admin friends posted this on a slack channel i'm in, apparently it's a big deal
http://pythonsweetness.tumblr.com/post/169166980422/the-mysterious-case-of-the-linux-page-table
I came to the datacenter drunk with a fake ID, don't you want to be just like me?
AMD processors are not subject to the types of attacks that the kernel page table isolation feature protects against. The AMD microarchitecture does not allow memory references, including speculative references, that access higher privileged data when running in a lesser privileged mode when that access would result in a page fault.
The (trivial) patch essential disables the work-around on AMD CPUs. I'm not going to comment on how fair GP's criticism of Intel is in general, but that link definitely isn't evidence in Intel's favor
Linux users don't even need to compile a custom kernel (although if performance *really* matters you should probably be doing so as a matter of course) as there's a boot time option in the that can be set to disable the new Page Table Isolation mode, "nopti". Without knowing the performance hit for a specific usage case and the nature of the flaw its currently impossible to say whether using it is going to be a good idea or not, but it's nice that they at least thought to include the option. Pretty sure BSD will do the same, but feel free to place your bets on commercial operating system vendors...
UNIX? They're not even circumcised! Savages!
Actually, it's a reference to a hex value that could trigger a nasty Pentium bug.
Results varied. Some workflows experienced a very significant performance loss however, e.g. Firefox became twice as slow, WinRAR four times as slow.
F00F
This bug has been known and reported about since early November; the original paper was presented in July of 2017, and code has been in Github since Feburary.
Motley Fool is just noting that the Intel CEO isn't holding any more stock than he needs to.
And there are good reasons:
* AMD is back from the dead.
* Intel's GPU hasn't been that successful -- they've even teamed up with AMD to put Radeon GPU's in the same die as an Intel CPU.
* PC sales are declining as consumers shift from Intel PC's to using ARM-powered tablets & phones instead.
* ARM is making inroads into the "desktop and laptop computer" marketplace.
* ARM is powering most consumer electronics as well (TV's, Blu-ray players, Smart Speakers, etc)
* Intel is absolutely nowhere in the mobile world. Mobile has one ARM to rule them all.
* Intel missed the boat for the current generation of XBOX and PlayStation consoles.
Intel is looking more and more like a one trick pony, and its competitors are beginning to do that one trick better too.
-- Sometimes you have to turn the lights off in order to see.
Nope. Page Table Isolation is the fix and not the fault. But isolating the userland and kernel page tables means you have to switch between them each time you go from user mode to kernel mode and back. This slows things down.
AMD CPUs don't have the bug where user mode can read kernel pages so does not require this isolation and the performance hit caused by enabling it. From the AMD email: "The AMD microarchitecture does not allow memory references, including speculative references, that access higher privileged data when running in a lesser privileged mode when that access would result in a page fault."
I don't think you understand how drastic this fix is. Every time a user mode to kernel mode transition happens and every time a hardware interrupt happens, the entire page table directory layout has to be switched. This means all the TLB caches are flushed as well and that's where the main performance hit comes from.
So if you're doing something like crypto currency mining you're not going to see much of a hit. But if you're doing a lot of I/O (file servers, database servers, web servers, etc.) you're going to see that 25-35% performance hit.
And that's why hardware bugs are so serious. Sometimes you get lucky and it's a microcode update with no penalty. Sometimes it's a simple fix with barely any performance penalty. But sometimes you get unlucky and the fix hurts a lot and the only way to get the performance back is to swap out the hardware.
He confused me at first with the mention of VMs as, like you, I initially thought he was talking about Virtual Machines (especially given the context of cloud computing and hardware sharing). But he was actually talking about Virtual Memory. Not sure how he got from one topic to the other, but it's pretty clear:
"Memory is crazy cheap these days compared to your time and security and energy and wallet thickness; you should have lots and lots. If you don't, then there's your error."
really sorry to bust your ARM bubble. https://lwn.net/Articles/74039...
Every process runs in virtual address space--EVERY process. Low level device drivers on X86 might need to map to physical, but nearly everything is virtual. Certainly everything in user-mode.
This is why process 1 memory location 10000 is a different piece of physical ram from process 5 memory location 10000. Different virtual address spaces. Each such mapping between each virtual address space and physical space is stored in a "page table". (Pages might also not currently exist in physical ram and the OS handles that, e.g., load from disc, make up from scratch or whatever, but that's a separate discussion.)
The main cost of a context switch between processes is flushing the "TLB" (translation lookaside buffer) - it's essentially a cache of "for the current process, what virtual addresses map to what physical addresses".
Traditionally, OS's separated the virtual address space into 'Kernel' and 'User' portions. (Those of you that remember /3GB switch on NT know all about this.) This way, jumping into the Kernel is might lighter-weight than jumping between processes because the TLB is still valid and thus doesn't need flushing. The TLB's data about kernel address space is correct.
The performance hit is this turns every transition from user-to-kernel from "a quick update of the current privilege level" into a full "load new page table and full TLB flush" as the kernel no longer lives in the same virtual address space. This is a huge hit on every kernel call.
The only OS's that wouldn't be affected by this are ones that use a single address space; or already separate everything including their kernel into separate virtual address spaces. Maybe a microkernel OS isn't affected, and single-address-space things like Unikernels and (Microsoft Research's) Singularity wouldn't be. Non-protecting operating systems also wouldn't be affected as they don't have security to begin with--for example, FreeDOS which aims to still run on 8088 chips, doesn't have any kernel protection or multitasking so it cannot be affected.
I'm saying that Intel tried to cripple all processors but the dude from AMD told him their products weren't vulnerable and didn't need to be slowed down.
You've confused virtual address space for swap.
When it comes to intel C compiler, optimizations that would work on AMD chips are left out when compiling for that CPU, because "we wouldn't presume to know what would work and what wouldn't on a competitor's chip!"
Yet in this case, they presumed to know what was best for a competitor's chip.
Funny how the error always falls to Intel's favor. One might think it wasn't an error at all.