CPU Vulnerabilities, Meltdown and Spectre, Kernel Page Table Isolation Patches, and more

To be fair, I'm leaving them on for a couple of test machines to see what happens.

 

Was about to turn on auto updates on my sis's laptop and this move actually made me re-consider.

 

You play with the fire

----------------------------------------------

Edit. Microcode revision guidance - February 12 2018

 

Microsoft Security Updates February 2018 release-Ghacks.net

As you all know... New is always better Direct update downloads in the link above (to the Microsoft Update Catalog website where you can download the updates as standalone files). I wish you good luck I'm a Happy Camper with slow download speed. I will take my time

 

MS-DEFCON 2 for Feb 2018: Make sure Automatic Update is turned off
Posted on February 12th, 2018 at 08:24
https://www.askwoody.com/2018/ms-defcon-2-for-feb-2018-make-sure-automatic-update-is-turned-off/

"Last month’s Patch Tuesday (and Monday, Wednesday, Thursday, Friday, Saturday and Sunday) should prove, once again, that knowledgeable Windows users need to turn off Automatic Update.

Do me a favor, wouldja? If you bump into any of the self-proclaimed security “experts” who tell everyone to turn on Automatic Update, would you post a link to their drivel? I took a lot of guff for my posts a year ago, advising folks to turn off Automatic Update. If there’s anybody in the industry who’s still spreading that kind of hooey, I want to know who and why."


Security Vulnerability: "Meltdown" and "Spectre" side channel attacks against CPUs with speculative execution.
https://www.suse.com/de-de/support/kb/doc/?id=7022512
Modified Date: 12-FEB-18
SUSE, SUSE Linux Enterprise Desktop, SUSE Linux Enterprise Server

Spoiler: Details and links to supporting information

This document (7022512) is provided subject to the disclaimer at the end of this document.

Environment

Based on research from various groups and individuals a new family of side channel attacks against CPUs with speculative execution were identified that can be used by attackers to read content of otherwise inaccessible memory.

To help mitigating this hardware implementation related flaws on the software layer, SUSE as an operating system vendor has released and is continuing to work on mitigations for these side channel attacks in the Linux kernel and other packages.

For details on the vulnerability, please check : https://meltdownattack.com/

Situation

The following three attacks have been identified :
CVE-2017-5753: variant 1 - bounds check bypass
Local attackers could use speculative execution over code patterns in the Linux Kernel to leak content from otherwise not readable memory in the same address space, allowing retrieval of passwords, cryptographic keys and other secrets.

This problem is mitigated by fencing speculative execution on affected code paths throughout the Linux kernel and needs to be addressed for all SUSE Linux Enterprise processor architectures.

Fixes for this variant are contained in the SUSE Linux Kernel updates.

AMD/Intel x86-64, IBM Power and IBM Z have received mitigations, only ARM Arch64 has not yet received them yet.

As these mitigations need to be added to a lot of different places throughout the Linux Kernel and potentially even also other packages, future updates could be necessary.

CVE-2017-5715: variant 2 - branch target injection
Local attackers could use mis-predicted branches to speculatively execute code patterns that in turn could be made to leak otherwise non-readable content in the same address space, an attack similar to CVE-2017-5753.

There are two different approaches to mitigate this issue, both complement each other :

Approach 1 : Selectively restricting the indirect branch predictor

This first method is done by restricting predictive branches, depending on CPU architecture either by firmware updates and/or mitigations in the user-kernel privilege boundaries.

Terminologies used :
- IBPB: Indirect branch prediction barrier. Previous learned branch prediction targets are forgotten at this barrier, used when switching to a different privilege context.

- IBRS: Indirect branch restricted speculation. If set, indirect branches will not use previous speculation data from lower privilege levels.

- STIBP: Single thread indirect branch predictors prevents indirect branch predictions from being controlled by the sibling Hyperthread.
Further reading in this white paper from Intel: https://newsroom.intel.com/wp-conte...is-of-Speculative-Execution-Side-Channels.pdf

Fixes needed in / by CPU architecture :
Intel x86_64 : Linux Kernel and CPU Microcode (Microcode delivered by SUSE or vendor)
AMD x86_64 : Linux Kernel and CPU Microcode (Microcode delivered by SUSE or vendor)
IBM Z : Linux Kernel and CPU Microcode (Microcode delivered by IBM)
IBM Power : CPU Microcode (Microcode delivered by IBM)
ARM Arch64 : still in development
This mitigation has a performance impact, and as such, this will be made configurable via the kernel command line option "nospec" in later releases. Please note that disabling it will disable the mitigation for CVE-2017-5715 and should only be done on systems with trusted users executing only trusted code (!).

Note on Intel CPU Microcode :

As Intel reported increased system instabilities after applying the 20180108 Intel CPU Microcode updates, we have retracted those from our update servers. We are in close contact with Intel and will be releasing new microcode updates once Intel releases them.

A detailed technical Intel Microcode guidance document was published on :
https://newsroom.intel.com/wp-content/uploads/sites/11/2018/01/microcode-update-guidance.pdf

The last Intel microcode update can be force installed using :
On SLE 12 :
zypper in -f ucode-intel-20170707-13.5.1
On SLE 11 SP3 LTSS and SLES 11 SP4 we have released an incremental "microcode_ctl" package that again reverts to the 20170707 state of the Intel ucode, which is available from our update servers.
Approach 2 : Rebuilding the kernel without indirect jumps by using "retpolines"

SUSE is currently working on compiler and kernel support for the "retpolines" technology that replaces indirect jumps by return-trampolines and will be releasing kernel updates with those enabled for x86_64 in the next weeks.

These kernel updates will mitigate the Spectre variant 2 problem without a need for microcode updates on most of the AMD and Intel x86_64 systems.

Some new x86_64 platforms like Broadwell and Skylake will still need microcode updates even with a retpoline enabled kernel.

CVE-2017-5754: variant 3 - rogue data cache load
Local attackers could use code patterns in userspace to speculative executive code that would read otherwise read protected memory, an attack similar to CVE-2017-5753.

This problem is mitigated by unmapping the Linux Kernel from the user address space during user code execution, following a approach described in the "KAISER" paper and called "Page Table Isolation" / "PTI".

We have released updates that implement this mitigation on the Intel x86_64 and IBM Power architecture.
This mitigation is also necessary for the ARM architecture and will be delivered in the second round of updates.

This problem does not affect the AMD x86_64 and IBM Z processor architecture.

This mitigation can be enabled / disabled by the "pti=[on|off|auto]" or "nopti" command line options. More details can be found in the "Additional information" section. Please note that disabling it will disable the mitigation for this issue (!).
Resolution

SUSE has released kernel updates for all maintained SUSE products to mitigate the "Meltdown" attack.
SUSE has released kernel updates for all maintained SUSE products to mitigate the "Spectre Variant 1" attack.
SUSE has released kernel updates for all maintained SUSE products to mitigate the "Spectre Variant 2" attack, pending on availability of CPU Microcode updates.
SUSE has released CPU microcode updates for AMD Ryzen in the "ucode-amd" package on SLE 12 and "microcode_ctl" on SLE 11.
SUSE has released KVM and QEMU updates to allow passing through CPU flags and MSR registers to support controlling speculative branch handling.
SUSE has released system compiler updates including "retpoline" support.
SUSE is in the process of releasing kernel updates for all maintained SUSE products to mitigate the "Spectre Variant 2" using the "retpoline" method on x86_64.

Going forward :
SUSE will be releasing kernel updates for all maintained SUSE products to mitigate the "Spectre Variant 2" using the "retpoline" method on x86_64.
SUSE will also be releasing firmware updates for Intel x86_64 in the packages microcode_ctl on SUSE Linux Enterprise 11, ucode-intel on SUSE Linux Enterprise 12, once stable microcode updates from Intel are available.

The XEN Hypervisor also needs mitigations for the described problems, these are currently in development.
For further details on XEN, KVM and QEMU updates please review TID 7022514.


Performance Impact

The performance impact of these patches is highly dependent on the actual workload, but also on CPU vendor and family. We recommend to always validate the performance impact prior to deploying these updates to production systems.

For more detail on the performance aspect, please read this SUSE blog here : https://www.suse.com/c/meltdown-spectre-performance/


SUSE has released the following updates :

SLES 12 SP3
kernel-default-4.4.114-94.11.3 released Wednesday, 7th of February 2018
kernel-default-4.4.103-94.6.1 (IBM Z Series ONLY) released Tuesday, 16th of January 2018
kernel-default-4.4.103-6.38.1 released Thursday, 4th of January 2018
ucode-amd-20170530-21.16.1 released Thursday, 4th of January 2018
(**obsoleted**) ucode-intel-20180108-13.11.1 released Thursday,11th of January 2018
(**obsoleted**) ucode-intel-20170707-13.8.1 released Thursday, 4th of January 2018
qemu-2.9.1-6.9.2 released Thursday, 4th of January 2018
SLES 12 SP3 Real Time
Original fixes were included in GA release. Future updates will be released via maintenance.
SLES 12 SP2
kernel-default-4.4.114-92.64.1 released Friday 9th of February 2018
kernel-default-4.4.103-92.59.1 (IBM Z Series ONLY) released Thursday, 11th of January 2018
kernel-default-4.4.103-92.56.1 released Thursday, 4th of January 2018
ucode-amd-20170530-21.16.1 released Thursday, 4th of January 2018
(**obsoleted**) ucode-intel-20180108-13.11.1 released Thursday,11th of January 2018
(**obsoleted**) ucode-intel-20170707-13.8.1 released Thursday, 4th of January 2018
SLES 12 SP2 Real Time
kernel-rt-4.4.104-24.1 released Thursday, 25th of January 2018
SLES 12 SP1 - LTSS
kernel-default-3.12.74-60.64.72.1 (IBM Z Series ONLY) released Tuesday, 16th of January 2018
kernel-default-3.12.74-60.64.69.1 released Friday, 5th of January 2018
(**obsoleted**) ucode-intel-20180108-13.11.1 released Thursday,11th of January 2018
(**obsoleted**) ucode-intel-20170707-13.8.1 released Thursday, 4th of January 2018
qemu-2.3.1-33.6.1 released Tuesday, 9th of January 2018
[*SLE-12-SP1 ppc64le customers, please see 'note 2' below.]
SLES 12 - LTSS
kernel-default-3.12.61-52.111.1 released Tuesday, 16th of January 2018
ucode-amd-20140807git-5.3.1 released Tuesday, 9th of January 2018
(**obsoleted**) ucode-intel-20180108-13.11.1 released Thursday,11th of January 2018
(**obsoleted**) ucode-intel-20170707-13.8.1 released Thursday, 4th of January 2018
SLES 11 SP4
kernel-default-3.0.101-108.24.1 (IBM Z Series ONLY) released Thursday, 18th of January 2018
kernel-default-3.0.101-108.21.1 released Thursday, 4th of January 2018
microcode_ctl-1.17-102.83.12.1 released Friday ,19th of January 2018
(**obsoleted**) microcode_ctl-1.17-102.83.9.1 released Thursday,11th of January 2018
(**obsoleted**) microcode_ctl-1.17-102.83.6.1 released Thursday, 4th of January 2018
SLES 11 SP4 Real Time
kernel-rt-3.0.101.rt130-69.14.1 released Tursday, 23th of January 2018
SLES 11 SP3 - LTSS
kernel-default-3.0.101-0.47.106.11.1 released Monday, 8th of January 2018
microcode_ctl-1.17-102.83.12.1 released Friday ,19th of January 2018
(**obsoleted**) microcode_ctl-1.17-102.83.9.1 released Thursday,11th of January 2018
(**obsoleted**) microcode_ctl-1.17-102.83.6.1 released Thursday, 4th of January 2018
SUSE CaaS Platform
ucode-amd-20170530-21.16.1 released Thursday, 4th of January 2018
qemu-2.9.1-6.9.2 released Thursday, 4th of January 2018

Note 1: Observing multiple microcode-ctl and/or ucode-intel releases for the same SLE version :
As firmware updates continue to become available for other CPU models, this will show as another new microcode-ctl and/or ucode-intel release with the date released.

