Security Intel Processor Flaw 'kernel memory leaking' [Spectre & Meltdown]

eva2000 · Mar 24, 2018

Meltdown & Spectre: Analyzing Performance Impacts on Intel's NUC7i7BNH

What we've found so far is that the impact of the Meltdown and Spectre patches varies with the workload and the type of test. Nate's GPU testing shrugs it off almost entirely, while Billy's SSD testing especially feels the pinch. In the middle of course are consumer system reviews, where workloads are more varied but also much more realistic and often more relevant as well. Of course, this is also the type hardware that we most often have to return when we're done, making it the most challenging to correct.

As everyone at AnandTech has been integrating the patches and updating their datasets in their own way, I wanted to offer some insight into what's going on for system testing. With several important systems set to launch in the first half of this year – particularly Intel's Hades Canyon – I've been going back and collecting updated results for use in those future reviews. In the process, I also wanted to document how performance has been impacted by these security patches and which benchmarks in particular have been affected.
Click to expand...

eva2000 · Mar 26, 2018

Linux 3.17 To Linux 4.16 Kernel Benchmarks On Intel Gulftown & Haswell Hardware - Phoronix

Every major kernel release was tested as we see how the Linux kernel performance has evolved on these Haswell and Gulftown systems since October 2014.
Click to expand...

eva2000 · Mar 29, 2018

Bad Microsoft Meltdown Patch Made Some Windows Systems Less Secure

Fisk, a Swedish IT security expert, reported on Tuesday that Microsoft made a fatal mistake in January with a botched patch that allowed malicious apps or a local user to access protected kernel memory and steal passwords and personal information from Windows 7 (64-bit) and Server 2008 R2 machines. No other Windows OS version is impacted.

Microsoft corrected the error in its March Patch Tuesday update.
Click to expand...

eva2000 · Apr 1, 2018

More Windows Server vs. Linux Benchmark Tests With Spectre/Meltdown Mitigations - Phoronix

This latest round of tests were done with an Intel Xeon E3-1280 v5 Skylake system with MSI C236A WORKSTATION motherboard (BIOS 2.90, the latest as of testing, released in December) with 16GB of RAM and 256GB Toshiba RD400 NVMe SSD.

While using the latest BIOS, unfortunately MSI has not released an updated BIOS with the latest CPU microcode for dealing with Spectre. As a result, all that Windows Server 2016 offers is kernel VA Shadow support as its approach to mitigating Meltdown. Branch target injection mitigation couldn't be enabled due to the BIOS/microcode. So on that front Windows Server 2016 was tested with/without VA Shadow being enabled while using the latest Windows Server 2016 Essentials Build 14393.
Click to expand...

eva2000 · Apr 4, 2018

As some folks have guessed, some Intel cpus can not be fixed for Spectre v2 vulnerability and some cpus Intel won't be fixing for Meltdown either Intel admits a load of its CPUs have Spectre v2 flaw that can't be fixed

Intel has issued new a new "microcode revision guidance" that confesses it won’t address the Meltdown and Spectre design flaws in all of its vulnerable processors – in some cases because it's too tricky to remove the Spectre v2 class of vulnerabilities.

The new guidance, issued April 2, adds a “stopped” status to Intel’s “production status” category in its array of available Meltdown and Spectre security updates. "Stopped" indicates there will be no microcode patch to kill off Meltdown and Spectre.

The guidance explains that a chipset earns “stopped” status because, “after a comprehensive investigation of the microarchitectures and microcode capabilities for these products, Intel has determined to not release microcode updates for these products for one or more reasons.”

Those reasons are given as:

Micro-architectural characteristics that preclude a practical implementation of features mitigating [Spectre] Variant 2 (CVE-2017-5715)

Limited Commercially Available System Software support

Based on customer inputs, most of these products are implemented as “closed systems” and therefore are expected to have a lower likelihood of exposure to these vulnerabilities.

Thus, if a chip family falls under one of those categories – such as Intel can't easily fix Spectre v2 in the design, or customers don't think the hardware will be exploited – it gets a "stopped" sticker. To leverage the vulnerabilities, malware needs to be running on a system, so if the computer is totally closed off from the outside world, administrators may feel it's not worth the hassle applying messy microcode, operating system, or application updates.

"Stopped" CPUs that won’t therefore get a fix are in the Bloomfield, Bloomfield Xeon, Clarksfield, Gulftown, Harpertown Xeon C0 and E0, Jasper Forest, Penryn/QC, SoFIA 3GR, Wolfdale, Wolfdale Xeon, Yorkfield, and Yorkfield Xeon families. The new list includes various Xeons, Core CPUs, Pentiums, Celerons, and Atoms – just about everything Intel makes.

Most the CPUs listed above are oldies that went on sale between 2007 and 2011, so it is likely few remain in normal use.

Intel has not revealed which of the "stopped" CPUs listed can’t be mitigated at all, and which Chipzilla can't be bothered finishing patches for. We’ve asked Intel to provide that list, and will update this story if the biz replies.

