• AnyStream is having some DRM issues currently, Netflix is not available in HD for the time being.
    Situations like this will always happen with AnyStream: streaming providers are continuously improving their countermeasures while we try to catch up, it's an ongoing cat-and-mouse game. Please be patient and don't flood our support or forum with requests, we are working on it 24/7 to get it resolved. Thank you.

Meltdown & Spectre potpourri

I read about this yesterday but was too busy to get around to posting. Some sad humour.

Operating systems that mishandle this debug exception and had their systems open to attacks include Apple, Microsoft, FreeBSD, Red Hat, Ubuntu, SUSE Linux, and other Linux distros based on the Linux Kernel —which is also affected.

Further, the issue also made it into virtualization software like VMWare and Xen. CERT/CC has a page dedicated to the patch status of each affected vendor.

Fixing the bug and having synchronized patches out by yesterday was an industry-wide effort, one that deserves praises, compared to the jumbled Meltdown and Spectre patching process.
The issues seems to be that by misinterpreting Intel’s incomplete documentation for these instructions, the OS vendors were allowing instructions such as SYSCALL, SYSENTER, INT 3, and others that transfer control to the operating system at Current Privilege Level (CPL) < 3 to follow the MOV SS and POP SS instructions.

This would result in an unexpected behavior by allowing Ring 3 user-level applications to control the kernel Ring 0 system level. In other words, malicious apps would be able to gain control of lower-level components of the system to bypass other security protections and steal sensitive memory information.

This relates to CVE-2018-8897:

 
"And the hits keep on coming."

This news started rolling out in the last few days.

Mitre CVE: CVE-2018-3639 - Speculative Store Bypass (SSB) - also known as Variant 4


From the MacRumors article:

According to Intel, the new vulnerability has a "moderate" severity rating because many of the exploits that it uses have already been addressed through mitigations that were first introduced by software makers and OEMs in January for Meltdown and Spectre. Intel is, however, releasing a full mitigation option that will "prevent this method from being used in other ways."

"This additional mitigation for Variant 4 has been delivered in beta form to OEM system manufacturers and system software vendors, and Intel is leaving it up to its partners to decide whether or not to implement the extra measures. Intel plans to leave the mitigation set to off by default because of the potential for performance issues."

This mitigation will be set to off-by-default, providing customers the choice of whether to enable it. We expect most industry software partners will likewise use the default-off option. In this configuration, we have observed no performance impact. If enabled, we've observed a performance impact of approximately 2 to 8 percent based on overall scores for benchmarks like SYSmark(R) 2014 SE and SPEC integer rate on client1 and server2 test systems.

Edit: This may or may not be related to a previously disclosed newer vulnerability. I'm losing track at this point.
 
Last edited:
Does this mean more performance hits in I/O for intel?. Already took 18% hit
 
Does this mean more performance hits in I/O for intel?. Already took 18% hit

The mitigation added in the firmware update will be defaulted to off. Yes, when enabled it WILL hurt performance. Again. When the mitigation is turned off there is no hit.
 
Also from the MacRumors article:

According to Intel, the new vulnerability has a "moderate" severity rating because many of the exploits that it uses have already been addressed through mitigations that were first introduced by software makers and OEMs in January for Meltdown and Spectre. Intel is, however, releasing a full mitigation option that will "prevent this method from being used in other ways."

In essence, if you already have prior Meltdown & Spectre mitigations via BIOS updates and OS updates then it is addressed... mostly. According to Intel. However, they are going to release a full mitigation but since it'll hand everyone yet another performance hit they are making it optional... for now until the other shoe drops.
 
Required? Definitely not. With the bios updates (microcode patches) and the ones in the OS itself your adequately protected. Intel is working on a revised CPU architecture that will have hardwired protection. Just don't know if that's going to be in the 8th gen Core i processors or the 9th.

Sent from my Nexus 6P with Tapatalk
 
@DrinkLyeAndDie after Intel and others have completed their analysis of the hardware issues do you think we will be required to get a new computer or will replacement boards be available? Thanks for your vigilance and reporting on this saga.

This is actually a complicated answer. It's not simply a yes or no question. It depends on the application of the system in question and how dangerous having the vulnerability is on the system. Is it a business machine (ie banking) or simply a home user? Who has more to lose and what will the repercussions be?

I doubt it will happen for numerous reasons but I'd love to see re-designs that protect against such vulnerabilities that would still fit the same socket and be usable in existing motherboards. IOW, I'd like to see a new protected LGA 1151 CPU that can actually be used in my Z170 motherboard. I am currently running a Skylake 6700K which the Z170 is targeted at but if I wanted I could run a Kaby Lake 7700K which is also LGA 1151 but I can't run a Coffee Lake 8700K which is also LGA 1151. I seriously doubt that any redesigns even if they are LGA 1151 will work in older motherboards like the Z170. Thanks, Intel. If I am wrong then I'll be happy and amazed but, wow, will I be shocked. It's the right thing to do but since when does that matter?
 