The microcode listed as (**obsoleted**)where removed from our maintenance updates and SUSE patch finder location here due to quality issues reported by customers and community.

Note 2 : An LTSS channel for SLE-12-SP1 ppc64le does not exist.
The patches for Spectre & Meltdown are available in the SLES-12-SP1-SAP channel. This channel is supported until May 2018 (as per the SUSE Product Life Cycle page here).

Important note : A valid SLES for SAP subscriptions is required to access this repository.

Cause

CVE-2017-5753 (Spectre - variant 1)
CVE-2017-5715 (Spectre - variant 2)
CVE-2017-5754 (Meltdown - variant 3)
Additional Information

Products running on top of SUSE Linux Enterprise Server, such as SUSE OpenStack Cloud, SUSE Enterprise Storage, SUSE Manager are not directly vulnerable. For these SUSE products, updating the the Host (running SUSE Linux Enterprise Server) with the updates detailed and listed here is sufficient.


Public Cloud:
SUSE has updated all (on-demand and BYOS) images that are actively maintained within the SUSE Public Cloud Image lifecycle guidelines. Image information can be retrieved with the "pint" tool.

All updated images have a timestamp of v20180104, i.e. January 4th 2018 or later.

For all running instances of SUSE images in production within public clouds, SUSE's advice to all customers is to apply all existing kernel updates available.

Enabling or Disabling Mitigations for Performance reasons

Mitigations that were applied can be selectively enabled or disabled.

SUSE Linux Enterprise chooses the default to be secure, meaning the mitigation's are enabled.

Spectre variant 2 kernel parameters :
For x86_64 architecture a new "spectre_v2" kernel commandline parameter has been added to control how the spectre variant 2 mitigations are enabled.
spectre_v2=<value>
<value> :
on - unconditionally enable the mitigation
off - unconditionally disable the mitigation
auto - kernel detects whether your CPU model is vulnerable
Selecting 'on' will, and 'auto' may, choose a mitigation method at run time according to the CPU, the available microcode, the setting of the CONFIG_RETPOLINE configuration option, and the compiler with which the kernel was built.
Specific mitigations can also be selected manually:
retpoline - replace indirect branches
retpoline,generic - google's original retpoline
retpoline,amd - AMD-specific minimal thunk
nospectre_v2 - this is the same as spectre_v2=off

Not specifying any option is equivalent to using : spectre_v2=auto.

For x86_64 we also support the option:
nospec
This option disables the CPU microcode based Spectre variant 2 mitigations.
The retpoline enablement is not controlled by this option.

For s390x architecture, the parameter is called "nobp", and has following values :
nobp=<value>
<value> :
on - enable mitigation
off - disable mitigation

PTI kernel parameter:

The default value for x86-64 is "auto", meaning enabled for processors deemed vulnerable or unknown, and disabled on those known to be unaffected (AMD).
For ARM the default value is "off" for the time being as the "auto" trigger has not been implemented yet.
pti = auto
lets kernel decide, which means it turns PTI on when is's running on Intel and turns it off when running on AMD
pti = off
force-disable PTI even on Intel
pti = on
force-enables PTI even on AMD

Verifying if a system is protected :
Following updating the latest kernels, it is possible to check /proc/cpuinfo for 'kaiser' or 'pti' and 'spec_ctrl' or 'ibpb' information.

When the output includes :
'kaiser' or 'pti' flags, then v3 (Meltdown) protection is active.
'spec_ctrl' flag, then v2/v1 (Spectre) protection is active on Intel CPU's.
'ibpb' flag, then v2/v1 (Spectre) protection is active on AMD CPU's.
Additional detail :
- The 'kaiser' flag is used on SLE versions up to SLE 12, in turn, SLE 15 will use the 'pti' flag.
- The 'spec_ctrl' or 'ibpb' flag implies both v2 and v1 protection, but if it is not present, it means v2 is not active, but v1 still may, as it currently cannot be disabled in SLES - if the installed kernel has it, it's on.
Disclaimer

This Support Knowledgebase provides a valuable tool for NetIQ/Novell/SUSE customers and parties interested in our products and solutions to acquire information, ideas and learn from one another. Materials are provided for informational, personal or non-commercial use within your organization and are presented "AS IS" WITHOUT WARRANTY OF ANY KIND."

Linux Meltdown patch: 'Up to 800 percent CPU overhead', Netflix tests show the performance impact of Meltdown patches makes it essential to move systems to Linux 4.14.
By Liam Tung | February 12, 2018 -- 12:36 GMT (04:36 PST)
http://www.zdnet.com/article/linux-meltdown-patch-up-to-800-percent-cpu-overhead-netflix-tests-show/

"The Linux mitigation for Meltdown known as kernel page table isolation (KPTI) can cause a massive drain on CPU performance, according to an analysis by Brendan Gregg, a senior performance architect at Netflix.

While Intel's Spectre mitigations have attracted the most attention for causing performance and stability problems, Gregg finds that KPTI causes the "largest kernel performance regressions I've ever seen".

KPTI prevents Meltdown leaks by using completely separate page tables for user-mode execution and kernel-mode execution.

To test the impact of KPTI, Gregg created a microbenchmark and found that Netflix, one the largest users of AWS, is likely to see a performance overhead of between 0.1 percent and six percent due to KPTI. However, others may see much larger overheads.

"The KPTI patches to mitigate Meltdown can incur massive overhead, anything from one percent to over 800 percent," he writes.

Spoiler

"Where you are on that spectrum depends on your syscall and page fault rates, due to the extra CPU cycle overheads, and your memory working set size, due to TLB flushing on syscalls and context switches."


Gregg's analysis looks at five key factors that influence overhead, including system call rates, context switches, page fault rate, the working set size, and cache pattern access. Depending on the measurements for each factor, the performance overhead can balloon from two percent to 17 percent.

The circumstance where the overhead can exceed 800 percent is when using a version of Linux that didn't support PCID or process-context ID.

The Linux kernel added support for PCID in version 4.14, improving its handling of the Meltdown-fixing separate tables so long as the CPU supports PCID too.

Exactly how much the system is impacted depends on the characteristics of the application. As he notes, applications with higher system call, or syscall, rates, such as proxies and databases that do lots of tiny I/O, will suffer the largest losses. The impact also rises with higher context switch and page fault rates.

Gregg offered the following summary:

• Syscall rate: There are overheads relative to the syscall rate, although high rates are needed for this to be noticeable. At 50,000 syscalls per second per CPU, the overhead may be two percent, and climbs as the syscall rate increases. At Netflix, high rates are unusual in the cloud, with some exceptions, such as databases.

• Context switches: These add overheads similar to the syscall rate, and the context switch rate can simply be added to the syscall rate for the following estimations.

• Page fault rate: Adds a little more overhead as well, for high rates.

• Working set size, hot data: More than 10MB will cost additional overhead due to TLB flushing. This can turn a one percent overhead (syscall cycles alone) into a seven percent overhead. This overhead can be reduced by a) PCID, available in Linux 4.14, and b) huge pages.

• Cache access pattern: The overheads are exacerbated by certain access patterns that switch from caching well to caching a little less well. Worst case, this can add an additional 10 percent overhead, taking, say, the seven percent overhead to 17 percent.

He expects Netflix will be able to reduce the performance overhead to less than two percent by using Linux 4.14 with PCID support, huge pages, syscall reductions and other methods to fine-tune performance.

However, Gregg notes that KPTI is only one source of performance overheads in the fixes for Meltdown and Spectre, which include cloud hypervisor changes, Intel's microcode, and compilation changes such as Google's Retpoline fix.


Brendan Gregg has set out the cost of extra CPU cycles in the syscall path.

 

Microsoft delivers free Meltdown-Spectre assessment tool for IT pros
Protecting an organization from attacks based on two widespread and potentially deadly security vulnerabilities requires monitoring software, firmware, and antivirus updates. New capabilities in Microsoft's Windows Analytics service display that status on a single dashboard.
By Ed Bott for The Ed Bott Report | February 13, 2018 -- 17:00 GMT (09:00 PST)
http://www.zdnet.com/article/microsoft-delivers-free-meltdown-spectre-assessment-tool-for-it-pros/

Spoiler: Article...

"If you're an IT pro and you haven't been sleeping soundly since the New Year, blame Meltdown and Spectre. These serious security flaws, more formally known as "speculative execution side-channel attacks," are present in all modern CPUs and represent the sort of problem that can keep any network admin up at night.

The biggest challenge is keeping track of all the pieces that need to be patched. To fully protect your Windows PCs from the inevitable attacks aimed at these vulnerabilities, you'll need to apply multiple software patches and update the BIOS or firmware on the underlying hardware.

(For more details, see "Meltdown-Spectre:Four things every Windows admin needs to do now.")

If your organization has standardized on third-party antivirus software, you'll also have to assess whether that software is compatible with those software and firmware patches. (You might also need to edit the registry on affected PCs to unblock security updates for those devices.)

Oh, and if you installed one of the early, defective firmware patches, which were the cause of " higher than expected reboots and other unpredictable system behavior," you might have still one more item to add to your checklist: Undo the January 2018 update (KB4078130) that temporarily disabled the software mitigations.

But don't do that until the PC maker pushes out a new firmware update to replace the defective one.

If you're responsible for a single PC, that checkup is easy to do manually. In a small office with a half-dozen PCs, it's a tedious but manageable task.

On a network with hundreds or thousands of Windows PCs, however, inspecting and patching every device by hand is impractical.

To address that acute problem, Microsoft announced today that it's releasing a new set of tools to help Windows admins assess what they need to do to protect their enterprise PCs from Meltdown and Spectre.

These capabilities are available through the free Windows Analytics service, which collects data from an organization's registered devices using the built-in Windows telemetry service and displays the aggregated protection status on a single dashboard like the one shown here.


These capabilities are newly added to the Windows Analytics dashboard.

Spoiler: Tool details...

Image credit: Microsoft
The Windows Analytics capabilities are available on Pro, Enterprise, and Education editions of all supported desktop versions of Windows: Windows 7 with Service Pack 1, Windows 8.1, and Windows 10. Setting up the service requires an Azure Active Directory account, which is also free. (If your organization has a business or enterprise Office 365 subscription, you already have the Azure AD infrastructure in place.)

As the screenshot above illustrates, the dashboard displays three crucial pieces of information, called status insights:

• Antivirus software status: Most third-party antivirus software has been updated to be compatible with the Windows security updates for Spectre and Meltdown. This status insight should identify any devices that still require updates.
• Windows security update status: This panel shows which security updates have been installed on a device that's being monitored and also indicates whether any of those updates have been disabled. This status insight includes information for all original January 2018 updates as well as the updates released as part of the February 2018 Patch Tuesday release. (For a complete list of software updates by edition, see "Protect your Windows devices against Spectre and Meltdown" [KB4073757].)
• Firmware security update status: In an interview ahead of today's announcement, Klaus Diaconu, Partner Group Program Manager at Microsoft, acknowledged that this piece of the puzzle is "still evolving." Intel pulled its original microcode updates, and some of the PC makers who were burned with the initial batch of defective updates are being more cautious with the latest round of updates.

From that dashboard, an IT pro can drill down into groups and even to specific devices to determine what actions are still required.

Most large organizations already have update management tools in place to deliver Windows security patches and antivirus updates as needed. Firmware updates are potentially the most problematic, as they don't always allow for automated updates from a centralized server.

This is not a problem for Microsoft's Surface devices, which deliver firmware and other system software updates through Windows Update. For other PC OEMs, the update workflow might be more challenging, and it might be weeks or months before the required updates are available.

In the short run, this service solves a serious problem for harried IT pros. In the long run, it also represents an opportunity for Microsoft to introduce its relatively new Windows Analytics service to a generation of admins who haven't tried it yet. Because, sadly, the Meltdown-Spectre cleanup is going to be a long process, with more updates to come.