There’s some good news in the tweaked guidance: the Arrandale, Clarkdale, Lynnfield, Nehalem, and Westmere families that were previously un-patched now have working fixes available in production, apparently.
Click to expand...

buik · Apr 5, 2018

eva2000 said: ↑

As some folks have guessed, some Intel cpus can not be fixed for Spectre v2 vulnerability and some cpus Intel won't be fixing for Meltdown either Intel admits a load of its CPUs have Spectre v2 flaw that can't be fixed
Click to expand...

"However, as indicated in our latest microcode revision guidance, we will not be providing updated microcode for a select number of older platforms for several reasons, including limited ecosystem support and customer feedback.”
Click to expand...

In short, customer. F*** you.
Providing a solution is always possible.
Hiding behind the fact that there is no more 'release ecosystem cycle support' or that customers didn't submit feedback.
Is a badly conceived reason.

eva2000 · Apr 12, 2018

Well AMD's turn for patch releases AMD Rolls Out Spectre Fixes for cpus only dating back to 2011

AMD said that CPU firmware and Windows 10 patches are now available to safeguard its products against the Spectre security flaw.

Mark Papermaster, senior vice president and chief technology officer at AMD, said in a Tuesday post that Spectre fixes are available for AMD customers, who can download BIOS updates provided by PC and server manufacturers and motherboard providers.

“These mitigations require a combination of processor microcode updates from our OEM and motherboard partners, as well as running the current and fully up-to-date version of Windows,” said Papermaster.

AMD said that its Spectre microcode updates date back to the first “Bulldozer” core products introduced in 2011.

The chip manufacturer’s announcement parallels Microsoft’s Patch Tuesday updates, which include an operating system update addressing Spectre. These Spectre mitigations are for AMD users running Windows 10 (version 1709) today, said AMD.
Click to expand...

eva2000 · Apr 27, 2018

Microsoft Issues More Spectre Updates For Intel CPUs

Microsoft has released additional Windows 10 mitigations for the Spectre side-channel flaw revealed in January, with an expanded lineup of firmware (microcode) updates for Intel CPUs that include the Broadwell and Haswell chipsets.

The company released two Windows Update packages addressing Spectre, KB4091666and KB4078407, both available as manual downloads from the Microsoft Update Catalog portal. The former contains the Intel microcode updates.
Click to expand...

eva2000 · May 3, 2018

wow a possible 8 new Spectre bugs found in Intel cpus r/Amd - Eight new Spectre Bugs found in Intel CPU's They're testing if AMD cpus are vulnerable or not. They're naming them Spectre Next Generation / Spectre-NG.

I already wrote it, but because some might over-read it. The bugs were confirmed on Intel and are still tested on ARM and AMD Systems (and maybe others). Right now only Intel is affected, until we know about the finished tests of the other platforms. And don't you start to cheer against Intel. Those bugs suck and we will all have problems with it in the longer run.
Click to expand...

Each of the eight vulnerabilities has its own number in the Common Vulnerability Enumerator (CVE) directory and each requires its own patches - probably they all get their own names. Until then, we will jointly call them the Spectre-NG gaps in order to distinguish them from the problems known so far.

So far we only have concrete information on Intel's processors and their patch plans. However, there is initial evidence that at least some ARM CPUs are also vulnerable. Further research is already underway on whether and to what extent the closely related AMD processor architecture is susceptible to the individual Spectre-NG gaps.

Intel is already working on some Spectre-NG patches itself; others are being developed in cooperation with the operating system manufacturers. When the first Spectre-NG patches will be released is not yet clear. According to our information, Intel is planning two patch waves: The first is scheduled to start in May; a second is currently planned for August.

At least one of the Spectre-NG patches has already been scheduled: Google's Project Zero has found one of the gaps again and on May 7 - the day before the Windows patchday - the 90-day deadline, which they typically allow the manufacturer before a release, expires. Google's elite hackers are quite uncompromising when it comes to such deadlines, and after their expiration they have already published information on vulnerabilities for which the manufacturer has not yet finished patches. If there is a second gap, Intel itself expects information to be made public at any time. So patches for these two gaps should be released sooner rather than later.

Microsoft is obviously also preparing for CPU patches: Originally, reference was made to BIOS updates for microcode updates against Spectre, but now they appear in the form of (optional) Windows updates. PC manufacturers simply need too long for BIOS updates. Microsoft is also offering up to $250,000 in a bug bounty program for Spectre gaps. Linux kernel developers are also continuously working on hardening measures against spectre attacks.
Click to expand...

eva2000 · May 3, 2018

yup 8 new Spectre-NG vulnerabilities
Eight new Spectre Variant Vulnerabilities for Intel Discovered - four of them critical

News has just started spreading that researchers have sighted another eight Spectre like vulnerabilities in Intel processors, all resemble Spectre, four of them are critical. The new vulnerabilities are grouped and named as Spectre-ng. The newly discovered vulnerabilities would make it really easy to exploit a host from a simple VM.

German c't / Heise reports and breaks the news today, as the new vulnerabilities have not been made public just yet. There would be 'no doubt' that these are real vulnerabilities. While technical details are missing, the attack scenarios resemble close to what the Spectre vulnerabilities are.

