from the small-price-to-pay dept.
UPDATE 2: (martyb)
This still-developing story is full of twists and turns. It seems that Intel chips are definitely implicated (AFAICT anything post Pentium Pro). There have been various reports, and denials, that AMD and ARM are also affected. There are actually two vulnerabilities being addressed. Reports are that a local user can access arbitrary kernel memory and that, separately, a process in a VM can access contents of other virtual machines on a host system. These discoveries were embargoed for release until January 9th, but were pre-empted when The Register first leaked news of the issues.
At this time, manufacturers are scrambling to make statements on their products' susceptibility. Expect a slew of releases of urgent security fixes for a variety of OSs, as well as mandatory reboots of VMs on cloud services such as Azure and AWS. Implications are that there is going to be a performance hit on most systems, which may have cascading follow-on effects for performance-dependent activities like DB servers.
To get started, see the very readable and clearly-written article at Ars Technica: What’s behind the Intel design flaw forcing numerous patches?.
Google Security Blog: Today's CPU vulnerability: what you need to know.
Google Project Zero: Reading privileged memory with a side-channel, which goes into detail as to what problems are being addressed as well as including CVEs:
So far, there are three known variants of the issue:
- Variant 1: bounds check bypass (CVE-2017-5753)
- Variant 2: branch target injection (CVE-2017-5715)
- Variant 3: rogue data cache load (CVE-2017-5754)
Before the issues described here were publicly disclosed, Daniel Gruss, Moritz Lipp, Yuval Yarom, Paul Kocher, Daniel Genkin, Michael Schwarz, Mike Hamburg, Stefan Mangard, Thomas Prescher and Werner Haas also reported them; their [writeups/blogposts/paper drafts] are at:
During the course of our research, we developed the following proofs of concept (PoCs):
- A PoC that demonstrates the basic principles behind variant 1 in userspace on the tested Intel Haswell Xeon CPU, the AMD FX CPU, the AMD PRO CPU and an ARM Cortex A57 . This PoC only tests for the ability to read data inside mis-speculated execution within the same process, without crossing any privilege boundaries.
- A PoC for variant 1 that, when running with normal user privileges under a modern Linux kernel with a distro-standard config, can perform arbitrary reads in a 4GiB range  in kernel virtual memory on the Intel Haswell Xeon CPU. If the kernel's BPF JIT is enabled (non-default configuration), it also works on the AMD PRO CPU. On the Intel Haswell Xeon CPU, kernel virtual memory can be read at a rate of around 2000 bytes per second after around 4 seconds of startup time. 
- A PoC for variant 2 that, when running with root privileges inside a KVM guest created using virt-manager on the Intel Haswell Xeon CPU, with a specific (now outdated) version of Debian's distro kernel  running on the host, can read host kernel memory at a rate of around 1500 bytes/second, with room for optimization. Before the attack can be performed, some initialization has to be performed that takes roughly between 10 and 30 minutes for a machine with 64GiB of RAM; the needed time should scale roughly linearly with the amount of host RAM. (If 2MB hugepages are available to the guest, the initialization should be much faster, but that hasn't been tested.)
- A PoC for variant 3 that, when running with normal user privileges, can read kernel memory on the Intel Haswell Xeon CPU under some precondition. We believe that this precondition is that the targeted kernel memory is present in the L1D cache.
According to a report in Barron's:
AMD said through a spokesperson:
There is a lot of speculation today regarding a potential security issue related to modern microprocessors and speculative execution. As we typically do when a potential security issue is identified, AMD has been working across our ecosystem to evaluate and respond to the speculative execution attack identified by a security research team to ensure our users are protected.
To be clear, the security research team identified three variants targeting speculative execution. The threat and the response to the three variants differ by microprocessor company, and AMD is not susceptible to all three variants. Due to differences in AMD’s architecture, we believe there is a near zero risk to AMD processors at this time. We expect the security research to be published later today and will provide further updates at that time.
UPDATE 1: (takyon)
Original story follows
It appears that all modern Intel processors contain a hardware-level security flaw. Details are being suppressed while patches are developed, but it appears that a user process can put a reference to a privileged address in speculative execution, and thereby bypass privilege restrictions.
Since simply marking certain areas of the virtual memory space as privileged is insecure, operating systems will have to completely isolate their kernels, i.e., remove them from the virtual memory space of user processes. This will make context switching more expensive. Presumably, every OS call will now require swapping out the virtual memory map and flushing the page tables cache in the processor. Twice: one to go to the kernel, and once to return to the user process. This will be a significant performance hit: depending on the application, up to 30%.
This is apparently an Intel-specific bug; processors by other manufacturers are not affected. However, they may still suffer the performance hit: The changes to the OS are substantial, and it seems unlikely that OS manufacturers will, in the long-term, maintain two completely different kernel-access strategies for different processors.
A bug that affects Intel processors requires Kernel Page Table Isolation in order to be mitigated:
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.
The fix could dramatically lower performance for some workloads:
The Python Sweetness blog, which first reported on the bug, said the vulnerability was first identified by developers working on the Linux kernel, though it also affects Windows operating systems. It added that a number of major security patches for the Linux kernel have been pushed out over the Christmas and New Year holidays, which are likely to be an attempt to fix the new bug. These kernel updates have provided a workaround that can prevent attackers from exploiting the bug, but the problem is that doing so comes at a heavy cost. In technical terms, the fix involves using Kernel Page-Table Isolation or PTI to restrict processes so they can only access their own memory area. However, PTI also affects low-level features in the hardware, resulting in a performance hit of up to 35 percent for older Intel processors.
[...] "Urgent development of a software mitigation is being done in the open and recently landed in the Linux kernel, and a similar mitigation began appearing in NT kernels in November," the Python Sweetness blog reported Monday. "In the worst case the software fix causes huge slowdowns in typical workloads." These slowdowns were highlighted by Brad Spengler, lead developer of grsecurity, which is a set of patches for the Linux kernel which emphasize security enhancements. According to HotHardWare, Spengler said an Intel Core i7-3770S GPU will take a 34 percent performance hit, while the new Intel Core i7-6700 will run 29 percent slower.
The Linux fix can be disabled, which you will likely want to do if you use an AMD processor.
December 19, 2017: Intel's CEO Just Sold a Lot of Stock
Did Krzanich use that money to buy AMD stock?
An Anonymous Coward contributed Prefetch Side-Channel Attacks: Bypassing SMAP and Kernel ASLR.
Spotted over on HN:
tl;dr: there is presently an embargoed security bug impacting apparently all contemporary CPU architectures that implement virtual memory, requiring hardware changes to fully resolve. Urgent development of a software mitigation is being done in the open and recently landed in the Linux kernel, and a similar mitigation began appearing in NT kernels in November. In the worst case the software fix causes huge slowdowns in typical workloads. There are hints the attack impacts common virtualization environments including Amazon EC2 and Google Compute Engine, and additional hints the exact attack may involve a new variant of Rowhammer.
Turns out 2018 might be more interesting than first thought. So grab some popcorn and keep those systems patched!
With the recent brouhaha about vulnerabilities in many relatively recent processors, I got to thinking back to the time when I first started programming. Back then, things seemed so much simpler and much more straightforward.
To start off the new year, I thought it might be interesting to find out how people got their start in programming.
My first exposure to programming was by means of a Teletype over a dialup line using an acoustical coupler to a PDP-8 computer running TSS/8 and which had 24 KB of RAM. At the time, Star Trek ToS was on the air, and I thought this was the new, big thing. I was quickly disappointed by it not measuring up to anything like what I saw on TV, but I saw it had promise. Started with BASIC (and FOCAL). Later on was exposed to a PDP-11 running RSTS/E and programmed in BASIC+ as well as some Pascal.
As for owning a computer, the first one I bought was an OSI[*] Challenger 4P with a whopping 4KB of RAM!
From those humble beginnings, I ate up everything I could lay my hands on and later worked for a wide variety of companies that ranged in size from major internationals to tiny startups. Even had a hand in a project for Formula 1!
So, my fellow Soylentils, how did you get started programming? Where has it taken you?
[*] One day when my girlfriend came over and saw the OSI logo on my computer her eyes got huge! You see, The Six Million Dollar Man was on television at that time, and she suddenly suspected I was connected to the "Office of Scientific Intelligence"!
Google security researchers have come to the conclusion that speculative execution attacks are here to stay without drastic changes to modern CPU architectures, such as removing speculative execution entirely.
Patch for Intel Speculative Execution Vulnerability Could Reduce Performance by 5 to 35% [Update: 2]
Qualcomm Joins Others in Confirming its CPUs Suffer From Spectre, and Other Meltdown News
Congress Questions Chipmakers About Meltdown and Spectre
What Impact Has Meltdown/Spectre Had on YOUR Systems?
Intel Admits a Load of its CPUs Have Spectre V2 Flaw That Can't be Fixed
Intel FPU Speculation Vulnerability Confirmed
New Spectre Variant SpectreRSB Targets Return Stack Buffer
Intel Discloses a Speculative Execution Attack in Software Guard eXtensions (SGX)
Intel 'Gags' Linux Distros From Revealing Performance Hit From Spectre Patches
MIT Researchers Claim to Have a Solution for Some Speculative Execution Attacks
Spectre, Meltdown Researchers Unveil 7 More Speculative Execution Attacks
New Side-Channel Leak: Researchers Attack Operating System Page Caches
Arthur T Knackerbracket has found the following story:
Qualcomm has confirmed its processors have the same security vulnerabilities disclosed this week in Intel, Arm and AMD CPU cores this week.
The California tech giant picked the favored Friday US West Coast afternoon "news dump" slot to admit at least some of its billions of Arm-compatible Snapdragon system-on-chips and newly released Centriq server-grade processors are subject to the Meltdown and/or Spectre data-theft bugs.
[...] Qualcomm declined to comment further on precisely which of the three CVE-listed vulnerabilities its chips were subject to, or give any details on which of its CPU models may be vulnerable. The paper describing the Spectre data-snooping attacks mentions that Qualcomm's CPUs are affected, while the Meltdown paper doesn't conclude either way.
[...] Apple, which too bases its iOS A-series processors on Arm's instruction set, said earlier this week that its mobile CPUs were vulnerable to Spectre and Meltdown – patches are available or incoming for iOS. The iGiant's Intel-based Macs also need the latest macOS, version 10.13.2 or greater, to kill off Meltdown attacks.
SoylentNews first reported the vulnerabilities on January 3. Since then, we have had a few stories addressing different reports about these vulnerabilities. Now that it is over two weeks later and we are *still* dealing with reboots, I am curious as to what our community's experience has been.
What steps have you taken, if any, to deal with these reports? Be utterly proactive and install every next thing that comes along? Do a constrained roll out to test a system or two before pushing out to other systems? Wait for the dust to settle before taking any steps?
What providers (system/os/motherboard/chip) have been especially helpful... or non-helpful? How has their response affected your view of that company?
What resources have you been using to check on the status of fixes for your systems? Have you found a site that stands above the others in timeliness and accuracy?
How has this affected your purchasing plans... and your expectations on what you could get for selling your old system? Are you now holding off on purchasing something new?