CPU Security Flaws MELTDOWN and SPECTRE

Note that Intel din't even mentioned the mitigations in the press briefing, they had to be specifically asked for any and all details
 
So, we can expect Intel PR do a 180 in a few months time when the new SKUs are available; From downplaying Spectre/Meltdown mitigation performance impacts to emphasizing how the new SKUs won't suffer massive performance degradation, thus forcing an upgrade cycle

I think it's more likely they just sell it as a performance upgrade, showing graphs of how the new CPUs are faster than the old ones (that have mitigations on ofc), without mentioning the bugs other than in the small print.
 
Your Hard Drive May Be Listening

For example, the team has shown that appropriate electromagnetic waves can cause a thermocouple—a sensor that produces a voltage to represent the temperature—to be read as showing 1847 degrees Fahrenheit when it was actually at room temperature. They similarly caused the voltage sensor in a pacemaker to provide inaccurate signals.

The researchers produced additional mayhem with sound waves, demonstrating that accelerometers in Fitbits, smart phones, and other devices are vulnerable. In one experiment, they showed that certain high-frequency sound waves can cause a Fitbit to add steps without moving. In another test, they used a specific acoustic waveform to force the graph of the voltage output of an accelerometer to spell out the word “WALNUT.” This waveform worked even when the sound was surreptitiously embedded in a sound track, so an attacker could, in principle, control your phone’s accelerometer by tricking you into watching an online video.

The team’s latest trick is to turn a hard drive into a microphone. They tapped into the feedback system that helps control the position of the read head above the magnetic disk. When the head is buffeted by sound waves, the vibrations are reflected in the voltage signal produced by the drive’s position sensors. By reading this signal, Fu and his colleagues were able to make high-quality recordings of people speaking near the drive.
 
New Spectre related exploits for Intel named "SPOILER".
[The researchers] have found that "a weakness in the address speculation of Intel’s proprietary implementation of the memory subsystem" reveals memory layout data, making other attacks like Rowhammer much easier to carry out.
The researchers also examined Arm and AMD processor cores, but found they did not exhibit similar behavior.
This security shortcoming can be potentially exploited by malicious JavaScript within a web browser tab, or malware running on a system, or rogue logged-in users, to extract passwords, keys, and other data from memory. An attacker therefore requires some kind of foothold in your machine in order to pull this off. The vulnerability, it appears, cannot be easily fixed or mitigated without significant redesign work at the silicon level.

Intel responds with:
Intel received notice of this research, and we expect that software can be protected against such issues by employing side channel safe development practices. This includes avoiding control flows that are dependent on the data of interest. We likewise expect that DRAM modules mitigated against Rowhammer style attacks remain protected. Protecting our customers and their data continues to be a critical priority for us and we appreciate the efforts of the security community for their ongoing research.
 
So Intels solution to its insecure memory stuff is to rely on software developers & fucking RAM manufacturers to fix it? o_O
 
So Intels solution to its insecure memory stuff is to rely on software developers & fucking RAM manufacturers to fix it? o_O

Actually, rowhammer is a RAM manufacturer problem. The reason why virtual-to-physical mapping is now believed to be better kept secret (from the process which owns the virtual address) is mostly because of rowhammer. If there's no rowhammer, it'd be practically a non-issue.
 
Why then were they unable to reproduce the vulnerability with ARM or AMD?

It doesn't matter. If there's no rowhammer, there's no point in hiding virtual-to-physical mapping from the running process. The fact that some ARM and AMD CPU (note that they don't actually test a lot of different ARM and AMD CPUs, so it's not clear whether newer ARM and AMD CPUs are actually immune) does not leak this information does not change that the whole thing would be a non-issue if there's no rowhammer.

The reason why CPU and OS have these protections against rowhammer is simply because there are just too many DRAM modules out there are susceptible to rowhammer and it can't be easily fixed. It does not change the fact that rowhammer is a design failure of DRAM modules, not CPU and OS. Once rowhammer resistant DRAM modules become widely available, it'd go back to be a non-issue.
 
So Intels solution to its insecure memory stuff is to rely on software developers & fucking RAM manufacturers to fix it? o_O
As previously noted, Rowhammer is a DRAM failure. In the past, bit upsets due to neighboring row accesses would have been a reason to fail DRAM at the factory, and when this was discovered the vulnerable products were not acting in accordance to their specifications. That people have moved to secondary mitigations or software is an indication that the DRAM products affected were too widespread to recall or that the reality going forward was that density would come at the price of discarding old standards of array reliability.