Last edited:
Haven't seen this discussed elsewhere but I found it interesting. This relates to the AMD Epyc processors.

The Register: Researchers crack open AMD's server VM encryption

A group of German researchers have devised a method to thwart the VM security in AMD's server chips.

Dubbed SEVered (PDF), the attack would potentially allow an attacker, or malicious admin who had access to the hypervisor, the ability to bypass AMD's Secure Encrypted Virtualization (SEV) protections.

The problem, say Fraunhofer AISEC researchers Mathias Morbitzer, Manuel Huber, Julian Horsch and Sascha Wessel, is that SEV, which is designed to isolate VMs from the prying eyes of the hypervisor, doesn't fully isolate and encrypt the VM data within the physical memory itself.

AMD did not respond to a request for comment on the study, but the researchers note that there are a few steps the chipmaker could take to isolate the transition between the host and guest physical address process.

"The best solution seems to be to provide a full-featured integrity and freshness protection of guest-pages additional to the encryption, as realized in Intel SGX. However, this likely comes with a high silicon cost to protect full VMs compared to SGX enclaves," they explain.
 
ThreatPost: Intel’s ‘Virtual Fences’ Spectre Fix Won’t Protect Against Variant 4

Spectre and Meltdown fixes for Intel chips announced in March, to be embedded into new CPUs, do not address the newly disclosed Variant 4, sources said.

Intel introduced hardware-based safeguards to its new chips to protect against the Spectre and Meltdown flaws that rocked the silicon industry when the vulnerabilities were made public in early 2018. However, those protections are specific to V2 and V3, and will not impact the newly-discovered Variant 4 as well as other potential speculative execution side channel-related flaws in the future, sources familiar with the situation told Threatpost.

That said, chip experts familiar with the situation said that while these “protective walls” will not impact Variant 4, Intel has added a functionality into its microcode – the Speculative Store Bypass Disable (SSBD) bit – to protect against Variant 4. This functionality will continue to be utilized on future hardware platforms.

[...]
 
Built intel8700k did some 4k tests. Thru-put is 920mb/s read and write on 2 500g blue wd ssd m2 n raid 0. So these patches have no effect on my max hero x and Intel 8700k chip. Glad I went Intel. Fast pc for 4k ripping. I'm in heaven now
 
Phoronix: CVE-2018-3665: Lazy State Save/Restore As The Latest CPU Speculative Execution Issue

The latest speculative execution vulnerability affecting modern CPUs has now been made public: Lazy State Save/Restore, a.k.a. CVE-2018-3665.

This vulnerability concerns saving/restore state when switching between applications. The newly-disclosed vulnerability exploits lazy-state restores for floating-point state when context switching, which is done as a performance optimization, to obtain information about the activity of other applications on the system.

[...]

... Update: Additional information is now available here via the researchers that uncovered the issue. It looks like recent Linux kernel users where eagerfpu defaults to enabled by default are covered. Additionally, the performance impact of that default kernel change was expected to cause no major performance hit, though I'll run some eagerfpu comparison benchmark runs with the latest kernel to see how it performs (that change happened back in 2016).

The Register: Intel chip flaw: Math unit may spill crypto secrets to apps – modern Linux, Windows, BSDs immune

A security flaw within Intel Core and Xeon processors can be potentially exploited to swipe sensitive data from the chips' math processing units.

Malware or malicious logged-in users can attempt to leverage this design blunder to steal the inputs and results of computations performed in private by other software.

These numbers, held in FPU registers, could potentially be used to discern parts of cryptographic keys being used to secure data in the system. For example, Intel's AES encryption and decryption instructions use FPU registers to hold keys.

In short, the security hole could be used to extract or guess at secret encryption keys within other programs, in certain circumstances, according to people familiar with the engineering mishap.

Modern versions of Linux – from kernel version 4.9, released in 2016, and later – and modern Windows, including Server 2016, as well as the latest spins of OpenBSD and DragonflyBSD are not affected by this flaw (CVE-2018-3665).

Windows Server 2008 is among the operating systems that will need to be patched, we understand, and fixes for affected Microsoft and non-Microsoft kernels are on their way. The Linux kernel team is back-porting mitigations to pre-4.9 kernels.

[...]

The Hacker News: New 'Lazy FP State Restore' Vulnerability Found in All Modern Intel CPUs
Mitre CVE: CVE-2018-3665
Bleeping Computer: New Lazy FP State Restore Vulnerability Affects All Intel Core CPUs
 
Fudzilla: Intel warns of lazy FP state restoration

While it is not as bad as Meltdown or Spectre the "Lazy FP state restoration exploitation" sounds like the chip is recovering from a big Sunday afternoon dinner.