Windows Analytics
Windows Analytics now provides insights into device status for Meltdown and Spectre
https://www.microsoft.com/en-us/windowsforbusiness/windows-analytics

 

If it's as little impact as last time, I might update others, but that's why I do this in the first place. I guess if you only have in-use systems to test with, better your sis's than yours.

 

What a nice brother. Use his sister as Guinea Pig Some better?

 

Updated my desktop with these latest updates, but did do a Macrium Reflect image beforehand just in case! Update went fine, and haven't discovered any issues yet. Just did a quick 3DMark and Timespy benchmark to check performance, that's the same. Couldn't really find any negative reports about this update when I looked about a couple of hours ago.

 

She won't let me near her PC, so I have to update it offline when she goes to College. Too much hassle and she isn't bothered by slow-downs and telemetry and other ****.
Maybe I'll turn ON auto-updates because I am finding it an hassle to do background work and optimising the PC for peak performance.

 

Hate to ruin your day, but... Boffins cook up fresh Meltdown, Spectre CPU design flaw exploits
And upcoming hardware changes may not be enough to kill off these security bugs
By Thomas Claburn in San Francisco 14 Feb 2018 at 23:50
https://www.theregister.co.uk/2018/02/14/meltdown_spectre_exploit_variants/

"When details of the Meltdown and Spectre CPU security vulnerabilities emerged last month, the researchers involved hinted that further exploits may be developed beyond the early proof-of-concept examples.

It didn't take long. In a research paper – "MeltdownPrime and SpectrePrime: Automatically-Synthesized Attacks Exploiting Invalidation-Based Coherence Protocols" – out this month, bit boffins from Princeton University and chip designer Nvidia describe variants of Meltdown and Spectre exploit code that can be used to conduct side-channel timing attacks.

In short, the team have discovered new ways for malware to extract sensitive information, such as passwords and other secrets, from a vulnerable computer's memory by exploiting the Meltdown and Spectre design blunders in modern processors. The software mitigations being developed and rolled out to thwart Meltdown and Spectre attacks, which may bring with them performance hits, will likely stop these new exploits.

Crucially, however, changes to the underlying hardware probably will not: that is to say, whatever Intel and its rivals are working on right now to rid their CPU blueprints of these vulnerabilities may not be enough. These fresh exploits attack flaws deeply embedded within modern chip architecture that will be difficult to engineer out.

Before you panic: don't. No exploit code has been released.

Spoiler

Patterns
How did we get here? Well, Princeton computer science professor Margaret Martonosi, doctoral candidate Caroline Trippel, and Nvidia senior research scientist Daniel Lustig developed an unnamed tool – to be discussed in a subsequent paper – that models computer chip microarchitectures to analyze specific execution patterns, such as Meltdown-Spectre-based timing attacks.

They used their tool to explore fresh methods to trigger the Meltdown and Spectre design faults, and in the process identified new ways to exploit the processor flaws. These latest exploit techniques are dubbed MeltdownPrime and SpectrePrime.

One way in which the offshoots differ from their predecessors is that they are two-core attacks – they use two CPU cores against each other – and leverage the way memory is accessed in multi-core systems.

The Meltdown and Spectre design flaws are a result of chip makers prioritizing speed over security.

Modern processors execute software instructions out of order in an effort to efficiently use all or most of their computing resources at any one given moment. This is faster than processing the instructions in a serial fashion, one after the other, which would leave sections of the chip idling. The CPU cores will also execute instructions speculatively, benefiting from a performance boost if they guess correctly which paths a program will take through its code.

Malicious software exploiting Meltdown and Spectre leverages these processor design characteristics to obtain privileged data, such as personal information, that it shouldn't be able to access.

Because accessing CPU memory is comparatively slow, chips include pools of faster memory called caches. The problem with having multiple memory units is you may end up with multiple copies of your data across a system.

Thus there are cache coherence protocols which ensure that multiple processor cores can share a consistent view of the state of the cached data and the system's memory. Through various operations, the state of a cache may be changed from, say, shared to invalid or from exclusive to modified.

Meltdown and Spectre are referred to as side-channel attacks because they exploit unanticipated side effects arising from these processor design characteristics.

Cache-based side-channel attacks involve attempts to discover privileged knowledge about a target application as it executes, in order to use that information against the host system.

Lock and load
The MeltdownPrime and SpectrePrime variants are based on cache invalidation protocols and utilize timing attack techniques known as Prime+Probe and Flush+Reload, which provide insight into how the victim is using cache memory.

"In the context of Spectre and Meltdown, leveraging coherence invalidations enables a Prime+Probe attack to achieve the same level of precision as a Flush+Reload attack and leak the same type of information," the paper explained. "By exploiting cache invalidations, MeltdownPrime and SpectrePrime – two variants of Meltdown and Spectre, respectively – can leak victim memory at the same granularity as Meltdown and Spectre while using a Prime+Probe timing side-channel."

The variants are similar to the earlier attacks developed for Meltdown and Spectre, but they're not identical.

"Where Meltdown and Spectre arise by polluting the cache during speculation, MeltdownPrime and SpectrePrime are caused by write requests being sent out speculatively in a system that uses an invalidation-based coherence protocol," the paper explained.

The researchers found that the cache coherence protocol "may invalidate cache lines in sharer cores as a result of a speculative write access request even if the operation is eventually squashed."

Considerations
The SpectrePrime proof-of-concept exploit was successfully run on an Apple Macbook with a 2.4GHz Intel Core i7 processor running macOS Sierra, aka version 10.12.6. (Apple's Spectre patch arrived in macOS High Sierra 10.13.2.) MeltdownPrime has not yet been tested on real-world hardware.

The researchers suggest that while software fixes for the original flaws will also neuter variant attacks, hardware changes may not be adequate.

"Given our observations with mfence and lfence successfully mitigating Spectre and SpectrePrime in our experiments, we believe that any software techniques that mitigate Meltdown and Spectre will also be sufficient to mitigate MeltdownPrime and SpectrePrime," the paper concluded. "On the other hand, we believe that microarchitectural mitigation of our Prime variants will require new considerations."

Intel, the chipmaker most affected by these flaws, incidentally just announced an extension of its bug bounty program – just through the end of 2018 – covering side-channel vulnerabilities, with awards of up to $250,000.

We asked Intel for comment on the aforementioned research. A spokesperson was not immediately available.

Updated to add
In a statement provided to The Register via email after this story was published, an Intel spokesperson suggested existing hardware mitigations would be adequate without specifically addressing the doubts raised by the researchers.

“We have received a copy of the research report,” the spokesperson said. “The side-channel analysis methods described in that report are similar to techniques disclosed by Google Project Zero and referred to as Spectre and Meltdown. Intel anticipates that the mitigations for Spectre and Meltdown will be similarly effective against the methods described in that report.”

 

Hands up who HASN'T sued Intel over Spectre, Meltdown chip flaws
Chipzilla says class-action lawsuit tally stands at 32
By Shaun Nichols in San Francisco 17 Feb 2018 at 00:42
https://www.theregister.co.uk/2018/02/17/intel_says_32_suits_filed/

"Intel says it is facing 32 separate class-action lawsuits following the revelations it shipped millions of processors with security design flaws dubbed Meltdown and Spectre.

The figure was slipped into its annual 10-K financial filing, submitted earlier this week to the US Securities and Exchange Commission (SEC).

Speaking to the risks Intel faced as a company, the form outlined the bevy of legal complaints that have arisen following reports the bugs can be exploited by malware to extract passwords and other secrets from a computer's memory.

Shortly after the bugs were disclosed, talk began of filing lawsuits on the behalf of both customers who purchased the vulnerable chips and investors who noted that Intel execs including CEO Brian Krzanich sold off shares around the time Intel began spreading word of the flaws.

Now, Intel says, the lawsuits number more than two dozen.

"As of February 15, 2018, 30 customer class action lawsuits and two securities class action lawsuits have been filed. The customer class action plaintiffs, who purport to represent various classes of end users of our products, generally claim to have been harmed by Intel's actions and/or omissions in connection with the security vulnerabilities and assert a variety of common law and statutory claims seeking monetary damages and equitable relief," Intel writes on the form.

"The securities class action plaintiffs, who purport to represent classes of acquirers of Intel stock between July 27, 2017 and January 4, 2018, generally allege that Intel and certain officers violated securities laws by making statements about Intel's products and internal controls that were revealed to be false or misleading by the disclosure of the security vulnerabilities."

If Intel ends up having to settle the complaints, it would add to what is already expected to be a substantial cost incurred in the clean-up effort from the two flaws.

In addition to the class action suits, Intel says it also faces a trio of individual complaints from shareholders that were filed in California Superior Court.

"The complaints allege that the defendants breached their duties to Intel in connection with the disclosure of the security vulnerabilities and the failure to take action in relation to alleged insider trading."

Intel goes on to say that it disputes the claims, and plans to defend itself against the charges in court."

Update: Now it's 35 lawsuits...

Spectre and Meltdown are now a legal pain for Intel — the chip maker faces 35 lawsuits over the attacks
http://www.businessinsider.com/35-l...gainst-intel-over-spectre-and-meltdown-2018-2

• "Intel disclosed Friday it now faces 35 lawsuits related to the Spectre and Meltdown attacks.
• Customers are charging they were harmed by the attacks; shareholders charge that Intel misled them about the state of its business, because it didn't disclose them sooner.
• At least one shareholder suit is taking aim at alleged insider trading at Intel; questions have been raised about a massive stock sale by the company's CEO after Intel was informed of the attacks but before it disclosed them to the public.

The Spectre and Meltdown attacks were a public relations nightmare for Intel. Now they've become a legal headache as well."

 

Intel CEO: New Products that Tackle Meltdown, Spectre Threats Coming this Year
https://www.darkreading.com/endpoin...30920?_mc=rss_x_drr_edt_aud_dr_x_x-rss-simple"

"In an earnings call yesterday, Intel CEO Brian Krzanich says security remains a 'priority' for the microprocessor company.

Intel CEO Brian Krzanich told analysts in the company's earnings call yesterday that Intel will unveil new products "later this year" that mitigate the Meltdown and Spectre vulnerabilities.

"Our near term focus is on delivering high quality mitigations to protect our customers infrastructure from these exploits. We're working to incorporate silicon-based changes to future products that will directly address the Spectre and Meltdown threats in hardware. And those products will begin appearing later this year," Krzanich said.

Intel has been under fire in the wake of recently discovered Meltdown and Spectre hardware vulnerabilities in most of its modern processors, which allow for so-called side-channel attacks. With Meltdown, sensitive information in the kernel memory is at risk of being accessed nefariously; with Spectre, a user application could read the kernel memory as well as that of another application. The end result: an attacker could read sensitive system memory containing passwords, encryption keys, and emails — and use that information to help craft a local attack.

In a post early this week, Intel called for customers and OEMs to halt installation of patches for its Broadwell and Haswell microprocessors after widespread reports of spontaneous rebooting of systems affixed with the new patches. Intel said it plans to issue a fix for the Meltdown-Spectre vulnerabilites.

Meanwhile, Krzanich told analysts on the earnings call: "Security has always been a priority for us and these events reinforce our continuous mission to develop the world's most secured products. This will be an ongoing journey, but we're committed to the task and I'm confident we’re up to the challenge. To keep you informed, we've created a dedicated website and we're approaching this work with customer-first urgency. I've assigned some of the very best minds at Intel to work through this and we're making progress."

Read more here and from an exerpt from the call transcript, here. "

 

Everything On The Meltdown + Spectre CPU Flaws! Rev. 3.0
Posted by Dr. Adrian Wong Date: February 17, 2018
https://www.techarp.com/articles/meltdown-spectre-cpu-flaws/

"The Meltdown and Spectre CPU flaws that the Google Project Zero team discovered are arguably the worst we have ever known. These vulnerabilities were built into BILLIONS of CPUs that we have been using for the last decade or so.

Not just Intel CPUs, but also CPUs made by AMD, Apple and ARM. Even those that power our smartphones and other smart devices!

Let’s take a look at what we know so far about Meltdown and Spectre, how they affect you, and what we can do about them.

This story is still developing. We will update the article as and when new details emerge. Be sure to check back and refresh the page for the latest information!

Spoiler

The Meltdown + Spectre Vulnerabilities

• The Project Zero team identified these vulnerabilities in 2017, reporting it to Intel, AMD and ARM on 1 June 2017.
• These vulnerabilities take advantage of the Speculative Execution and Branch Predictionfeatures of the modern processor, that have been used for many years to improve performance.
• Speculative Execution lets the CPU predict and pre-execute the next instruction, allowing it to “instantly” deliver the results if it’s correct.
• Branch Prediction helps the CPU predict future execution paths that should be speculatively-executed for better performance.
• There are THREE (3) variants of the speculative execution CPU bug :
  • 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)