However, there are notable use cases for knowing the physical memory layout of data like IO, NVRAM (big reason why some key instructions exist), and high-performance code. Memory controllers and DRAM modules have limited ranges where they can provide sustained bandwidth and consistent latency based on the physical access patterns. As such, this is likely too important of a case for software to be denied knowledge of the physical address space. I think OS developers are trying to find ways of providing privilege levels for getting this information, which was something that could be queried or derived rather freely up until recently.
Besides, this is just one side channel. The cache hierarchies, TLBs, and page table layouts are perhaps further out from the memory reorder buffer, but they have well-documented and not-difficult channels for leaking physical address information. There's no likely change on the horizon for ripping out the x86 virtual memory architecture or changing all caches past the L1 to anything but physical addressing.

As far as counting on software with secret information to be modified to not have path selection based on hidden values, that's been standard cryptographic practice for decades. Secret values are not to be used by instructions or units whose behavior may change based on the contents, or the usage should be obfuscated by stalls or parallel make-work that creates external behavior that is indistinguishable. New side channels or missed exploits are usually reasons to change the code, since almost all execution outside of these limited exceptions considers this behavior to be unimportant, acceptable, or expected.

In that regard, certain attacks using physical address leaks would be worse on a system using AMD's recommended setup, since a subset of attacks are related to kernel address space mapping leaks fixed by the KAISER changes repurposed for Meltdown.


Why then were they unable to reproduce the vulnerability with ARM or AMD?
It can come down to specific implementation choices or the algorithm used.
There may also be northbridge or system-level mitigations for problematic patterns that might make such patterns more difficult to sustain, or might make leaking the physical mapping less impactful.

The AMD chip I saw listed was Bulldozer, whose specific OoO memory implementation was not really disclosed in years past. There could be corner cases that could correlate physical addresses that just differ from the subset of bits Intel used, or from my recollection discussion for Bulldozer's forwarding and disambiguation schemes were that they were more fragile or obscured by other architectural stalls and pitfalls. The weaker load/store pipeline and the unconventional write-through to a write-combining cache that spilled into an insufficient L2 could provide enough of a shadow to lose modest latency spikes versus a generally high-performance Intel scheme with an isolated set of longer mispredicts or a sub-optimal replay mechanism.
AMD's Zen has been tested to have a more robust speculation pipeline, although testing may be complicated by other forms of speculation that occur within the register file and renamer prior to getting out to the store queue. The store queue which would function using physical addresses and might have its own layer for speculation that could have a timing side channel.
The general case is that a subset of bits or a hash function using an unknown number of bits (likely >48 bits) is discussed, meaning there could be gaps that could be exploited to varying degrees if they were as well-known.

The ARM chip I saw listed was a Qualcomm version of the A73, which is just one ARM core of many. Of note, there is a different store to load forwarding mispredict exploit that AMD, Intel, ARM, and others do have exposure to in various products (variant 4) where measures for restricting speculation on store forwarding exist. Some ARM cores do have microcode changes to expose these methods, so they may have a somewhat different implementation for speculation.

Of the ARM vendors, I would be curious about Apple. For one thing, Apple's cores are significantly higher-performance, IOS products got Meltdown-related changes as well, and Apple and Intel ran into litigation surrounding the same memory disambiguation patent.
 
Intel VISA: Through the Rabbit Hole

The complexity of x86-based systems has become so great that not even specialists can know everything. The recently discovered Meltdown/Spectre vulnerabilities, as well as numerous issues in Intel Management Engine, underscore the platform's mindboggling intricacies. So, the chips manufacturer has to actively use of various means for manufacturing verification and post-silicon debugging.

We found that modern Platform Controller Hub (PCH) and CPU contain a full-fledged logic signal analyzer, which allows monitoring the state of internal lines and buses in real time—a gold mine for researchers. A vulnerability previously discovered by us, INTEL-SA-00086, enabled studying this technology, which is called Intel Visualization of Internal Signals Architecture (VISA). We believe it is used for manufacturing line verification of chips. With an enormous number of settings, VISA allows for the creating of custom rules for capturing and analyzing signals. VISA documentation is subject to an NDA and not available to ordinary users. However, we will show how, with the help of publicly available methods, one can access all the might of this technology WITHOUT ANY HARDWARE MODIFICATIONS on publicly available motherboards.