Currently, most at risk are shared hosting providers, once you have access to your rented server-container, you could exploit the processor to retrieve secure data. All eight vulnerabilities share the same design problem that the "Meltdown and Spectre" vulnerabilities detailed as well - they are, so to speak, Spectre Next Generation ergo Spectre NG. c't mentions they have concrete information about Intel's processors and their patch plans. However, there are some indications that other processors are affected as well, at least some ARM CPUs are also vulnerable to some extent. Further research into whether and to what extent the AMD processor architecture is vulnerable at (if at all), is not yet known.

Intel is reportedly actively and nervously working on Spectre NG patches behind the scenes; other patches are developed in collaboration with the operating system manufacturers (Microsoft / Linux etc). When exactly the first Spectre NG patches and firmware updates will become available is not yet clear. According to information, Intel is planning at least two patch waves: a first one should start in May; a second is currently scheduled for August. For at least one of the Specter NG patches is already a specific date as it was Google's Project Zero that has found one of the vulnerabilities, on May 7 - the day before the Windows Patchday - the 90-day warning period expires. So it's likely that when the first patch would be released for Microsoft Windows. Microsoft is preparing CPU patches: they appear to be in the form of optional Windows updates, and not so much microcode updated (firmware). The PC motherboard and server manufacturers probably need too long for BIOS updates.

Intel classifies four of the Specter NG vulnerabilities as "high-risk"; which in Intel language is translated as: super dangerous. The danger of the other four is rated as medium. According to c't/Heise, Specter-NG risks and attack scenarios are similar to those of Specter - with one exception. C't calls the Intel vulnerabilities and their procs a Swiss Cheese due to the many security holes.
Click to expand...

hmm VPS servers would thus be vulnerable !

eva2000 · May 8, 2018

Are us shared/VPS cloud hosting users screwed ? Intel Has to Delay Patches for new Spectre-NG Vulnerabilities

The news is reported today by Heise in Germany and is based on sources that are familiar with Intel's patch plans. From the looks of it, Intel is not capable of finishing up the patches before the disclosure publication date of what the new vulnerabilities mean and are. Up-to-now, any and all technical information on the Spectre-NG variants are disclosed. Likely all detected and to be published by Google Project Zero.

Intel set a new target for initial patches and firmware updates at the 21st of May, however also indicated they might not make that date and if so, requested technical disclosure until July 10th 2018. New microcode updates are due to be released on this date. At the same time, technical information on the nature of at least two of the Specter NG vulnerabilities are likely to be published. Heise states that a wide number of systems would be affected by the leaks including pretty much Core-i processors, Xeon variants, as well as Pentium and Celeron proc based Atom CPUs released ever since 2013. Later in August, it will address and patch the most serious leak that involves virtualized environments like cloud hosts, making it possible to obtain secure information directly from the CPU. The patch date for that specific vulnerability would be August 14 according to Heise. AMD has indicated it is investigating all reports. It is completely unclear whether the company was affected by the vulnerabilities as well.

To secure the architecture, Intel plans a combination of hardware updates in the form of new microcode and software improvements that the operating system manufacturers have to implement.
Click to expand...

eva2000 · May 9, 2018

Second wave of Spectre-like CPU security flaws won't be fixed for a while

The new bunch of Spectre-like flaws revealed last week won't be patched for at least 12 days.

German outlet Heise, which broke news of the eight Spectre-like vulnerabilities last week has now reported that Intel wants disclosure of the flaws delayed until at least May 21.

“Intel is now planning a coordinated release on May 21, 2018. New microcode updates are due to be released on this date”, Jürgen Schmidt reported on May 7.

Last week, Heise noted that one participant in the planned coordinated release would include a Google Project Zero disclosure, which as far as The Register can discern has not yet happened.

Heise added that the bug affects any Core-i (and their Xeon derivatives) processors using microcode written since 2010; and Atom-based processors (including Pentium and Celeron) since 2013.
Click to expand...

Looks like we may see more Spectre like vulnerabilities found as security researchers are now focusing on looking for them !

In addition to microcode fixes from Intel, operating system-level patches will also be necessary.

Ever since the original Meltdown and Spectre bugs were confirmed in January, it's become clear that speculative execution has been of interest to researchers for some time.
Click to expand...

eva2000 · May 17, 2018

AMD EPYC cpus might not be affected by new class of Spectre security vulnerabilities called Spectre-NG AMD is reportedly unaffected by Spectre NG - Great news for EPYC

AMD is reportedly unaffected by Spectre NG - Great news for EPYC
The scariest thing about the processor exploits known as Spectre and Meltdown is not just what they can do directly, but also the fact that it opens the door to a broader range of speculative execution problems which were previously considered impossible.

In recent weeks, rumours have started circulating about Spectre NG (Next Generation), a new Spectre variant which early reports stated could affect Intel-made chips. These initial reports said little about ARM and AMD silicon, though no Elazar Advisors has stated that AMD's processors are immune to the issue, after contacting AMD directly regarding the exploit.