• The Spectre attack (whitepaper) exploits variants 1 and 2.
• The Meltdown attack (whitepaper) exploits variant 3.
• There is a Variant 3a, which appears to affect only certain ARM processors.

What’s The Difference Between Meltdown & Spectre?

• Spectre tricks the CPU branch predictor into mis-predicting the wrong path, thereby speculatively executing code that would not otherwise be executed.
• Meltdown takes advantage of the out-of-order execution capability of modern processors, tricking them into executing malicious code that would normally not be allowed.
• The Spectre name is based on both the root cause – speculative execution, and the fact that it is not easy to fix, and will haunt us for a long time like a spectre (ghost).
• The Meltdown name was chosen because the vulnerability “basically melts security boundaries which are normally enforced by the hardware“.

How Bad Are Meltdown & Spectre?

• The Spectre exploits let an attacker access and copy information from the memory space used by other applications.
• The Meltdown exploit lets an attacker copy the entire physical memory of the computer.
• Unless patched, the affected processors are vulnerable to malware and cyberattacks that exploits this CPU bug to steal critical information from running apps (like login and credit card information, emails, photos, documents, etc.)
• While the Meltdown exploit can be “fixed”, it is likely that the Spectre exploit cannot be fixed, only mitigated, without a redesign of the processors. That means we will have to live with the risks of a Spectre attack for many more years to come.

How Many Processors Are Affected? Updated!
For the complete list of affected AMD, Apple, ARM and Intel processors, please see this separate article – The Complete List Of CPUs Vulnerable To Meltdown / Spectre

Company Spectre 1 Spectre 2 Meltdown
AMD 295 Server CPUs
42 Workstation CPUs
396 Desktop CPUs
208 Mobile CPUs 295 Server CPUs
42 Workstation CPUs
396 Desktop CPUs
208 Mobile CPUs None
Apple 13 Mobile SoCs 13 Mobile SoCs 13 Mobile SoCs
ARM 10 Mobile CPUs
3 Server SoCs 10 Mobile CPUs
3 Server SoCs 4 Mobile CPUs
3 Server SoCs
IBM 10 POWER CPUs 10 POWER CPUs 10 POWER CPUs
Intel 732 Server / Workstation CPUs
443 Desktop CPUs
583 Mobile CPUs
51 Mobile SoCs 732 Server / Workstation CPUs
443 Desktop CPUs
583 Mobile CPUs
51 Mobile SoCs 732 Server / Workstation CPUs
443 Desktop CPUs
583 Mobile CPUs
51 Mobile SoCs
Total 2786 CPUs 2786 CPUs 1839 CPUs

For the complete list of affected AMD, Apple, ARM and Intel processors, please see this separate article – The Complete List Of CPUs Vulnerable To Meltdown / Spectre

Intel Detection Tool?
The Intel-SA-00086 Detection Tool does NOT detect the processor’s susceptibility to these vulnerabilities. It only checks for different vulnerabilities affecting the Intel Management Engine.

InSpectre
Our reader Arthur shared that the Gibson Research Corporation has an aptly-named utility called InSpectre.

It checks for Meltdown and Spectre hardware and software vulnerabilities in a Windows system. It will help you check if your system is getting patched properly against these vulnerabilities.

What Is Being Done??? Updated!
Note : The terms “ mitigate” and “ mitigation” mean the possibility of a successfully attacked are reduced, not eliminated.

• Intel has started issuing software and firmware updates for the processors introduced in the last 5 years. By the middle of January 2018, Intel expects to have issued updates for more than 90% of those CPUs. However, that does not address the other Intel processors sold between 2010 and 2012.
• Microsoft and Linux have started to roll our the KPTI (Kernel Page Table Isolation) patch, also known as the KAISER (Kernel Address Isolation to have Side-channels Efficiently Removed) patch.
• The KPTI or KAISER patch, however, will only protect against the Meltdown exploit. It has no effect on a Spectre attack.
• Microsoft Edge and Internet Explorer 11 received the KB4056890 security update on 3 January 2018, to prevent a Meltdown attack.
• Firefox 57 includes changes to mitigate against both attacks.
• Google Chrome 64 will be released on 23 January 2018, with mitigations against Meltdownand Spectre attacks.
• For Mac systems, Apple introduced mitigations against Spectre in macOS 10.13.2 (released on 8 January 2018), with more fixes coming in macOS 10.13.3.
• For iOS devices, Apple introduced mitigations against Meltdown in iOS 11.2 and tvOS 11.2.
• On 8 January 2018, Apple released iOS 11.2.2, which mitigates the risk of the two Spectre exploits in Safari and WebKit, for iPhone 5s, iPad Air, and iPod touch 6th generation or later.
• ARM has made available the KPTI / KAISER kernel patches for Linux, while Google will provide them for Android.
• Google patched Android against both exploits with the December 2017 and January 2018patches.
• Google shared details of their Return Rrampoline (Retpoline) binary modification technique that can be used to protect against Spectre attacks. It is a software construct that ensures that any associated speculative execution will “bounce” (as if on a trampoline) endlessly.
• NVIDIA issued six driver and security updates for affected devices and software between 3-9 January 2018.
• On 11 January 2018, AMD announced that the “majority of AMD systems” have received the mitigation patches against Spectre 1, albeit some older AMD systems got bricked by bad patches. They also announced that they will make “optional” microcode updates available forRyzen and EPYC processors by the same week.
• In the same 11 January 2018 disclosure, AMD also shared that Linux vendors have started to roll out OS patches for both Spectre exploits, and they’re working on the “return trampoline (Retpoline)” software mitigations as well.
• On 23 January 2018, Apple released Meltdown patches for macOS Sierra and OS X El Capitan, but not macOS High Sierra.
• On 23 January 2018, Microsoft finally revealed their Spectre and Meltdown patch schedule.
• On 24 January 2018, AMD revealed their 11 software mitigations for both Spectre exploits.
• The 24 January 2018 AMD whitepaper also revealed that the AMD K10 and K8 processors are vulnerable as well, adding anadditional 663 CPU models to the list of vulnerable processors.
• On 2 February 2018, Microsoft released KB4078130 to disable the Spectre 2 patches that were causing many Intel systems to randomly and spontaneously reboot.
• On 8 February 2018, an Intel microcode update schedule revealed that their Penryn-based processors are also vulnerable, adding an additional 314 CPU models to the list of vulnerable processors.
• On 14 February 2018, Intel revealed an expanded Bug Bounty Program, offering up to $250,000 in bounty awards.

Some AMD PCs Got Bricked
In the rush to mitigate against Meltdown and Spectre, Microsoft released Windows 10 patches that bricked some AMD PCs. They blamed the incorrect / incomplete documentation provided by AMD.

You can read more about this issue @ These Windows 10 Updates Are Bricking AMD PCs!

Buggy Intel Spectre 2 Patches Updated!
Intel’s rush to patch Meltdown and Spectre resulted in buggy microcode patches, causing several generations of their CPUs to randomly and spontaneously reboot.

So far, over 800 Intel CPU models have been identified to be affected by these spontaneous reboot issues. If you have one of the affected CPUs, please hold off BIOS / firmware updates!

Intel has identified the cause as the Spectre 2 patches in their microcode updates for some of these processors. They’re still investigating the cause of the other affected CPU models.

Fortunately for Windows users, Microsoft issued the KB4078130 emergency update to stop the reboots while Intel worked to fix the issue.

You can read more about this issue @ The Intel Spectre Reboot Issue, and the Microsoft solution @ KB4078130 : Emergency Windows Update To Disable Intel Spectre Patches!

What Should You Do? Updated!
First and foremost – DO NOT PANIC. There is no known threat or attack using these exploits.

Although we listed a number of important patches below, the buggy updates are worse than the potential threat they try to fix. So we advise HOLDING OFF these patches, and wait for properly-tested versions a few weeks down the line.

• If you are using Windows, make sure you install the latest Microsoft Spectre and Meltdown updates.
• If you are using a Mac system, get the latest Apple Spectre and Meltdown patches.
• If you are using an iOS device, get updated to iOS 11.2 or tvOS 11.2.
• If you are using Firefox, update to the latest Firefox 57.
• If you are using Google Chrome, make sure you watch out for Chrome 64, which will be released on 23 January.
• Download and install the latest software firmware updates from your PC, laptop, motherboard brands. In particular, install the latest driver for the Intel Management Engine (Intel ME), theIntel Trusted Execution Engine (Intel TXE), and the Intel Server Platform Services (SPS)
• If you are running an ARM processor on Linux, grab the kernel patches.
• IBM POWER system users can download and install these firmware updates.
• Users of affected NVIDIA systems can download and install these driver and firmware updates.
• If you are using an Intel system, hold off updating your firmware, unless you have already verified that your CPU is not affected by the buggy Intel patches, or Intel has already issued corrected patches.

The Performance Impact Of The Mitigation Patches
Many benchmarks have been released, showing performance impacts of between 5% to 30%, depending on the type of benchmark and workload. Microsoft has called those benchmark results into question, stating that they did not cover both operating system and silicon microcode patches.

They released an initial report on their findings, which we have summarised in our article – Pre-2016 Intel CPUs Hit Worst By Meltdown + Spectre Fix.

Meltdown + Spectre Reading Suggestions

• Everything On The Meltdown + Spectre CPU Flaws!
• The Complete List Of CPUs Vulnerable To Meltdown / Spectre
• The Microsoft Spectre + Meltdown Patch Schedule
• The Intel Spectre Reboot Issue – Everything You Need To Know!
• Intel Penryn CPUs Also Vulnerable To Meltdown + Spectre
• The Complete AMD Spectre Mitigation Strategy Guide
• The Apple Spectre + Meltdown Patches Detailed
• These Windows 10 Updates Are Bricking AMD PCs!
• Pre-2016 Intel CPUs Hit Worst By Meltdown + Spectre Fix
• Yes, AMD CPUs Are Also Vulnerable To Spectre 2 Exploit
• AMD K10 And K8 Processors Also Vulnerable To Spectre
• KB3078130 : Emergency Windows Update To Disable Intel Spectre Patches!

A Clear Guide to Meltdown and Spectre Patches
Updated 2/13/18 at 3:57pm ET with details on how IT pros can now track the vulnerability status for individual machines by using Windows Analytics.
https://blog.barkly.com/meltdown-spectre-patches-list-windows-update-help

"Having trouble keeping up and making sense of all the Meltdown and Spectre patches being released? You're not alone. This guide will help."

Both of these are updated in Post #1.

 

Two new Meltdown and Spectre variants discovered
The new variants might cause some problems for Intel's and AMD's already announced hardware fixes. (Source: Heise.de)
by Bogdan Solca, 2018/02/16
https://www.notebookcheck.net/Two-new-Meltdown-and-Spectre-variants-discovered.284524.0.html

"The latest variants dubbed MeltdownPrime and SpectrePrime were discovered by Nvidia and Princeton University researchers. In a nutshell, these variants force two CPU cores to react to each other in order to trick multi-core systems into giving up cached data.

Even if there were no reports of actual grand-scale hacks that took advantage of the Meltdown / Spectre vulnerabilities found in Intel’s and AMD’s CPU released this decade, there is still a pronounced feeling of unease among the end-users who now demand efficient hardware fixes instead of rushed and poorly optimized fixes that mess up their systems anyway. Meltdown and Spectre first got their spotlight when Google revealed them in early January this year as inherent CPU flaws that can enable unwarranted access to personal info that happens to be stored in the system memory, including passwords, emails and other critical data that can compromise the OS.