Lazy FP state restoration is a means for developers to squeeze additional performance out of compatible Intel processor, but possible for software running on an operating system which uses Lazy FP switching to increase floating-point unit (FPU) performance to obtain access to data it should not, including cryptographic keys.

Amazon's Julian Stecklina and Cyberus Technology's Thomas Prescher found the bug earlier this year, and originally scheduled for public announcement in August until leaks pushed the announcement date up.

[...]

[...]

The vulnerability is exploitable only when the operating system is configured to use lazy rather than eager FPU switching instructions. For Windows, that was the case up until Microsoft released a patch switching to eager FPU switching earlier this week. Linux kernel version 4.9 is already protected, while backported patches are beginning to land for older but still supported kernel releases.

[...]
 
Interesting reading. This could definitely make for a brighter future in chip design.

arXiv - Cornell University Library: SafeSpec: Banishing the Spectre of a Meltdown with Leakage-Free Speculation

[...]

In this paper, we introduce a new model (SafeSpec) for supporting speculation in a way that is immune to side-channel leakage necessary for attacks such as Meltdown and Spectre. In particular, SafeSpec stores side effects of speculation in a way that is not visible to the attacker while the instructions are speculative. The speculative state is then either committed to the main CPU structures if the branch commits, or squashed if it does not, making all direct side effects of speculative code invisible. The solution must also address the possibility of a covert channel from speculative instructions to committed instructions before these instructions are committed. We show that SafeSpec prevents all three variants of Spectre and Meltdown, as well as new variants that we introduce. We also develop a cycle accurate model of modified design of an x86-64 processor and show that the performance impact is negligible. We build prototypes of the hardware support in a hardware description language to show that the additional overhead is small. We believe that SafeSpec completely closes this class of attacks, and that it is practical to implement.

The Register: Boffins offer to make speculative execution great again with Spectre-Meltdown CPU fix

[...]

The research, if validated and adopted, means more work for Intel and other chip makers.

"SafeSpec requires a deep redesign of the CPU to separate out the speculative state from the permanent state," the paper explains.

In a phone interview with The Register, Nael Abu-Ghazaleh, professor of computer science and engineering at UC Riverside and a co-author of the paper, said he believes SafeSpec can defend against the recently disclosed Lazy FP state bug affecting Intel math processors.

"Like the other variants of Spectre/Meltdown, the speculatively accessed floating point state would go to the shadow state, but not make it to the visible architectural state, preventing the attack," he said.

It also addresses another recently disclosed variant, Speculative Store Bypass (variant 4). "The good thing about it is it doesn't care about the source of the speculation," he said.

Abu-Ghazaleh acknowledged that SafeSpec requires some extra space on the L1 cache, but he considers the hardware changes to be minimal. And in terms of performance, he said, SafeSpec could even offer small improvements.

"I think it's really practical in terms of overhead," he said.

It's not a complete fix. As the paper acknowledges, other silicon structures affected by speculative instructions like the branch predictor and DRAM buffers also need to be fortified.

But it might just be better than past patches.
 
This has been talked about for a few days...

Ars Technica: Hyperthreading under scrutiny with new TLBleed crypto key leak

[...]

The previous focus for side-channel attacks has been the processor's data cache, a small piece of high-speed memory that's used to hold recently used data. TLBleed uses a new side channel: the processor's translation lookaside buffer (TLB).

[...]

[...]

The other feature of TLBleed is the one that caused the OpenBSD changes to be made. Processors with simultaneous multithreading (SMT) support two or more logical cores, each of which can run a thread, on each physical core. These logical cores share the physical core's resources, including the caches and the TLB. With the attacker program running on the same physical core as the victim program, these attacker can detect changes to the TLB as they're made.

The research looked at Intel processors with hyperthreading (Intel's name for SMT), but others may well be affected, too. AMD's Ryzen processors also have SMT, for example, and depending on how Ryzen's TLB works, they may be susceptible to similar attacks.

[...]

[...]

The Spectre and Meltdown attacks are particularly significant because they can be used to attack cloud infrastructure and because they've prompted hardware modifications to prevent the data leaks and close the side channels.

TLBleed doesn't seem likely to do the same. Ben Gras, one of the researchers, tweeted "don't panic" and said that TLBleed "is not the new Spectre." Just as was done for previously known side channels, encryption algorithms can be implemented such that their pattern of data accesses is the same regardless of the encryption key. Removing this variation removes the side channel. Gras said that implementations that do this are currently rare, but if it were done, TLBleed would no longer work.

This has provoked a rather dismissive response from Intel. Although the company operates a bug bounty program, it has declared that this problem isn't eligible for an award. Intel argues that countermeasures against cache side channels can also protect against TLBleed.

[...]
 
"The point is not merely to understand the world, but to change it."
"To win is meaningless. To lose is meaningless. To quit is inexcusable."
Yet your user name commands us to commit suicide in one of the most horrific ways possible.

Just seemed ironic.
 
Back
Top