At this time not much is known about Spectre NG, aside from the early reports which have suggested that Intel's existing Spectre/Meltdown mitigations are not enough to address the vulnerability, which means that Intel has to create new fixes which have the potential to impact processor performance in the name of security.

AMD's reported immunity is excellent news for the company in the data center market, making their EPYC series CPUs all the more attractive to enterprise customers. So far AMD has been relatively unaffected by Spectre/Meltdown, making their platform seem more secure than their Intel equivalents.
Click to expand...

eva2000 · May 22, 2018

wow this is never ending Microsoft, Google: We've found a fourth variant of Meltdown-Spectre CPU holes ! Red Hat has published an extensive rundown of the bug, here. Fix needs both kernel update and microcode/bios updates and a system power off/restart.

Variant 1 and 2 are known as Spectre (CVE-2017-5753, CVE-2017-5715), and variant 3 is Meltdown (CVE-2017-5754). Today, variant 4 will be disclosed by Microsoft and Google researchers. It can be potentially exploited by script files running within a program – such as JavaScript in a browser tab – to lift information out of other parts of the application – such as an other tab.

Variant 4 affects modern out-of-order processors, such as those from Intel. Chipzilla's executive veep of product security Leslie Culbertson explained in an official blog post seen by The Register prior to publication today:

Variant 4 (CVE-2018-3639) uses speculative execution, a feature common to most modern processor architectures, to potentially expose certain kinds of data through a side channel. In this case, the researchers demonstrated Variant 4 in a language-based runtime environment. While we are not aware of a successful browser exploit, the most common use of runtimes, like JavaScript, is in web browsers.

We’ve already delivered the microcode update for Variant 4 in beta form to OEM system manufacturers and system software vendors, and we expect it will be released into production BIOS and software updates over the coming weeks. This mitigation will be set to off-by-default, providing customers the choice of whether to enable it or not. 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-8 per cent based on overall scores for benchmarks like SYSmark 2014 SE and SPEC integer rate on client and server test systems.
Click to expand...

Click to expand...

CVE-2018-3639 - Red Hat Customer Portal

An industry-wide issue was found in the way many modern microprocessor designs have implemented speculative execution of Load & Store instructions (a commonly used performance optimization). It relies on the presence of a precisely-defined instruction sequence in the privileged code as well as the fact that memory read from address to which a recent memory write has occurred may see an older value and subsequently cause an update into the microprocessor's data cache even for speculatively executed instructions that never actually commit (retire). As a result, an unprivileged attacker could use this flaw to read privileged memory by conducting targeted cache side-channel attacks.
Find out more about CVE-2018-3639 from the MITRE CVE dictionary dictionary and NIST NVD.
Click to expand...

Kernel Side-Channel Attack using Speculative Store Bypass - CVE-2018-3639 - Red Hat Customer Portal

A malicious, unprivileged user could use this flaw to read privileged system memory and/or memory outside of a sandboxed environment like a web-browser or JIT execution run times.

To fully mitigate this vulnerability, system administrators must apply both hardware “microcode” updates and software patches that enable new functionality. At this time, microprocessor microcode will be delivered by the individual manufacturers, but at a future time Red Hat will release the tested and signed updates as we receive them.

This issue was disclosed to the public May 21, 2018.

Background Information
CVE-2018-3639 (aka “Speculative Store Bypass”) opens a new avenue (like Branch Misprediction) which can be exploited via speculative execution and cache based side channel methods to bypass security measures and access privileged memory. This issue is similar to CVE-2017-5753 (aka “Spectre v1”), except it leverages Speculative Store Bypass memory optimization in place of Branch Misprediction used by Spectre v1.
Click to expand...

Fix needs both kernel update and microcode/bios updates and a system power off/restart.

Take Action
Red Hat customers running affected versions of Red Hat products are strongly recommended to update them as soon as errata are available. Customers are urged to apply the appropriate updates immediately. These fixes also require CPU microcode/firmware updates and subscribers are advised to contact their hardware OEM vendors to receive the appropriate microcode/firmware for their processor. A kernel update, without the appropriate firmware/microcode updated for the processor, is insufficient to remediate this vulnerability.

The order the patches are applied is not important, but after updating firmware and hypervisors, every system/virtual machine will need to power off and restart to recognize a new hardware type.
Click to expand...

Intel has outlined Spectre variant 4 and 3a on their site at INTEL-SA-00115

Description:

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

Systems with microprocessors utilizing speculative execution and speculative execution of memory reads before the addresses of all prior memory writes are known may allow unauthorized disclosure of information to an attacker with local user access via a side-channel analysis.

4.3 Medium CVSS:3.0/AV:L/AC:L/PR:N/UI:N/S:C/C:L/I:N/A:N

CVE-2018-3640 – Rogue System Register Read (RSRE) – also known as Variant 3a

Systems with microprocessors utilizing speculative execution and that perform speculative reads of system registers may allow unauthorized disclosure of system parameters to an attacker with local user access via a side-channel analysis.

4.3 Medium CVSS:3.0/AV:L/AC:L/PR:N/UI:N/S:C/C:L/I:N/A:N

Affected products:

The following Intel-based platforms are potentially impacted by these issues. Intel may modify this list at a later time.

Intel® Core™ i3 processor (45nm and 32nm)
Intel® Core™ i5 processor (45nm and 32nm)
Intel® Core™ i7 processor (45nm and 32nm)
Intel® Core™ M processor family (45nm and 32nm)
2nd generation Intel® Core™ processors
3rd generation Intel® Core™ processors
4th generation Intel® Core™ processors
5th generation Intel® Core™ processors
6th generation Intel® Core™ processors
7th generation Intel® Core™ processors
8th generation Intel® Core™ processors
Intel® Core™ X-series Processor Family for Intel® X99 platforms
Intel® Core™ X-series Processor Family for Intel® X299 platforms
Intel® Xeon® processor 3400 series
Intel® Xeon® processor 3600 series
Intel® Xeon® processor 5500 series
Intel® Xeon® processor 5600 series
Intel® Xeon® processor 6500 series
Intel® Xeon® processor 7500 series
Intel® Xeon® Processor E3 Family
Intel® Xeon® Processor E3 v2 Family
Intel® Xeon® Processor E3 v3 Family
Intel® Xeon® Processor E3 v4 Family
Intel® Xeon® Processor E3 v5 Family
Intel® Xeon® Processor E3 v6 Family
Intel® Xeon® Processor E5 Family
Intel® Xeon® Processor E5 v2 Family
Intel® Xeon® Processor E5 v3 Family
Intel® Xeon® Processor E5 v4 Family
Intel® Xeon® Processor E7 Family
Intel® Xeon® Processor E7 v2 Family
Intel® Xeon® Processor E7 v3 Family
Intel® Xeon® Processor E7 v4 Family
Intel® Xeon® Processor Scalable Family
Intel® Atom™ Processor C Series (C3308, C3338, C3508, C3538, C3558, C3708, C3750, C3758, C3808, C3830, C3850, C3858, C3950, C3955, C3958)
Intel® Atom™ Processor E Series
Intel® Atom™ Processor A Series
Intel® Atom™ Processor X Series (x5-E3930, x5-E3940, x7-E3950)
Intel® Atom™ Processor T Series (T5500, T5700)
Intel® Atom™ Processor Z Series
Intel® Celeron® Processor J Series (J3355, J3455, J4005, J4105)
Intel® Celeron® Processor N Series (N3450)
Intel® Pentium® Processor J Series (J4205)
Intel® Pentium® Processor N Series (N4000, N4100, N4200)
Intel® Pentium® Processor Silver Series (J5005, N5000)

Please check with your system vendor or equipment manufacturer for more information regarding updates for your system. For non-Intel based systems please contact your system manufacturer or microprocessor vendor.
Click to expand...

OVH's response OVH - Spectre Variant 4 and 3a disclosure - OVH Blog

Stemming from Spectre
These vulnerabilities are variants of « Spectre » and are called “Spectre Variant 3a” (CVE-2018-3640), and “Spectre Variant 4” (CVE-2018-3639), both also know as “SpectreNG” or “Spectre New Generation”. The specific “Spectre Variant 4” is also referred as “Speculative Store Bypass”.

Though they are closely related to « Spectre », they have enough difference to be considered specific flaws which will require additional action(s) for certain CPU architectures.

Spectre Variant 3a concern systems with microprocessors utilizing speculative execution and that perform speculative reads of system registers, which may allow unauthorized disclosure of system parameters to an attacker with local user access via a side-channel analysis.

Spectre Variant 4 concern systems with microprocessors utilizing speculative execution and speculative execution of memory reads before the addresses of all prior memory writes are known, which may allow unauthorized disclosure of information to an attacker with local user access through a side-channel analysis.

We also know that Spectre Variant 4 may be carried out in a language-based runtime environment. The most common use of runtime is JavaScript, which is used in web browsers but at this time we are not aware of any successful web browser exploitation.
Click to expand...

Mitigation of these flaws will need an addition of CPU microcode and software/operating system updates. As usual, we will continue to test every microcode or sensible update internally before deploying anything live, to ensure the security and the stability of our customers infrastructure.
Click to expand...

eva2000 · May 22, 2018

Researchers disclose new Spectre exploit variant, but Intel and AMD leave mitigation off by default

But, as Intel puts it, “to ensure we offer the option for full mitigation and to prevent this method from being used in other ways, we and our industry partners are offering an additional mitigation for Variant 4, which is a combination of microcode and software updates.”

OEMs, which make components like motherboards, already have the fix. But like some other patches, this one will be left off by default. Why?

Probably because Intel observed a performance hit of “2 to 8 percent” when the fix was enabled. Accordingly, it has chosen in this case to let OEMs and consumers opt into having a slower, safer processor than opt out of it. Since many manufacturers live and die by the performance of their hardware, it seems unlikely they’ll choose the slow option, and few consumers are tech-savvy enough to enable it themselves.

Critics of this choice aren’t hard to find; it’s arguable that Intel is simply putting performance over safety. But it’s also arguable that an 8 percent drop in speed just isn’t worth the tradeoff when the problem is already partially mitigated.