While Intel and AMD are already working to include hardware fixes in the upcoming CPU lineups, researchers from Nvidia and Princeton University dug deeper into the underlying flaws and uncovered two new vulnerability variants named “MeltdownPrime” and “SpectrePrime”.

The “MeltdownPrime and SpectrePrime: Automatically-Synthesized Attacks Exploiting Invalidation-Based Coherence Protocols” paper released on February 11 notes that: In the context of Spectre and Meltdown, leveraging coherence invalidations enables a Prime+Probe attack to achieve the same level of precision as a Flush+Reload attack and leak the same type of information. By exploiting cache invalidations, MeltdownPrime and SpectrePrime -- two variants of Meltdown and Spectre, respectively -- can leak victim memory at the same granularity as Meltdown and Spectre while using a Prime+Probe timing side-channel. [...]MeltdownPrime and SpectrePrime are caused by write requests being sent out speculatively in a system that uses an invalidation-based coherence protocol.”

It is not clear if these new variants have already been patched with the latest software fixes, but, more importantly, Intel and AMD have not yet confirmed if these variants will be fixed with the in-silicon solutions to be released in late 2018."

Source(s)
Official Princeton paper
TechSpot

 

CRN Exclusive: Intel Bests ARM and AMD For Its Spectre, Meltdown Exploit Response
by Lindsey O'Donnell on February 19, 2018, 12:00 pm EST
https://www.crn.com/news/components...for-its-spectre-meltdown-exploit-response.htm

" Solution providers are applauding Intel for its response to the Spectre and Meltdown security flaws – including more support and patching services over competitors ARM and AMD, according to an exclusive CRN survey.

"Intel is trying to give its partners as much information as possible in a way that can't be matched … we think that they have continued to handle this in the right way," said Michael Goldstein, president and CEO of Fort Lauderdale, Fla.-based LAN Infotech.

According to the CRN survey, 17 percent of respondents said that Intel's response to the Spectre and Meltdown security flaws was "excellent," while only 9 percent gave AMD such high marks and 4 percent had the same response for ARM.

CRN conducted an online poll of 190 members of the CRN Channel Intelligence Council, a panel of solution providers representing the broad channel ecosystem in North America. In the survey, solution providers ranked the vendor responses to the Spectre and Meltdown vulnerability issue on a scale of one to five, with five being the top mark, or "excellent."

A full 28 percent of survey respondents rated Intel's response as a "4" or "good" while 22 percent had the that description for AMD and 12 percent had that rating for ARM.

Intel partners had high praise for Intel's support, technical and patching services in the wake of the Spectre and Meltdown security flaws, which were revealed in January and have impacted chips from multiple vendors, including Intel, AMD and ARM.

The flaws, which account for three variants of a side-channel analysis security issue in server and PC processors, potentially could enable hackers to access protected data.

Intel has worked to issue patches for these exploits, but the company in January acknowledged that some companies are reporting reboot issues with both older and newer chips – including Skylake chips – for both client compute and data center after they patched their devices.

Most recently, the Santa Clara, Calif.-based company opened a Bug Bounty program focused specifically on side channel vulnerabilities through Dec. 31, 2018 – with an award for disclosures up to $250,000.

AMD, meanwhile, first claimed in January that there is currently "near-zero risk" to its processors related to the Spectre and Meltdown security flaws. However, the company later reversed its statement, acknowledging that two variants of the Spectre vulnerabilities apply to its processors and that it will issue microcode and OS patch updates to protect customers.

On ARM's end, the chip design company said that the "majority of ARM processors" are not impacted by Spectre and Meltdown. However, the company said that exploits are dependent on "malware running locally which means it's imperative for users to practice good security hygiene by keeping their software up-to-date and avoid suspicious links or downloads."

Partners said that Intel's communication was key to the vendor being the most helpful, particularly as the channel is emerging the trusted advisor between manufacturers and customers in the fallout of Spectre and Meltdown.

"We're staying in touch with our Intel reps, and as soon as we hear something from them, we're going back to our customers," said Barrett Lamothe, federal sales team lead at MicroAge, a Tempe, Ariz.-based Intel partner. "Intel has been extremely easy to work with, and has been transparent with the channel through this process. We know that they have all their security guys working on this issue."

Intel declined to comment. ARM and AMD did not respond to requests via email for comment.

Partners also cheered Intel CEO Brian Krzanich's pledge to release processors later this year aimed at eliminating the threat posed by the Spectre and Meltdown exploits.

"Intel did the right thing assuring shareholders and partners that they were 'security first' and announcing that they would replace their technology so customers don't have to worry about the security flaws," said Goldstein.

One partner, who wished to remain anonymous, said that Intel has "been communicating very well" with the channel – but all chip manufacturers could do a better job in being transparent with the public.

"The channel's role so far has been to talk with our customers about this," said the partner. "I think the channel can say things that Intel and AMD cannot. We have been working with vendors on some patches, but the real threat right now is more about consumer confidence.""

 

CRN Research: Google Bests Microsoft And AWS In Cloud Response To Spectre, Meltdown Vulnerabilities
by Gina Narcisi on February 19, 2018, 2:00 pm EST
https://www.crn.com/news/security/3...ponse-to-spectre-meltdown-vulnerabilities.htm

"When news of the far-reaching Spectre and Meltdown exploits first hit, Simon Margolis, cloud platform director for managed service provider Sada Systems, braced for impact.

Margolis worried that customers were about to be walloped thanks to the sweeping hardware vulnerabilities that until now, had laid dormant in the heart of all major operating systems. However, public cloud giant Google had already covered its tracks by taking the necessary remediation steps, and the impact was barely noticed by users.

"To be honest, I freaked out when I first heard about it," Margolis said. "But it was really encouraging to hear that Google was the team that discovered Spectre and Meltdown and had patched all their internal systems already."

Of the three leading cloud providers, Google received the highest scores in a recent CRN survey investigating how vendors responded to the widespread Spectre and Meltdown vulnerabilities.

Sada Systems, a Google Cloud Premier Partner, received notice from Google within a couple of hours of the vulnerabilities coming to light with mitigation instructions. Google, Margolis said, was the first provider to come out with information on the vulnerabilities and what to do about it.

"Google has always been very quick to announce anything security-related -- they really don't have an ego that gets in the way when it comes to serious issues, and this situation was no exception," he said.

CRN conducted an online poll of 190 members of the CRN Channel Intelligence Council, a panel of solution providers representing the broad channel ecosystem in North America. In the survey, solution providers ranked the vendor responses to the Spectre and Meltdown vulnerability issue on a scale of one to five, with five being the top mark, or "excellent."

Google received the highest overall ranking among cloud providers, with 17 percent of respondents saying Google had an "excellent" response and 27 percent rating its response as "good."

By comparison, Microsoft Azure received an "excellent" ranking by 13 percent of respondents, and 27 percent of respondents ranking the cloud provider's response "good."

Amazon Web Services (AWS) following in third place, ranked "excellent" by 8 percent of respondents and "good" by 17 percent of respondents.

Partners said that Google's strong response out of the gate did not come as a surprise; the internet giant has always been very security-minded. Google's own Project Zero -- a team of security analysts employed by Google tasked with finding zero-day vulnerabilities -- first discovered Spectre and meltdown and disclosed the flaw to chipmakers Intel, AMD, and ARM.

Soon after, Google notified more companies, including Amazon and Microsoft, who would also need to patch their cloud platforms. In the end, dozens of competing IT companies collaborated to keep the bugs secret for long enough for many of the industry-leading vendors to respond with updates for their operating systems.

By the time news of Spectre and Meltdown came out publicly, the exploits were mostly uneventful for Agosto, a Minneapolis-based Google partner.

"We didn't have any of our infrastructure clients impacted, and Google was really diligent and handled all of [the mitigation efforts]; we really didn't have to manage that process at all," according to Aric Bandy, president of Agosto.

Six days after Google's CTO office first published a blog post explaining Spectre and Meltdown, Ben Treynor Sloss, vice president of engineering for Google, posted a follow-up blog on January 11 explaining how the cloud provider identified and put patches in place to address the exploits, which he called the "most challenging and hardest to fix in a decade."

He also shared how Google was protecting its cloud customers from new vulnerabilities without impacting performance.

"By December, all Google Cloud Platform services had protections in place for all known variants of the vulnerability. During the entire update process, nobody noticed: we received no customer support tickets related to the updates. This confirmed our internal assessment that in real-world use, the performance-optimized updates Google deployed do not have a material effect on workloads," Sloss said. "In sharing our research publicly, we hope that this can be universally deployed to improve the cloud experience industry-wide."

While Google was quick to respond to Spectre and Meltdown, Los Angeles-based Sada Systems also immediately sent out its own notice to customers filling them in on the vulnerabilities, as well as initial client-side remediation steps to take. All of Sada's end customers today have completed the necessary updates, and are no longer at risk, Margolis said.

"Between what Google and we sent out [to customers], no one reached out to us for further instruction. It ended up not really being an issue," he said.

While Google may have been first, partners say that cloud competitors AWS and Microsoft both also did a commendable job of communicating with partners and end customers, giving both groups a head's up on the issues, as well as recommendations to help mitigate any potential impact to users.

"Microsoft did a pretty good job and so did AWS, but [AWS] kind of handled it in their own, laid-back approach by directing everyone to their blog, so I thought Microsoft was a little bit better in terms of leveraging their channel," according to one Microsoft and AWS solution provider partner that asked to remain anonymous.

Microsoft Azure declined to comment on its mitigation efforts or its response to partners regarding Spectre and Meltdown.

AWS did not respond to CRN's request for comment before publication.

Considering the "awful and wide-ranging nature of vulnerabilities," all three cloud providers handled the situation very well, said Paul Vallee, president and CEO of Pythian, an Ottawa, Ontario-based Google, AWS, and Microsoft partner.

"Given the scale of the problem -- and it was pervasive -- and the difficulty of the solution, I really liked what I saw regarding the reaction of the three major cloud providers," Vallee said. Pythian's customers on AWS, Google and Microsoft cloud platforms are all up to date with the appropriate patching and updates.

Because Google's team first discovered the vulnerabilities, which were revealed to the public in January, the company had a head start patching and updating its environment; it started in September, Vallee said. "As a result, there were no user-visible consequences to Google customers, and that includes performance consequences," he added.

It stands to reason that security is a top priority for a massive target like Google, which owns one of the world's largest network, with millions of endpoints, and customer assets with more than a billion active users. The internet giant's cloud platform consists of homegrown technology because Google has elected to build its own servers, software stack, and operating system.

"I do believe they are leading the charge in security … everything in their environment is proprietary, and I think that is instrumental to Google being able to properly secure and run a network of their size at scale while not compromising speed," said Agosto's Bandy.

However, the internet giant's security efforts often reach outside of the company. Google's Project Zero team is constantly on the hunt, "hacking for good" to continually search out and identify any vulnerabilities so the internet remains a safe place for all companies and end users, Bandy said. "It's almost unfortunate that the market doesn't understand how much emphasis Google puts internally on their approach to security.""

 

Expanding Intel’s Bug Bounty Program: New Side Channel Program, Increased Awards
By Rick Echevarria, February 14, 2018
https://newsroom.intel.com/news/expanding-intels-bug-bounty-program/

"At Intel, we believe that working with security researchers is a crucial part of identifying and mitigating potential security issues in our products. Similar to other companies, one of the ways we’ve made this part of our operating model is through a bug bounty program.

The Intel® Bug Bounty Program was launched in March 2017 to incentivize security researchers to collaborate with us to find and report potential vulnerabilities. This, in turn, helps us strengthen the security of our products, while also enabling a responsible and coordinated disclosure process.

Coordinated disclosure is widely regarded as the best way to responsibly protect customers from security exploits. It minimizes the risk that exploitable information becomes publicly known before mitigations are available.