With VISA, we succeeded in partially reconstructing the internal architecture of PCH and, within the chip, discovered dozens of devices that are invisible to the user yet are able to access certain critical data. In our talk, we will demonstrate how to read signals from PCH internal buses (for example, IOSF Primary and Side Band buses and Intel ME Front Side Bus) and other security-sensitive internal devices.
 
The presentation slides go into more detail about the on-die fabric and significant debugging and trace capability.
There's a primary data fabric that extends PCIe semantics, connects IP blocks, and allows for third-party integration. There's a base fabric unit, various addressing methods, and bridges from the internal fabric to various external or legacy buses.
Much of this is reminiscent of another vendors more publicly marketed fabric.
There's also a sideband bus with more miscellaneous traffic and a JTAG bus for testing.

Various exploits attempt to set system variables to unlock an access level that can reach all levels of fabric, clients, and the signals and tracing available with the VISA infrastructure.
As noted, these are validation and testing tools for a complex and high-performance collection of internal systems.
Using this means local access and essentially running a setup for testing and validating the chip--whose wealth of tools and counters can give side-channel information or avenues for touching elements assumed inaccessible outside of a factory test-bench.
While there seems to be a fuse-based way of locking this out, it appears to be unset.

I'd be curious what methods other vendors have for this. All such chips would have some kind of infrastructure for validation and testing. Whether they lock things out with more layers of security or physical/electrical barriers like fusing is unclear.
As an example, when AMD's Ryzen chips were experiencing segfault errors, they were asking for chips to be returned. That could have been an opportunity to analyze what on-die elements were failing, or could serve such a role in any future post-launch problems.

Possibly, the desire for such a capability may explain why Intel and presumably others might not have made the cut-out for this kind of functionality physical.
 
New ZombieLoad attack discovered on Intel CPUs. Whitepaper discuss:

the ZombieLoad attack which uncovers a novel Meltdown-type effect in the processor’s previously unexplored fill-buffer logic. Our analysis shows that faulting load instructions (i.e., loads that have to be re-issued for either architectural or micro architectural reasons) may transiently dereference unauthorized destinations previously brought into the fill buffer by the current or a sibling logical CPU. Hence, we report data leakage of recently loaded stale values across logical cores. We demonstrate ZombieLoad’s effectiveness in a multitude of practical attack scenarios across CPU privilege rings, OS processes, virtual machines, and SGX enclaves. We discuss both short and long-term mitigation approaches and arrive at the conclusion that disabling hyperthreading is the only possible workaround to prevent this extremely powerful attack on current processors.

1OH7fHI.png


Looks like everything since sandy bridge until kaby lake is affected.

The demo on the official site is extremely scary, it shows leaking info through an VM on TOR
 
Last edited:
New Win 10 update has further Spectre related fixes https://support.microsoft.com/en-nz/help/4494441/windows-10-update-kb4494441
  • Enables “Retpoline” by default if Spectre Variant 2 (CVE-2017-5715) is enabled. Make sure previous OS protections against the Spectre Variant 2 vulnerability are enabled using the registry settings described in the Windows Client and Windows Server articles. (These registry settings are enabled by default for Windows Client OS editions, but disabled by default for Windows Server OS editions). For more information about “Retpoline”, seeMitigating Spectre variant 2 with Retpoline on Windows.
  • Provides protections against a new subclass of speculative execution side-channel vulnerabilities, known as Microarchitectural Data Sampling, for 64-Bit (x64) versions of Windows (CVE-2019-11091, CVE-2018-12126, CVE-2018-12127, CVE-2018-12130). Use the registry settings as described in the Windows Client and Windows Server articles. (These registry settings are enabled by default for Windows Client OS editions and Windows Server OS editions).
 
So I've been reading a perf hit from ZombiLoad around 3% for desktop and up to 9% for datacenter. Some specific workloads on Mac being hit up to 40%.

Those of us with VPS are being shafted more and more over time as additional fixes are applied by hosts. Maybe Intel should pay for all hosts around the world to bump up all their clients one perf level.
 
I haven't followed closely, so can someone gauge the following statement I saw on other forums for truthiness?
  • One of the fixes/patches disables HyperThreading thus downgrading i7's to i5's with major financial impact considering the premium Intel charges between the models.
 
I haven't followed closely, so can someone gauge the following statement I saw on other forums for truthiness?
  • One of the fixes/patches disables HyperThreading thus downgrading i7's to i5's with major financial impact considering the premium Intel charges between the models.
From what I've read so far, ChromeOS is disabling HT in its next update.
 
Back
Top