“I continue to encourage everyone to keep their systems up-to-date, as it’s one of the easiest ways to ensure you always have the latest protections,” writes Intel’s Leslie Culbertson. The easiest way, presumably, is for it to be enabled by default, but her heart is clearly in the right place.

(Update: AMD has a less substantial post describing its own mitigation efforts, which it will also be leaving off by default. No word on what the performance hit will be for AMD processors.)
Click to expand...

buik · May 23, 2018

Already been fixed at the latest EL 6 and EL 7 kernel.

Example:

[2.6.32-696.30.1]
- [x86] x86/kvm: fix CPUID_7_EDX (word 18) mask (Jan Stancek) [1566893 1566899] {CVE-2018-3639}

[2.6.32-696.29.1]
- [x86] x86/spec_ctrl: Fix late microcode problem with AMD (Waiman Long) [1566893 1566899] {CVE-2018-3639}
- [x86] x86/spec_ctrl: Clean up entry code & remove unused APIs (Waiman Long) [1566893 1566899] {CVE-2018-3639}
- [x86] x86/spec_ctrl: Mask off SPEC_CTRL MSR bits that are managed by kernel (Waiman Long) [1566893 1566899] {CVE-2018-3639}
- [x86] x86/spec_ctrl: add support for SSBD to RHEL IBRS entry/exit macros (Waiman Long) [1566893 1566899] {CVE-2018-3639}
- [x86] x86/bugs: Rename _RDS to _SSBD (Waiman Long) [1566893 1566899] {CVE-2018-3639}
- [x86] x86/speculation: Add prctl for Speculative Store Bypass mitigation (Waiman Long) [1566893 1566899] {CVE-2018-3639}
- [x86] x86/process: Allow runtime control of Speculative Store Bypass (Waiman Long) [1566893 1566899] {CVE-2018-3639}
- [kernel] prctl: Add speculation control prctls (Waiman Long) [1566893 1566899] {CVE-2018-3639}
- [x86] x86/kvm: Expose the RDS bit to the guest (Waiman Long) [1566893 1566899] {CVE-2018-3639}
- [x86] x86/bugs/AMD: Add support to disable RDS on Fam[15, 16, 17]h if requested (Waiman Long) [1566893 1566899] {CVE-2018-3639}
- [x86] x86/spec_ctrl: Sync up RDS setting with IBRS code (Waiman Long) [1566893 1566899] {CVE-2018-3639}
- [x86] x86/bugs: Provide boot parameters for the spec_store_bypass_disable mitigation (Waiman Long) [1566893 1566899] {CVE-2018-3639}
- [x86] x86/bugs: Expose the /sys/../spec_store_bypass and X86_BUG_SPEC_STORE_BYPASS (Waiman Long) [1566893 1566899] {CVE-2018-3639}
- [x86] x86/bugs: Read SPEC_CTRL MSR during boot and re-use reserved bits (Waiman Long) [1566893 1566899] {CVE-2018-3639}
- [x86] x86/spec_ctrl: Use separate PCP variables for IBRS entry and exit (Waiman Long) [1566893 1566899] {CVE-2018-3639}
- [x86] cpu/intel: Knight Mill and Moorefield update to intel-family.h (Waiman Long) [1566893 1566899] {CVE-2018-3639}
- [x86] x86/speculation: Update Speculation Control microcode blacklist (Waiman Long) [1566893 1566899] {CVE-2018-3639}
- [x86] x86/cpuid: Fix up 'virtual' IBRS/IBPB/STIBP feature bits on Intel (Waiman Long) [1566893 1566899] {CVE-2018-3639}
- [x86] x86/cpufeatures: Clean up Spectre v2 related CPUID flags (Waiman Long) [1566893 1566899] {CVE-2018-3639}
- [x86] x86/cpufeatures: Add AMD feature bits for Speculation Control (Waiman Long) [1566893 1566899] {CVE-2018-3639}
- [x86] x86/cpufeatures: Add Intel feature bits for Speculation (Waiman Long) [1566893 1566899] {CVE-2018-3639}
- [x86] x86/cpufeatures: Add CPUID_7_EDX CPUID leaf (Waiman Long) [1566893 1566899] {CVE-2018-3639}
- [x86] x86/cpu: Fill in feature word 13, CPUID_8000_0008_EBX (Waiman Long) [1566893 1566899] {CVE-2018-3639}
- [x86] Extend RH cpuinfo to 10 extra words (Waiman Long) [1566893 1566899] {CVE-2018-3639}
- [x86] kpti/kexec: fix wrong page address in clear_page (Dave Young) [1573176 1572487]
Click to expand...

eva2000 · May 23, 2018

Ah i just got a kernel update too on CentOS 7 for kernel-3.10.0-862.3.2.el7. So folks need to do a server reboot after kernel update

But these fixes are disabled by default !

Code (Text):

rpm -q --changelog kernel-3.10.0-862.3.2.el7 | head -n25
* Mon May 21 2018 CentOS Sources <bugs@centos.org> - 3.10.0-862.3.2.el7
- Apply debranding changes