Working closely with our industry partners and our customers, we encourage responsible and coordinated disclosure to improve the likelihood that users will have solutions available when security issues are first published.

Our Bug Bounty Program supports this objective by creating a process whereby the security research community can inform us, directly and in a timely fashion, about potential exploits that its members discover.

In support of our recent security-first pledge, we’ve made several updates to our program. We believe these changes will enable us to more broadly engage the security research community, and provide better incentives for coordinated response and disclosure that help protect our customers and their data.

Updates to our program include:

Shifting from an invitation-only program to a program that is open to all security researchers, significantly expanding the pool of eligible researchers.

Offering a new program focused specifically on side channel vulnerabilities through Dec. 31, 2018. The award for disclosures under this program is up to $250,000.

Raising bounty awards across the board, with awards of up to $100,000 for other areas.

More details on the program, including these new updates, can be found online on the Intel security site or our HackerOne page.

We will continue to evolve the program as needed to make it as effective as possible and to help us fulfill our security-first pledge. Thank you, in advance, to all of those across the industry who choose to participate.

Rick Echevarria is vice president and general manager of Platform Security at Intel Corporation."

FYI - In the context of this press release, to Intel the side channel vulnerabilities are the code words for hacks taking advantage of Meltdown and Spectre vulnerabilities, and as yet undiscovered related vulnerabilities.

"side channel attack" has a much broader definition:
https://en.wikipedia.org/wiki/Side-channel_attack

Spectre and Meltdown: a new type of software-based side-channel attacks
https://www.riscure.com/blog/spectre-meltdown-new-type-software-based-side-channel-attacks/

 

Intel Completes Spectre Fixes For Skylake, Kaby Lake, And Coffee Lake CPUs

Direct link to latest Intel microcode revision guidance (February 20 2018)

 

Excellent news, looks like MSI will now finally be in a position to produce/release a BIOS fix for my Z170A motherboard, considering it can support both Skylake (microcode previously released) and Kabylake (now released according to your news)!

 

You got that news from somewhere, can you please include a link?

What does "finally in a position" mean? MSI didn't release a Skylake BIOS update, but now that the Kabylake microcode is releasing MSI are "in a position to make an update"? To me that means "hopefully MSI will make an update", not that they will, certainly not that they have done so.

Maybe it's best to wait until MSI has actually made the download available before posting?

 

I'm just making suppositions, nothing to link. All I mean is that MSI now obviously have the fixed microcode for both Skylake & Kabylake, as per Papusans linked news - this would mean that MSI is in a position to incorporate it into their BIOS for my Z170A board (as it supports both Skylake & Kaby), and hopefully this means that an updated BIOS will be released soon - supposition.

 

That's not even at the rumor stage then, just wishful thinking.

The problem is there are a lot of Motherboards out there, and we don't know - many worry - that there won't be enough depth in coverage for BIOS updates - but we've never had this level of problem before, going back 10+ years affecting every Intel motherboard, so it's a complete unknown.

It's possible vendors will be overwhelmed, and they will be forced due to a lack of resources to draw an imaginary line in time, say at the 1 year, or 2 year, or ? year warranty mark for BIOS updates. Out of warranty MB's may never get an update.

Or, there will be government - or Intel - subsidized funding to allow the motherboard makers to push back further in time to make BIOS updates to protect those older systems too. More wishful thinking

No one knows how this is going to work out short and long term.

 

It's also possible some of the OEMs will not care enough to do anything. Case in point being Dell/Alienware doesn't fix anything (usually) that is not a current model for sale on their web site. If it is going to take any time and resources/money, I could see a whole bunch of them taking a position that they do not support EOL products. Likewise, most OEMs provide no driver support for Windoze 10 for systems released prior to Windoze 10. Same was true for Windows 7 driver support on systems designed to run XP. Technically, it is not their problem any more as soon as a product is replaced by something newer.

Great reason to purchase a Clevo from a @Prema Partner Shop. Brother @Prema doesn't leave his partners high and dry like the big boys often do with their customers.

 

Intel ships (hopefully stable) microcode for Skylake, Kaby Lake, Coffee Lake
All 6th, 7th, and 8th generation Core processors now have microcode available.
PETER BRIGHT - 2/21/2018, 11:03 AM
https://arstechnica.com/gadgets/201...-microcode-for-skylake-kaby-lake-coffee-lake/

"Intel reports that it has developed a stable microcode update to address the Spectre flaw for its Skylake, Kaby Lake, and Coffee Lake processors in all their various variants.

The microcode updates help address Spectre variant 2 attacks. Spectre variant 2 attacks work by persuading a processor's branch predictor to make a specific bad prediction about which code will be executed. This bad prediction can then be used to infer the value of data stored in memory, which, in turn, gives an attacker information that they shouldn't otherwise have. The microcode update is designed to give operating systems greater control over the branch predictor, enabling them to prevent one process from influencing the predictions made in another process.

Intel's first microcode update, developed late last year, was included in system firmware updates for machines with Broadwell, Haswell, Skylake, Kaby Lake, and Coffee Lake processors. But users subsequently discovered that the update was causing systems to crash and reboot. Initially, only Broadwell and Haswell systems were confirmed to be affected, but further examination determined that Skylake, Kaby Lake, and Coffee Lake systems were rebooting, too.

A new microcode for mainstream Skylake processors was released earlier this month. The latest microcode covers both Skylake variants, such as Skylake X (used in the newest Core X and Xeon-W processors), Skylake D (used in the latest Xeon D chips) and Skylake SP (used in Xeon Scalable Processor), and the post-Skylake mainstream chips, branded as 7th and 8th generation Core, and codenamed Kaby Lake and Coffee Lake.

Older processors using the Broadwell and Haswell cores still do not have a fixed microcode update available. Intel claims that microcode fixes for Sandy Bridge, Ivy Bridge, Broadwell, and Haswell processors are in beta. This means that Intel has distributed a microcode update to hardware vendors for testing, protected under NDA. A handful of older chips are described as having their microcode updates in "pre-beta," meaning that Intel is performing internal validation of the fix prior to the "beta" stage external testing.

In general, PC users will have to wait for their system or motherboard vendor to provide an updated firmware that contains the microcode."

Latest Intel Security News: Updated Firmware Available for 6th, 7th and 8th Generation Intel Core Processors, Intel Xeon Scalable Processors and More
By Navin Shenoy , February 20, 2018
https://newsroom.intel.com/news/latest-intel-security-news-updated-firmware-available/

"Over the past several weeks, we’ve been developing and validating updated microcode solutions to protect Intel customers against the security exploits disclosed by Google Project Zero. This effort has included extensive testing by customers and industry partners to ensure the updated versions are ready for production. On behalf of all of Intel, I thank each and every one of our customers and partners for their hard work and partnership throughout this process.

More: Security Exploits and Intel Products (Press Kit) | Security Research Findings (Intel.com)

Based on these efforts, we have now released production microcode updates to our OEM customers and partners for Kaby Lake- and Coffee Lake-based platforms, plus additional Skylake-based platforms. This represents our 6th, 7th and 8th Generation Intel® Core™ product lines as well as our latest Intel® Core™ X-series processor family. It also includes our recently announced Intel® Xeon® Scalable and Intel® Xeon® D processors for data center systems.

The new microcode will be made available in most cases through OEM firmware updates. I continue to encourage people to always keep their systems up-to-date. There is also a comprehensive schedule and current status for planned microcode updates available online.

We are mindful of the fact that, in some cases, there are multiple mitigation techniques available that may provide protection against these exploits. This includes “Retpoline,” a Google-developed mitigation technique for Variant 2. For those interested in more information on Retpoline and how it works, we recently published a new white paper. Google has also posted information about Retpoline.

I look forward to sharing additional updates soon. Again, I extend my sincere appreciation to all Intel customers and industry partners for their ongoing support.

Navin Shenoy is executive vice president and general manager of the Data Center Group at Intel Corporation."

 

Anybody worries of this bulshit? Won't it cause slowdowns?

 

If you have installed MSFT's new update which disables OS level fixes, then slowdown is minimal. You will notice 10% less performance in 4k Disk benching SW like CDM, AS-SSD etc..

 

Thanks @Papusan for notifying about typo. Sometime I eat some words whilst typing and my damn auto-correct dictionary actually has hallucinations that make me believe I have typed it correct.
This is the exe file that disables the fix(KB4078130) https://www.catalog.update.microsof...459594)(nOD_rLJHOac-YJXEC13kjGJLhkF.4JaVqg)()

 

Well, MSI have committed to updating a lot of their motherboards with regards to Spectre, and certainly the Z170A board that I have:
https://www.msi.com/news/detail/OkG...rTL9kD4wPpTAxIJCC2sBeYjNfGz221AA2yAjPZIzXKw~~

 

Intel's new Spectre fix: Skylake, Kaby Lake, Coffee Lake chips get stable microcode
Intel makes progress on reissuing stable microcode updates against the Spectre attack.
By Liam Tung | February 21, 2018 -- 11:57 GMT (03:57 PST)
http://www.zdnet.com/article/intels...-lake-coffee-lake-chips-get-stable-microcode/

"Customers running machines with newer Intel chips can expect to receive stable firmware updates for the Spectre CPU attack Variant 2 soon.

Intel says it has given PC makers a new set of microcode updates that mitigate the branch target injection Spectre attack on its 6th, 7th, and 8th generation Intel Core chips.

It also has new updates for its latest Core X-Series and Intel Xeon Scalable and Xeon D processors for datacenters.

"We have now released production microcode updates to our OEM customers and partners for Kaby Lake- and Coffee Lake-based platforms, plus additional Skylake-based platforms," Intel vice president Navin Shenoy said on Tuesday.

The updates signal that Intel is making progress on reissuing stable microcode mitigations for the Spectre attack revealed by Google on January 3.

Intel on January 22 said it had identified the root cause of unexpected reboots on updated Broadwell and Haswell chips and advised PC makers to stop deploying its mitigations for the Variant 2 attack.

It initially said the reboots were only occurring on Broadwell and Haswell processors but later admitted its patch was also causing stability issues on Skylake and Kaby Lake chips.

Dell, HP, and Lenovo paused their respective BIOS updates while Intel worked on stable fixes. Microsoft also released an out-of-band patch to disable Intel's fix on systems it had been installed on.

Earlier this month Intel released new microcode for several Skylake chipsbut didn't disclose the status of Broadwell and Haswell chips.

It now has updated its guidance with the current status of microcode updates for various generations of chips, which now indicates that fixes for Broadwell, Haswell, Sandy Bridge and some Ivy Bridge chips have reached beta. It also has production updates available for Apollo Lake and Cherry View and Bay Trail chips.

The chip giant last week revealed it is facing 32 class action lawsuits over the Meltdown and Spectre vulnerabilities, and additional lawsuits over alleged insider trading.

Intel last week published a new whitepaper explaining how Google's software-based fix for Variant 2 called Retpoline works. The search company found Retpoline doesn't cause the performance overhead that Intel's earlier mitigations did.

"There are a number of possible mitigation techniques for the branch target injection Spectre variant 2 exploit. The Retpoline mitigation technique presented in this document is resistant to exploitation and has attractive performance properties compared to other mitigations," Intel notes in the paper."

 

(We know this already right, Papusan linked an article on the previous page yesterday, which is how our conversation started)

 

I don't see papusan's posts, I am ignoring him. I posted it, including Intel's press release.

The point is nothing has changed from our earlier exchange, there are no new BIOS's to download, we are still waiting. That was the purpose of posting that whole article, so you will read it and notice it is dated 1 month after your BIOS downloads post - which was dated just before Intel pulled their Spectre microcode patches.

Intel just released Kabylake Spectre microcode, it'll take time for the vendors to build and test BIOS updates, and I'm sure they will take more time testing them before releasing them to customers this time, that is if they wise up and don't assume Intel is doing adequate testing before rushing them to vendors.

Hope springs eternal, but we can't download it.

 

