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."
At one point, Forcefully Unmap Complete Kernel With Interrupt Trampolines, aka FUCKWIT, was mulled by the Linux kernel team, giving you an idea of how annoying this has been for the developers.
About par for Intel's course. Make it fast at the expense of horrible bugs.
Your hair look like poop, Bob! - Wanker.
Intel guys are doing the bulk of the work for the linux kernel changes, and I'm sure to be fair they'll equally cripple all processors with the changes not just their own.
Sorry for the lack of imagination, but if the user space process can only read kernel memory, and can't write to it, how could one make use of this?
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.
The developers behind the GRSecurity project measured up to 63% performance loss. If most common tasks are equally affected, Intel is sure fucked. Home users might not need to bother, but large cloud providers might be seriously affected.
Meanwhile the Linux kernel has received the largest incremental minor patch in its history (229KiB) - perhaps kernel 4.14.11 already contains all the required fixes.
I have a sneaking suspicion Intel shares will fall through the floor in the next few weeks because Intel CPUs might have suddenly become quite slower than their AMD Zen based counterparts.
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.
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?
And this comment. Someone could feel the storm coming.
KAISER: hiding the kernel from user space
Posted Nov 16, 2017 7:21 UTC (Thu) by alkbyby (subscriber, #61687) [Link]
Looks like something bad is coming. Such as mega-hole maybe in hardware that can be mitigated by hiding kernel addresses.
Otherwise I cannot see why simply hiding kernel addresses better, suddenly becomes important enough to spend massive amount of cpu on it.
- This isn't the first time. There was a problem a decade ago with Intel CPU's, when separate process threads could access each others data through cache memory.
Vintage computer adverts: http://www.vintageadbrowser.com/computers-and-software-ads
Results varied. Some workflows experienced a very significant performance loss however, e.g. Firefox became twice as slow, WinRAR four times as slow.
I'm curious how much Cannon Lake and Ice Lake CPU architectures are going to be delayed. Since Cannon Lake is basically SkyLake on a 10nm node, Intel cannot release it with such a glaring hole which causes such a significant performance loss.
I've been running a Sandy Bridge CPU for seven years now, and now I'm really looking forward to the second gen Zen CPUs. Viva, competition. I'm really glad AMD is still around.
https://www.fool.com/investing...
Less than a month before we know the linux kernel was being patched for this bug.
This is why we run our mission critical workloads on SPARC and Power along side Linux. Solaris and AIX. Diversity -- in operating system, in processor, in manufacturer - is healthy. The SPARC T8's are blazing faster, secure, and don't have this nonsense. Neither do our POWER8's. Having all your eggs in the Intel+Linux basket could be a major shitshow here... meanwhile, we'll keep chugging along.
really sorry to bust your ARM bubble. https://lwn.net/Articles/74039...
From the AMD commit:
this can probably be rewritten in the inverse like:
Intel processors ... allow memory references, including speculative references, that
access higher privileged data when running in a lesser privileged mode, [including]
when that access would result in a page fault.
So it seems like: set up a speculative memory reference to a kernel memory structure, cause a page fault, and then get a bit of kernel memory out (and back in?). That could get you root before long. Some people have been saying this can be leveraged to get a guest into its hypervisor too.
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
not you. thats's what the Linux team wanted to call this bug.
I read the El Reg article but I still don't understand what it is saying. At all levels. I don't understand if this means all intel processors or just the new ones. I don't understand if the 20% slowdown is for a tiny fraction of operations in the OS or if it means that things like e-mail, firefox or general python programming will be slowed down 20% overall. The latter would be a disaster. (could I ask intel to refund 20% of my computer costs?). And what's the consequences of not patching? Is the OS unstable or not use memory efficiently or "just" a security hole?
Some drink at the fountain of knowledge. Others just gargle.
You're over generalizing. You're also assuming people are playing games that are console ports. I play a few games that are already CPU limited. There are also a few popular titles that are cpu intensive. PUBG being a big one right now. I'm not saying this fix is going to make it worse, as I don't know. But, a huge hit to CPU performance would make a huge impact on those games.
If you're provided three options, and only three options, you're forced to pick one. Inaction is a choice that would force at least one of the options.
Cue the lawyers to initiate class action lawsuits against Apple once they release their patches to deliberately slow down older machines in the face of a hardware limitation.
To reduce crime, make fewer things against the law.
Leaving stale ones is often fine. FreeBSD does this intentionally in the transparent superpage promotion. When it condenses adjacent pages into a single superpage in the page tables, it doesn't invalidate the TLB entries. The exact behaviour of this varies between CPUs. When you get a TLB miss in an adjacent address range, it's filled from the superpage entry and now you have two TLB entries for the same virtual address[1]. Intel will just discard the smaller one, Centaur will note the mismatch, invalidate both, and refill from the page table, gem5 will crash (I think we've upstreamed the fix for this), and I'm not sure what AMD does.
Your example is highly unlikely, because the kernel typically reserves the top half of the address space for itself and an attempt by userspace to map anything in this range will fail. On x86 chips, there's a huge gap in the middle of the address space (it actually makes more sense to think of virtual addresses as signed values, with userspace ones being positive, kernel ones being negative, and the size of the number somewhat less than 64 bits [microarchitecture specific]). The kernel map, by default, will include the entire userspace portion of the address space for the current process, so that copies between kernel and userspace are cheap.
This kind of TLB invalidate is actually cheap on AMD, because they implement a tagged TLB with the cr3 value as the tag, so swapping cr3 values implicitly invalidates the TLB, but the entries become valid again when you reset the entry. The PCID feature, which is apparently the cause of this vulnerability, is largely a result of the fact that AMD patented this technique and so Intel doesn't use it.
[1] Some old SPARC chips would literally catch fire if you did this: the TCAMs would run hot enough to burn.
I am TheRaven on Soylent News
If I bought a car with X horsepower, and suddenly something was found wrong with it and it had to be modified to work, and was suddenly X - 10%, I'd expect compensation.
Funnily enough people are bringing a class action lawsuit for exactly this against Volkswagen after a fix to the emissions cheat reduced the power of their cars.
I don't know, but maybe he runs an high performance computing (HPC ) cluster.
With compute nodes segregated on a separate network that might not even have internet access,
and certainly not running random javascripts downloaded from random websites.
And in these context, performance matters a lot,
while security is handled in a "perimeter" fashion.
In those cases, it makes sense to have an option to disable the fix.
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
"you cut 30% off the performance of my CPU expect to hear about it.
--
Hi! I make Firefox Plug-ins. Check 'em out @ https://addons.mozilla.org/en-..."
I can't be the only person who sees the irony of a person complaining about performance degradation and that they make Firefox plug-ins in the same post.
~Any apparent grammatical or typographic errors are caused by defects in your display device.