* Tue May 15 2018 Rado Vrbovsky <rvrbovsk@redhat.com> [3.10.0-862.3.2.el7]
- [x86] spec_ctrl: Fix late microcode problem with AMD (Waiman Long) [1566904 1566905] {CVE-2018-3639}
- [x86] entry: Add missing "$" in IBRS macros (Waiman Long) [1566904 1566905] {CVE-2018-3639}
- [x86] spec_ctrl: Clean up entry code & remove unused APIs (Waiman Long) [1566904 1566905] {CVE-2018-3639}
- [x86] spec_ctrl: Mask off SPEC_CTRL MSR bits that are managed by kernel (Waiman Long) [1566904 1566905] {CVE-2018-3639}
- [x86] spec_ctrl: add support for SSBD to RHEL IBRS entry/exit macros (Waiman Long) [1566904 1566905] {CVE-2018-3639}
- [fs] proc: Use CamelCase for SSBD (Waiman Long) [1566904 1566905] {CVE-2018-3639}
- [x86] bugs: Rename _RDS to _SSBD (Waiman Long) [1566904 1566905] {CVE-2018-3639}
- [kernel] seccomp: Enable speculation flaw mitigations (Waiman Long) [1566904 1566905] {CVE-2018-3639}
- [fs] proc: Provide details on speculation flaw mitigations (Waiman Long) [1566904 1566905] {CVE-2018-3639}
- [x86] nospec: Allow getting/setting on non-current task (Waiman Long) [1566904 1566905] {CVE-2018-3639}
- [x86] speculation: Add prctl for Speculative Store Bypass mitigation (Waiman Long) [1566904 1566905] {CVE-2018-3639}
- [x86] process: Allow runtime control of Speculative Store Bypass (Waiman Long) [1566904 1566905] {CVE-2018-3639}
- [uapi] prctl: Add speculation control prctls (Waiman Long) [1566904 1566905] {CVE-2018-3639}
- [x86] kvm/vmx: Expose SPEC_CTRL Bit(2) to the guest (Waiman Long) [1566904 1566905] {CVE-2018-3639}
- [x86] bugs/amd: Add support to disable RDS on Fam[15, 16, 17]h if requested (Waiman Long) [1566904 1566905] {CVE-2018-3639}
- [x86] spec_ctrl: Sync up RDS setting with IBRS code (Waiman Long) [1566904 1566905] {CVE-2018-3639}
- [x86] bugs: Provide boot parameters for the spec_store_bypass_disable mitigation (Waiman Long) [1566904 1566905] {CVE-2018-3639}
- [x86] bugs: Expose /sys/../spec_store_bypass (Waiman Long) [1566904 1566905] {CVE-2018-3639}
- [x86] bugs: Read SPEC_CTRL MSR during boot and re-use (Waiman Long) [1566904 1566905] {CVE-2018-3639}
- [x86] spec_ctrl: Use separate PCP variables for IBRS entry and exit (Waiman Long) [1566904 1566905] {CVE-2018-3639}
- [x86] cpufeatures: Make CPU bugs sticky (Waiman Long) [1566904 1566905] {CVE-2018-3639}

eva2000 · May 23, 2018

But as per Red Hat Customer Portal kernel update is not enough, microcode / bios updates needed too

Note: This issue is present in hardware and cannot be fully fixed via software update. The updated kernel packages provide software side of the mitigation for this hardware issue. To be fully functional, up-to-date CPU microcode applied on the system is required. Please refer to References section for further information about this issue, CPU microcode requirements and the potential performance impact.

In this update mitigations for x86-64 architecture are provided.
Click to expand...

eva2000 · May 23, 2018

Linux 4.9, 4.14, 4.16 Point Releases Bring SSBD For Spectre V4 - Phoronix

oday's 4.9/4.14/4.16 point releases carry the Intel/AMD mitigation for Spectre V4 albeit the Intel support is dependent upon to-be-released microcode updates and is vulnerable by default while for AMD processors there is SSB disabled via prctl and seccomp.

The list of changes/fixes can be found for 4.9.102, 4.14.43, and 4.16.11.
Click to expand...

Spectre Variants 3A & 4 Exposed As Latest Speculative Execution Vulnerabilities - Phoronix

These new vulnerabilities affect all major CPU vendors just not AMD/Intel but also ARM and IBM / POWER. Red Hat has initial details on their site and a further explanation.

Mitigating these new Spectre vulnerabilities is known to affect performance, potentially by a few percent.

Initial SSBD mitigation landed today in the Linux kernel and is being prepared for back-porting to supported stable series. Microcode CPU updates are also necessary.
Click to expand...

And benchmarks An Initial Look At Spectre V4 "Speculative Store Bypass" With AMD On Linux - Phoronix

Landing yesterday into Linux 4.17 Git was Speculative Store Bypass Disable (SSBD) as the Linux-based mitigation on Intel/AMD x86 CPUs. Since then has also been the POWER CPU SSBD implementationand pending patches for ARM64 CPUs.