AMD Hit With Multiple Lawsuits Over Spectre Chip Exploits-Hothardware.com
Yeees. Amd is the only choice All talk about Intel's flaws, but AMD's micro architecture is almost brand new!!

"Despite its knowledge of the Spectre defect, AMD continued to sell its processors to unknowing customers at prices much higher than what customers would have paid had they known about the Spectre defect and its threat to critical security features as well as on the processing speeds of the devices they purchased," one of the lawsuits alleges.

"Defendant has been unable or unwilling to repair the security vulnerabilities in the subject CPUs or offer Plaintiff and class members a non-defective CPU or reimbursement for the cost of such CPU and the consequential damages arising from the purchase and use of such CPUs," reads another lawsuit.​

The second lawsuit goes on to claim that AMD's software patches have not been adequate in protecting affected customers from all variants of Spectre, and that firmware updates will be required. "Even then, these 'patches' dramatically degrade CPU performance," the lawsuits states.

 

If at first you don't succeed, you're likely Intel: Second Spectre microcode fix emitted
Mitigations for chip design vulnerabilities, take two
By Paul Kunert 21 Feb 2018 at 16:11
https://www.theregister.co.uk/2018/02/21/intel_spectre_2_microcode_patch/

" Updated For the second time of asking, Intel has issued microcode updates to computer makers that it prays says will mitigate the Spectre variant two design flaw impacting generations of x86 CPUs spewed out over previous decades.

Yep, old Chipzilla has turned up at the scene of the metaphorical IT industry earthquake with a dustpan and brush*: the firmware updates are for the sixth generation (Skylake), the seventh generation (Kaby Lake) and the eight generation (Coffee Lake), the X-series line and the Xeon scalable and Xeon D processors.

Since 2 January, when The Register exposed the existence of the Meltdown and then Spectre chip design blunders, Intel and other CPU vendors have been working to mitigate the vulnerabilities.

The 12 January release of the firmware updates for Meltdown and Spectre made PCs and servers less stable, and so vendors including Lenovo, VMware and Red Hat delayed rolling out patches.

“We have now released production microcode updates to our OEM customers and partners,” said Navin Shenoy, veep and GM for mobile client platforms at Intel. “The microcode will be made available in most cases through OEM firmware updates”.

Intel said the firmware is in beta mode for Sandy Bridge, Ivy Bridge, Haswell and Broadwell. The microcode patch update schedules for the chips are here.

Shenoy said there are “multiple mitigation techniques available that may provide protection against these exploits”, including Google-developed binary modification technique Retpoline ( white paper here).

According to Google: “Retpoline sequences are a software construct which allow indirect branches to be isolated from speculative execution.

“This may be applied to protect sensitive binaries (such as operating system or hypervisor implementations) from branch target injection attacks against their indirect branches”.

Retpoline is a portmanteau of return and trampoline: it is a trampoline construct built using return operations which “also figuratively ensures that any associated speculative execution will ‘bounce' endlessly.”

Intel, which is facing 32 separate lawsuits in the US over Spectre and Meltdown - from both customers and investors - extended its “appreciation” to the rest of the industry for their “ongoing support”.

Some hard pressed techies dealing with the fallout are not yet convinced of Intel’s latest microcode update, at least ones that expressed doubts on Reddit.

“Don’t patch yet,” was the advice from one, “MS had to revert one of Intel's fixes already. Best to wait until it's verified not to cause issues with the OS."

Another said, “I would imagine… at least hope, that the second time around they’d make sure they get it right. But probably still a good call.”

A third said he was “cautiously optimistic” as it will still be “up to the motherboard manufacturers to provide BIOS updates”.

And therein lies the problem, pessimists are rarely disappointed, but for optimists… it is the hope that gets them in the end. El Reg suspects Linux supremo Linus Torvalds, based on experience, fits into the former bracket where Intel is concerned. ®

* Sorry, Sean Lock, couldn't resist pinching your joke.

Updated
Intel told us it has not yet ascertained the performance impact the latest patch update may cause. "We do expect to provide more information on this in the future," a spokesman told us."


Intel with 35 Lawsuits is still ahead of AMD with only 4:

Guess who else Spectre is haunting? Yes, it's AMD. Four class-action CPU flaw lawsuits filed
Punters not happy with handling of vulnerability confessions
By Shaun Nichols in San Francisco 21 Feb 2018 at 22:43
https://www.theregister.co.uk/2018/02/21/amd_spectre_lawsuits/

"It's not just Intel facing a legal firestorm over its handling of the Spectre and Meltdown CPU design flaws – AMD is also staring at a growing stack of class-action complaints related to the chip vulnerabilities.

Spoiler

At least four separate lawsuits have now been filed against the California-based processor slinger, alleging violations ranging from securities fraud to breach of warranty, unfair competition, and negligence. The cases, all submitted to a US district court in San Jose, include:

• Nathan Barnes and Jonathan Caskey vs AMD, Case 5:18-cv-00883-BLF
• Brian Speck vs AMD, Case 5:18-cv-00744-HRL
• Diana Hauck vs AMD, Case 5:18-cv-00447-NC
• Doyun Kim vs AMD, Case 5:18-cv-00321-EJD

The first three suits, which could be merged into each other at some point, seek damages from AMD on behalf of those who bought an AMD processor blighted by the Spectre design vulnerability prior to the flaw's public disclosure by researchers in January of this year.

While Meltdown primarily affects Intel chips, AMD's CPUs – like many modern processor architectures including Intel's – suffer from Spectre-class bugs. The trio of suits cite El Reg's exclusive reporting on the semiconductor security cockups.

The lawsuits note that AMD knew of these side-channel attack vulnerabilities before the public disclosure and yet didn't issue any mitigations, nor warn users of the risks even as they pushed their products to market.

"Despite its knowledge of the Spectre Defect, AMD continued to sell its processors to unknowing customers at prices much higher than what customers would have paid had they known about the Spectre Defect and its threat to critical security features as well as on the processing speeds of the devices they purchased," read the Barnes complaint.

Additionally, the cases note that because Spectre is rooted so deeply into the CPU architecture, a permanent fix will be difficult to roll out and will likely cause a drop in performance.

"Defendant has been unable or unwilling to repair the security vulnerabilities in the subject CPUs or offer Plaintiff and class members a non-defective CPU or reimbursement for the cost of such CPU and the consequential damages arising from the purchase and use of such CPUs," reads the Speck complaint.

"The software updates or 'patches' pushed by AMD onto CPU owners does not appear to provide protection from all the variants of Spectre. At the very least, firmware updates or changes will be required. Even then, these 'patches' dramatically degrade CPU performance."

The Speck, Barnes, and Hauck complaints levy charges against AMD including breach of implied warranty, breach of express warranty, violation of the Magnusson-Moss Warranty Act, negligence, strict liability, unjust enrichment, and violations of unfair competition and consumer protection laws in California and Ohio.

Meanwhile, the Kim complaint, as we reported last month, looks to recover cash on behalf of shareholders who bought AMD stock between between February 21, 2017 and January 11, 2018. The suit alleges that AMD mislead investors and violated securities laws when it failed to disclose the bugs and, after the flaws were disclosed, downplayed their severity.

As a result, the suit alleges, shareholders took a financial hit when the vulnerabilities were confirmed in AMD chips and its stock price fell 0.99 per cent on January 12, 2018.

"AMD and the Individual Defendants, individually and in concert, directly or indirectly, disseminated or approved the false statements… which they knew or deliberately disregarded were misleading in that they contained misrepresentations and failed to disclose material facts," the complaint reads.

All four complaints seek a jury trial to determine damages. A spokesperson for AMD could not be reached for immediate comment."

 

Hmmm I wonder if the iGPU drivers Intel released for Meltdown/Spectre will reduce CPU performance...

 

Yeah, so that would be a thing for Optimus enabled notebooks as well as notebooks without a dedicated GPU. Are you gonna test it?

 

GPU architectures aren't affected by Spectre.

 

iGPU=Intel

 

Yes, iGPU are Intel ofc, they remain unaffected for short while until someone finds hidden exploit in nvidia compiler/driver architecture that can send or receive user data silently w/o any alerts aka stealth mode.

 

Intel didn't tell CERTS, govs, about Meltdown and Spectre because they couldn't help fix it
Letters to Congress detail the plan to keep CPU flaws secret
By Simon Sharwood, APAC Editor 23 Feb 2018 at 08:30
https://www.theregister.co.uk/2018/02/23/meltdown_spectre_letters_to_congress/

"Letters sent to the United States Congress by Intel and the other six companies in the Meltdown/Spectre disclosure cabal have revealed how and why they didn't inform the wider world about the dangerous chip design flaws.

Republican members of the House Energy and Commerce Committee sent letters to the seven in January, to seek answers about the reasons they chose not to disclose the flaws and whether they felt their actions were responsible and safe.

All the letters go over old ground: Google Project Zero spotted the design errors, told Intel, which formed a cabal comprising itself, Google, AMD, Arm, Apple, Amazon and Microsoft. The gang of seven decided that Project Zero's 90-day disclosure deadline had to be extended to January, then spoke to others to help them prepare fixes. But stray posts and sharp-eyed Reg hacks foiled that plan as we broke the news on January 3rd.

The flaws are so serious that Congressman insisted the seven explain themselves, and now we have the letters in which they attempt to do so, with links on this page .

Spoiler

Intel's letter (PDF) is the most informative because it reveals "Before the leak, Intel disclosed information about Spectre and Meltdown only to companies who could assist Intel in enhancing the security of technology users."

That meant the cabal felt none of the US government, the United States Computer Emergency Readiness Team or the Computer Emergency Readiness Team Coordination Center would be useful in preparing a response to the mess it made. Once news of the flaws broke, Intel "expedited its plans to deploy the mitigations and promptly briefed governments and others about the issues."

Intel explained that it devised this response after considering the "CERT Guide to Coordinated Vulnerability Disclosure", the "Common Vulnerabilities and Exposures (CVE) Numbering Authority Rules" the "Forum of Incident Response Security Teams Common Vulnerability Scoring System".

The letter also states that "Later this year, Intel will introduce new hardware design changes in our products to address vulnerabilities such as Spectre and Meltdown."

Microsoft's dilemma
The other letters mostly point out that Spectre and Meltdown are Intel's problems, so while the cabal members answer the questions they defer to Chipzilla's actions. But there are still a few fun factoids.

Microsoft's, for example, revealed that it knew its fixes would break some anti-virus software and tried to warn vendors of such products in advance, but couldn't tell them why it was making changes for fear of leaking news of Meltdown and Spectre.

Arm's response almost feels like it was chuffed to be asked to play with the big boys. "Before Spectre and Meltdown, Arm had not been involved in multiparty coordinated vulnerability disclosure." Its letter says the company's senior managers and Board were made aware of the issue, and the fix was made a "major priority".

Amazon said it "focussed our efforts on developing countermeasures for the Linux operating system and the Xen hypervisor".

There's no sign of responses from the Congressmen who sent the letters. If that changes, so will this story. Or we'll write another.

Intel did not tell U.S. cyber officials about chip flaws until made public
FEBRUARY 22, 2018 / 12:22 PM
https://www.reuters.com/article/us-...ip-flaws-until-made-public-idUSKCN1G62PS?il=0

"Intel Corp did not inform U.S. cyber security officials of the so-called Meltdown and Spectre chip security flaws until they leaked to the public, six months after Alphabet Inc notified the chipmaker of the problems, according to letters sent by tech companies to lawmakers on Thursday.

Current and former U.S. government officials have raised concerns that the government was not informed of the flaws before they became public because the flaws potentially held national security implications. Intel said it did not think the flaws needed to be shared with U.S. authorities as hackers had not exploited the vulnerabilities.

Intel did not tell the United States Computer Emergency Readiness Team, better known as US-CERT, about Meltdown and Spectre until Jan. 3, after reports on them in online technology site The Register had begun to circulate.

Spoiler

US-CERT, which issues warnings about cyber security problems to the public and private sector, did not respond to a request for comment.

