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."
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?
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.
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.
No. On modern processor running in protected mode, all memory is virtual. Memory pages that appear contiguous could be backed up by NON-contiguous areas of physical memory, device i/o space, numa, swap, etc. This bug may affect any memory access in userspace.
OK about the second part. The first part is a matter of opinion ;-)
Glad my latest computer is a Raspberry Pi. Glad to be on an ARM processor. Perhaps this will help more ARM based computers become more mainstream this year.
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)
By "virtual memory" are we talking Page Files and swap space?
Almost. The difference is a minor or major page fault. From swap space to ram to CPU cache is a major page fault whereas a memory transfer is between the CPU cache (L1,L2 or L3) and system RAM is a minor page fault.
Disk space as memory?
No. Between CPU cache and system RAM. In this case the issue relates to minor page faults which occur when the CPU scheduler is switching tasks, called "context switching", between processes, threads and lwt running on the system.
The kernel maintains a summary page of the process when it switches tasks so that it doesn't have to recreate details of the process and is more efficient when it switches tasks. It is this summary page that can be attacked and IIUC addresses can be changed to access memory the process does not have permission to access.
This means that a process running in the userspace of Ring 3 of the CPU it can modify it's summary table to access data in Ring 0, where the kernel is. Which is obviously bad because now that process can access all the memory.
So an almost unusuable computer becomes completely unusable. Unless you're on solid state, then you get the performance of a mechanical hdd.
Maybe, but not how you would expect. The CPU scheduler *may* make it possible to hide some of the latency created by the now crippled context switching in mechanical disk latency that you can't do with ssd because of the way IO determines *when* the scheduler will context switch. Still early days and it depends on what techniques can be devised. It depends on where the summary tables are maintained and I would expect that to be in CPU cache, which is much faster than system RAM, which is why it is a tough bug to get around.
With that in mind it's plain to see why the Linux kernel devs want to call the patch fuckwit_ because Intel screwed up badly on this.
My ism, it's full of beliefs.
Having done a fair amount of both, I would disagree. The things that make software complex are dynamic: you can dynamically create threads and you can dynamically allocate memory, which makes the number of possible interactions almost impossible to statically reason about. In a CPU, all of these things are bounded and (very) finite, to the extent that it is actually possible to apply formal methods to the design (Centaur in collaboration with UT Austin do some amazing work in this area).
The difference is that a bug in software can usually[1] be fixed after you ship, whereas a bug in silicon usually can't (though if you've got a lot of microcode you can sometimes work around it). ARM has a nice chart of the cost of fixing a bug at each stage in development, which becomes more and more terrifying, whereas for software that cost is roughly flat, so you can get away with spending a lot less effort on correctness.
[1] Though not always easily. A colleague of mine released his first CVE a couple of years ago for a small library he wrote a couple of decades back. It turns out that most deployments of this library are in fax machines and printers, with no software update mechanism.
I am TheRaven on Soylent News
When it comes to the C compiler, Intel puts some things behind microarchitecture tests because in the past they didn't and people complained. They enabled fast paths after doing feature checks and it turned out that a bunch of x86 chips implemented certain instructions, but in microcoded slow paths and the optimised icc version that used them ran a lot slower than the version that didn't. As a result, they only enable certain instructions on chips that they have tested and which run faster when those instructions are used. And then people complained that they weren't doing optimisations on their competitors chips...
In this case, there is a vulnerability affecting a bunch of x86 processors, they issued a patch for x86 processors. This is exactly the right thing to do for a security issue: blanket enable and then whitelist safe CPUs.
I am TheRaven on Soylent News
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
This, I don't completely understand the reasoning for crippling all processors, including non-intel. It seems Intel is trying to use its political clout to reduce everyone's performance with a bunch of fear and scare tactics which just tops the charts for 2017 and 2018, just so they don't lose their edge. This is just an utter catastrophe for Intel and they're trying to drag the rest of us with them.