When it comes to the Intel/AMD CPUs, that is squared away in Linux 4.17 although we expect the support will continue to be refined over the weeks/months ahead just as the earlier Spectre and Meltdown mitigation work continues to be improved upon, particularly for performance efficiencies. The initial x86 mitigation work has already premiered today in new 4.9/4.14/4.16 kernel point releases.
Click to expand...

AMD CPU users booting to a new kernel via /sys/devices/system/cpu/vulnerabilities/spec_store_bypasswill find that their mitigation support is enabled by default and working. If your kernel is built with the SECCOMP configuration option, it will report Speculative Store Bypass has been disabled via PRCTL and SECCOMP methods otherwise just PRCTL. This behavior can be controlled via the spec_store_bypass_disable= kernel parameter with valid options of on/off/auto/prctl/seccomp.
Click to expand...

But for Intel users today if booting to a patched kernel you will find your system reporting it's still vulnerable to Spectre V4 and even with the spec_store_bypass_disable kernel option cannot be forced enabled: you first need an upgraded BIOS / CPU microcode. Intel is working on getting that out to motherboard vendors/partners for hitting end-users in the weeks ahead. I was hoping to get access to updates today, but unfortunately as of writing that didn't pan out yet so I don't have any Intel testing to share at this point.

For AMD CPU users wishing to learn more about the technical details on SSBD, AMD has published a PDF whitepaper going over all the fine technical information. Additionally, AMD CPUs are not believed to be applicable to the Spectre Variant 3A vulnerability.
Click to expand...

Benchmarks on the Ryzen 7 2700X, Ryzen 3 2200G, and EPYC 7601 when using a Linux 4.17 Git kernel look good with no real performance impact. Will need to see how Intel fairs after their bios/microcode updates

At least from this initial testing on AMD hardware, the performance impact of SSBD for Spectre Variant 4 is much smaller than the performance hits experienced months ago with KPTI for Intel Meltdown handling and Retpolines for Spectre V2
Click to expand...

eva2000 · May 23, 2018

Linode response to Spectre 3a and 4 variants Spectre Variants 3a and 4 (Spectre-NG) and Linode: What you need to know

Intel announced details and mitigation information for Spectre variant 4 known as “Speculative Store Bypass” on May 21, 2018. The details and mitigation notes describe a microcode update which also addresses variant 3a named “Rogue System Register Read.”

Variants 3a and 4 are considered “Side-Channel Vulnerability Variants.” Variant 4 is focused around speculative store bypass, and could potentially impact processes local to your Linode. Based on our current understanding of this issue, we do not believe it’s possible to exploit this vulnerability to gain access to the host hypervisor or other Linodes. We have not seen exploit code in the wild yet. However, we highly recommend that you update the packages on your Linode to the latest version as a preventative measure.

So far it’s looking like we will need to apply microcode and software updates to achieve full mitigation for this vulnerability. The microcode is currently in beta, and our security and engineering teams will be working with Intel to evaluate this and its impact on our host fleet.

Depending on the effectiveness of the microcode and software updates, we may be required to reboot the fleet. In the event that reboots are necessary, we’re committed to providing at least two full weeks of notice to all customers. At a high level, we are not anticipating any actions for a few months. The security of our customers is of critical importance to us, and we will continue providing information here as it becomes available.
Click to expand...

Log in / Register

Forums

Want more timely Centmin Mod News Updates?

Security Intel Processor Flaw 'kernel memory leaking' [Spectre & Meltdown]

eva2000 Administrator Staff Member

eva2000 Administrator Staff Member

eva2000 Administrator Staff Member

eva2000 Administrator Staff Member

eva2000 Administrator Staff Member

buik “The best traveler is one without a camera.”

eva2000 Administrator Staff Member

eva2000 Administrator Staff Member

eva2000 Administrator Staff Member

eva2000 Administrator Staff Member

eva2000 Administrator Staff Member

eva2000 Administrator Staff Member

eva2000 Administrator Staff Member

eva2000 Administrator Staff Member

eva2000 Administrator Staff Member

buik “The best traveler is one without a camera.”

eva2000 Administrator Staff Member

eva2000 Administrator Staff Member

eva2000 Administrator Staff Member

eva2000 Administrator Staff Member

.

Log in / Register

Useful Searches

Want more timely Centmin Mod News Updates?

Security Intel Processor Flaw 'kernel memory leaking' [Spectre & Meltdown]

eva2000 Administrator Staff Member

eva2000 Administrator Staff Member

eva2000 Administrator Staff Member

eva2000 Administrator Staff Member

eva2000 Administrator Staff Member

buik “The best traveler is one without a camera.”

eva2000 Administrator Staff Member

eva2000 Administrator Staff Member

eva2000 Administrator Staff Member

eva2000 Administrator Staff Member

eva2000 Administrator Staff Member

eva2000 Administrator Staff Member

eva2000 Administrator Staff Member

eva2000 Administrator Staff Member

eva2000 Administrator Staff Member

buik “The best traveler is one without a camera.”

eva2000 Administrator Staff Member

eva2000 Administrator Staff Member

eva2000 Administrator Staff Member

eva2000 Administrator Staff Member

.