Details of when the chip flaws were disclosed were detailed in letters sent by Intel, Alphabet and Apple Inc on Thursday in response to questions from Representative Greg Walden, an Oregon Republican who chairs the House Energy and Commerce Committee. The letters were seen by Reuters.

Alphabet said that security researchers at its Google Project Zero informed chipmakers Intel, Advanced Micro Devices Inc and SoftBank Group Corp-owned ARM Holdings of the problems in June.

It gave the chipmakers 90 days to fix the issues before public disclosing them, standard practice in the cyber security industry intended to give the targets of bugs time to fix them before hackers can take advantage of the flaws.

Alphabet said it left the decision of whether to inform government officials of the security flaws up to the chipmakers, which is its standard practice.

Intel said it did not inform government officials because there was “no indication that any of these vulnerabilities had been exploited by malicious actors,” according to its letter.

Intel also said it did not perform an analysis of whether the flaws might harm critical infrastructure because it did not think it could affect industrial control systems. But Intel said that it did inform other technology companies that use its chips of the issue, according to its letter.

Intel, Alphabet and Apple could not immediately be reached for comment.

AMD, ARM, Microsoft Corp and Amazon.com Inc also responded to questions from lawmakers.

Microsoft said that it did inform several antivirus software makers about the flaws “several weeks” ahead of their public disclosure to give them time to avoid compatibility issues. AMD said that Alphabet extended the disclosure deadline from the standard 90 days twice, first to Jan. 3, then to Jan. 9."

 

OpenBSD releases Meltdown patch
And now to see if it's an unwelcome imposition or a mere inconvenience
By Richard Chirgwin 23 Feb 2018 at 05:30
https://www.theregister.co.uk/2018/02/23/openbsd_emits_meltdown_patch/

"OpenBSD's Meltdown patch has landed, in the form of a Version 11 code update that separates user memory pages from the kernel's – pretty much the same approach as was taken in the Linux kernel.

A few days after the Meltdown/Spectre bugs emerged in January, OpenBSD's Phillip Guenther responded to user concerns with a post saying the operating system's developers were working out what to do.

Now he's revealed the approach used to fix the free OS: “When a syscall, trap, or interrupt takes a CPU from userspace to kernel the trampoline code switches page tables, switches stacks to the thread's real kernel stack, then copies over the necessary bits from the trampoline stack. On return to userspace the opposite occurs: recreate the iretq frame on the trampoline stack, switch stack, switch page tables, and return to userspace.”

That explanation is somewhat obscure to non-developers, but there's a more readable discussion of what the project's developers had in mind from January, here.

Spoiler

Part of the OpenBSD solution used the approach employed by Matthew Dillon in his DragonFly BSD – the per-CPU page layout aspect.

It'll take testing for OpenBSD users to confirm the performance impact of the fix.

Gunther's commit note says the aim was to implement the fix “with only the minimum of kernel code and data required for the transitions to/from the kernel (still marked as supervisor-only, of course)”.

That's still challenging: earlier this month, Netflix (and dTrace) engineer Brendan Gregg ran tests on patched Linux, and found slowdowns between 0.1 per cent (bearable) and 6 per cent (important in big systems).

However, Gregg reckoned that skilled sysadmins would be able to tune their systems to cope; the same, we hope, will be true for OpenBSD."

Mitigating the Performance Impact of Meltdown / Spectre Kernel Patches
The performance issues introduced by the vulnerability mitigations can cripple developer machines performance
Attila Orosz, FEB 23, 2018
http://wayoflinux.com/blog/meltdown-spectre-performance

"Meltdown and Spectre took the world (but not the industry) by surprise after the carefully guarded information leaked into the public consciousness. While the revelation was not intentional (from the industry's side anyway), the lack of action was. Of course patches had to be issued in a hurry after the world learned about just how serious the vulnerabilities are, and given the short timeframe, the first patches are just, well, patchy...

A lot has been said and written about the performance penalty resulting from these patches. After all, the offending CPU "features" were meant to enhance performance, so disabling them were expected to have an impact. While most of the reporting was basically hype, and apparently served no other purpose than distract the public's attention from some far more serious implications, some have really felt the patches coming back to bite them on the rear-parts.

Particularly those working with software development tools feel a performance decrease, as compile and build times can greatly increase with the patched kernels. Managed languages such as Java might perform even worse, so if you are working with something like Java and/or doing Android development, you might have noticed your IDE locking up, freezing or just generally underperforming.

Of course the currently available patches are the first responses to the problem, cobbled together in record time. The primary focus was mitigation, performance issues are so far seen as a side effect. Once the dust settles, we can hopefully expect better, more efficient solutions to replace the current ones, and while no software solution can counterbalance the spectacularly stupid hardware design decisions that introduced the problems in the first place, there is still hope that eventually, we end up with something workable.

Until such time, however, developers can simply re-enable their machines, by turning off the patches.

Spoiler

BEFORE YOU PROCEED: MAKE SURE YOU UNDERSTAND THE RISKS
This Ubuntu Insights article discusses the issue in some detail, with additional resources provided for further reading. Despite its use of the same PR-esque language as your average hype-aggregator would (calling the vulnerabilities "attacks", as opposed to what they really are: vulnerabilities caused by deliberately idiotic, faulty hardware design), it's worth reading.

One important conclusion of said article is that average Desktop users will experience negligible slowdowns resulting from the patches, so minimal that most would probably not even notice if their attention had not been hijacked by overhyped reporting on how bad it will all get fo us.

If you do have real-time issues, e.g. the very noticeable performance decrease, and frequent freezes of Android Studio, IntelliJ or Eclipse (and other) IDEs, and the two-three times longer build times on larger projects, etc., you still want to do everything you can to lower the risks of going "patchless".

Physically securing the machines, using strong passwords, locking properly when leaving your workstation, using the latest browsers (as the most common attack surface might be your browsers JS engine), are absolutely necessary pre-requisites of going "patchless".

You should read everything you can on the vulnerabilities, and the risks associated with disabling the patches. This article is only meant to provide a quick way to do this, but the responsibility is ultimately your own.

DISABLE THE OFFENDING PATCHES
Once again, if you came here because you've read an article about the performance impact of the patches and now you fear for your life because Facebook might load slower, or you're looking to enhance PC performance because some stupid game might run faster, stop reading now, uninstall your browser, turn off the PC, tear out the hard-drive, and declare yourself unfit to operate computing equipment.

This cannot be repeated often enough: The meltdown/spectre patches are vital to keeping your PC and data safe, and disabling them will expose your computer to these vulnerabilities. Follow the below advice at your own risk. Any damage, loss of data, or any other negative outcome is your own responsibility. You have been warned.

If your concerns are genuine, however, such as your work is impacted by serious penalties on build/compilation time, IDE performance, etc. your solution is fortunately quite simple.

The current, or perhaps some future patches will eventually become part of the kernel, so you might want to HODL your current kernel after doing this, like it was some fancy new crypto, until everything properly settles or you can buy a less affected CPU.

FOUR COLOURFUL NOTICES LATER, THE SOLUTION
The current patches can be disabled with simple kernel command line parameters. (Yay!) This RedHat KB articleexplains the three main performance hogs and how they can be disabled, while this Ubuntu wiki article lists all relevant tunables, so that you can cherry-pick what is loaded, depending on your situation/evaluation.

The three most common performance "offenders", as per the above RH article are:

• Page Table Isolation (pti) — Use the parameter nopti or pti=off to disable it
• Indirect Branch Restricted Speculation (ibrs) — Use the parameter noibrs to disable it
• Indirect Branch Prediction Barriers (ibpb) — Use the parameter noibpb to disable it

The simplest way to do this (for GRUB/2) is to edit /etc/default/grub with your favourite editor, something like:

sudo micro /etc/default/grub
(You can, of course, use nano, vi(m), and even emacs, if you feel masochistic, or whatever you fancy, this is just a text file)

...then change the line where it says GRUB_CMDLINE_LINUX_DEFAULT from something like:

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"
(It might not look exactly like that, but you being a developer n'all should already know this)

...to something like:

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash nopti noibrs noibpb"
(Of course you want to keep the original parameters, because why wouldn't you wanna keep them.)

...then update grub with:

sudo update grub
or

sudo update-grub2
depending on your setup.

If you're not loading with GRUB/2, you can find the most detailed guide to kernel parameters known to man on the Arch Linux Wiki, right here, with generic kernel boot-parameter instructions for just about any possible scenario.

And that's it. Reboot, and your PC should have its old performance once again. Now get back to work, but only afer you've shared this article on your favourite social media platform.

Happy coding.

 

Intel, AMD, Google Respond To US Government Meltdown/Spectre Inquiry-Tomshardware.com
"Clearly, Intel continues to be the center of attention in the ongoing Meltdown/Spectre issue. Why it chose not to disclose with the U.S. government is up for question. Perhaps it was because the company thought it was useless to do so without having a fix in place. It’s easy to place blame on Intel, but let’s not forget that AMD and Arm CPUs are both partially involved in this incident too, and neither of them chose to disclose the vulnerabilities either."

 

90% of CPU market is dominated by Intel, so its natural for them to center of attraction and everybody got their data handed over to Intel Chips when you're running an Intel based PC.

 

Also people who use QuickSync for video encoding need Intel iGPU drivers.

Anyway, after the driver update, my scores in wPrime 32M and TS Bench 32M are consistently about 50ms faster. Although that could be margin of error or due to the reboot.

 

Intel's microcode revision guidance (February 24 2018)

 

Cool, what's new on that, my first impression is that Broadwell is in Production status, and Sandybridge is in Beta (but haven't compared to previous document to know for sure)? For old platforms like Sandybridge, I'd be surprised if laptop/desktop vendors release BIOS fixes for these. I wonder if the updated microcodes will be released to the general public in this form ( https://downloadcenter.intel.com/download/27337/Linux-Processor-Microcode-Data-File), if so then I'd probably try patching my old Sandybridge system using the following method ( http://forum.notebookreview.com/threads/how-to-update-microcode-from-windows.787152/), I'm not sure if that would be able to fix the Spectre vulnerability when patched in that way, but I'd try it anyway.

 

They must have all the updated Microcodes finished before they can post it there for download.

 

Yes, that makes sense, because that microcode file contains the microcodes for all of the Intel CPUs.

 

Intel has updated the Microcode status again today, February 26, but I wouldn't get excited, as vendors need to integrate microcode changes in to a BIOS update for your specific motherboard.

And, given Intel's track record so far I wouldn't install BIOS updates until it's been out for a few weeks, to see if it gets pulled again.

Here is Intel's current Microcode status PDF, which appears like it is getting updated daily as a Live document, here is the active link:

Microcode Revision Guidance
The following table provides details of availability for microcode updates currently planned by Intel. Changes since the previous version are highlighted in yellow.
https://newsroom.intel.com/wp-content/uploads/sites/11/2018/02/microcode-update-guidance.pdf

Here is an upload of today's Microcode Revision Guidance: February 26 2018:

 

Another Potential Performance Optimization For KPTI Meltdown Mitigation
Written by Michael Larabel in Linux Kernel on 23 February 2018 at 03:41 AM EST. 4 Comments
https://www.phoronix.com/scan.php?page=news_item&px=KPTI-Global-Pages

"Now that the dust is beginning to settle around the Meltdown and Spectre mitigation techniques on the major operating systems, in the weeks and months ahead we are likely to see more performance optimizations come to help offset the performance penalties incurred by mitigations like kernel page table isolation (KPTI) and Retpolines. This week a new patch series was published that may help with KPTI performance.

Intel developer Dave Hansen discovered that the back when KPTI was known as KAISER allowed the user/kernel shared areas to be marked global that would reduce the TLB overhead. But with all the code churn and it transitioning to page table isolation, that code got dropped.

Hansen posted a set of 10 patches on Thursday for bringing back global pages for shared areas with the x86/pti code. With this the code avoids unnecessary TLB misses.

No performance reports were provided but will be interesting to see what impact if anything measurable it will have on real-world workloads that were affected by KPTI. The patches can be found on the kernel mailing list and will be tested in our next Spectre/Meltdown benchmarking roundup."