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

eva2000 · May 26, 2018

Latest state of my OVH MC-32 Core i7 4790K kernel level spectre/meltdown fixes

kernel

Code (Text):

uname -r
3.10.0-862.2.3.el7.x86_64

check boot log on CentOS 7

Code (Text):

journalctl -b | egrep -C1 -i 'spectre|meltdown|cve' | sed -e "s|$(hostname -f)|hostname|g"
May 22 08:11:33 hostname kernel: FEATURE IBPB_SUPPORT Not Present
May 22 08:11:33 hostname kernel: Spectre V2 : Vulnerable: Retpoline without IBPB
May 22 08:11:33 hostname kernel: Freeing SMP alternatives: 24k freed
--
May 25 14:12:44 hostname DISCLAIMER[28517]: This updated microcode supersedes microcode provided by Red Hat with
May 25 14:12:44 hostname DISCLAIMER[28517]: the CVE-2017-5715 (“Spectre”) CPU branch injection vulnerability
May 25 14:12:44 hostname DISCLAIMER[28517]: mitigation.
May 25 14:12:44 hostname kernel: Spectre V2 : Mitigation: Full retpoline
May 25 14:12:44 hostname DISCLAIMER[28517]: Historically, Red Hat has provided updated microcode, developed by our
--
May 25 14:12:44 hostname unknown: This updated microcode supersedes microcode provided by Red Hat with
                                     the CVE-2017-5715 (“Spectre”) CPU branch injection vulnerability
                                     mitigation.

CentOS microcode_ctl package change log

Code (Text):

rpm -q --changelog microcode_ctl | head -n12
* Tue May 15 2018 Petr Oros <poros@redhat.com> - 2.1-29.2
- Update disclaimer text
- Resolves: #1575570

* Mon May 07 2018 Petr Oros <poros@redhat.com> - 2.1-29.1
- Intel CPU microcode update to 20180425.
- Resolves: #1575570

* Fri Jan 12 2018 Petr Oros <poros@redhat.com> - 2.1-29
- Revert Microcode from Intel for Side Channel attack
- Resolves: #1533939

check logging for microcode related entries

Code (Text):

journalctl -b --no-pager | grep microcode | sed -e "s|$(hostname)|hostname|g"
May 22 08:11:33 hostname kernel: microcode: microcode updated early to revision 0x22, date = 2017-01-27
May 22 08:11:33 hostname kernel: microcode: CPU0 sig=0x306c3, pf=0x2, revision=0x22
May 22 08:11:33 hostname kernel: microcode: CPU1 sig=0x306c3, pf=0x2, revision=0x22
May 22 08:11:33 hostname kernel: microcode: CPU2 sig=0x306c3, pf=0x2, revision=0x22
May 22 08:11:33 hostname kernel: microcode: CPU3 sig=0x306c3, pf=0x2, revision=0x22
May 22 08:11:33 hostname kernel: microcode: CPU4 sig=0x306c3, pf=0x2, revision=0x22
May 22 08:11:33 hostname kernel: microcode: CPU5 sig=0x306c3, pf=0x2, revision=0x22
May 22 08:11:33 hostname kernel: microcode: CPU6 sig=0x306c3, pf=0x2, revision=0x22
May 22 08:11:33 hostname kernel: microcode: CPU7 sig=0x306c3, pf=0x2, revision=0x22
May 22 08:11:33 hostname kernel: microcode: Microcode Update Driver: v2.01 <tigran@aivazian.fsnet.co.uk>, Peter Oruba
May 22 08:11:35 hostname systemd[1]: Starting Load CPU microcode update...
May 22 08:11:35 hostname systemd[1]: Started Load CPU microcode update.
May 22 08:12:19 hostname dracut[3492]: *** Generating early-microcode cpio image contents ***
May 22 08:12:19 hostname dracut[3492]: *** Creating microcode section ***
May 22 08:12:19 hostname dracut[3492]: *** Created microcode section ***
May 22 08:12:20 hostname dracut[3492]: drwxr-xr-x   2 root     root            0 May 22 08:12 kernel/x86/microcode
May 22 08:12:20 hostname dracut[3492]: -rw-r--r--   1 root     root        22528 May 22 08:12 kernel/x86/microcode/GenuineIntel.bin
May 25 14:12:44 hostname kernel: microcode: CPU0 sig=0x306c3, pf=0x2, revision=0x22
May 25 14:12:44 hostname kernel: microcode: CPU0 updated to revision 0x24, date = 2018-01-21
May 25 14:12:44 hostname kernel: microcode: CPU1 sig=0x306c3, pf=0x2, revision=0x22
May 25 14:12:44 hostname kernel: microcode: CPU1 updated to revision 0x24, date = 2018-01-21
May 25 14:12:44 hostname kernel: microcode: CPU2 sig=0x306c3, pf=0x2, revision=0x22
May 25 14:12:44 hostname kernel: microcode: CPU2 updated to revision 0x24, date = 2018-01-21
May 25 14:12:44 hostname kernel: microcode: CPU3 sig=0x306c3, pf=0x2, revision=0x22
May 25 14:12:44 hostname kernel: microcode: CPU3 updated to revision 0x24, date = 2018-01-21
May 25 14:12:44 hostname kernel: microcode: CPU4 sig=0x306c3, pf=0x2, revision=0x22
May 25 14:12:44 hostname kernel: microcode: CPU4 updated to revision 0x24, date = 2018-01-21
May 25 14:12:44 hostname kernel: microcode: CPU5 sig=0x306c3, pf=0x2, revision=0x22
May 25 14:12:44 hostname kernel: microcode: CPU5 updated to revision 0x24, date = 2018-01-21
May 25 14:12:44 hostname kernel: microcode: CPU6 sig=0x306c3, pf=0x2, revision=0x22
May 25 14:12:44 hostname kernel: microcode: CPU6 updated to revision 0x24, date = 2018-01-21
May 25 14:12:44 hostname kernel: microcode: CPU7 sig=0x306c3, pf=0x2, revision=0x22
May 25 14:12:44 hostname kernel: microcode: CPU7 updated to revision 0x24, date = 2018-01-21
May 25 14:12:44 hostname DISCLAIMER[28517]: This updated microcode supersedes microcode provided by Red Hat with
May 25 14:12:44 hostname DISCLAIMER[28517]: Historically, Red Hat has provided updated microcode, developed by our
May 25 14:12:44 hostname DISCLAIMER[28517]: temporarily suspended this practice while microcode stabilized. Red
May 25 14:12:44 hostname DISCLAIMER[28517]: Hat is once again providing an updated Intel microcode package
May 25 14:12:44 hostname DISCLAIMER[28517]: (microcode_ctl) and AMD microcode package (linux-firmware) to customers
May 25 14:12:44 hostname DISCLAIMER[28517]: continue to update these microcode packages as necessary. Please
May 25 14:12:44 hostname DISCLAIMER[28517]: Intel and AMD microcode package versions.
May 25 14:12:44 hostname yum[28281]: Updated: 2:microcode_ctl-2.1-29.2.el7_5.x86_64
May 25 14:12:44 hostname unknown: This updated microcode supersedes microcode provided by Red Hat with
                                     Historically, Red Hat has provided updated microcode, developed by our
                                     temporarily suspended this practice while microcode stabilized. Red
                                     Hat is once again providing an updated Intel microcode package
                                     (microcode_ctl) and AMD microcode package (linux-firmware) to customers
                                     continue to update these microcode packages as necessary. Please
                                     Intel and AMD microcode package versions.
May 25 14:13:05 hostname dracut[8202]: *** Generating early-microcode cpio image contents ***
May 25 14:13:05 hostname dracut[8202]: *** Creating microcode section ***
May 25 14:13:05 hostname dracut[8202]: *** Created microcode section ***
May 25 14:13:06 hostname dracut[8202]: drwxr-xr-x   2 root     root            0 May 25 14:13 kernel/x86/microcode
May 25 14:13:06 hostname dracut[8202]: -rw-r--r--   1 root     root        23552 May 25 14:13 kernel/x86/microcode/GenuineIntel.bin
May 25 14:13:17 hostname dracut[18352]: *** Generating early-microcode cpio image contents ***
May 25 14:13:17 hostname dracut[18352]: *** Creating microcode section ***
May 25 14:13:17 hostname dracut[18352]: *** Created microcode section ***
May 25 14:13:18 hostname dracut[18352]: drwxr-xr-x   2 root     root            0 May 25 14:13 kernel/x86/microcode
May 25 14:13:18 hostname dracut[18352]: -rw-r--r--   1 root     root        23552 May 25 14:13 kernel/x86/microcode/GenuineIntel.bin

Check Redhat/CentOS tunables explained here = 1 1 0

Code (Text):

cat /sys/kernel/debug/x86/pti_enabled
1

cat /sys/kernel/debug/x86/ibpb_enabled
1

cat /sys/kernel/debug/x86/ibrs_enabled
0

cat /sys/kernel/debug/x86/retp_enabled 
1

So

pti_enabled - Page Table Isolation is enabled
ibpb_enabled - Indirect Branch Predication Barriers is enabled
ibrs_enabled - Indirect Branch Restricted Speculation is disabled
retp_enabled - "retp_enabled" alteration is only available at runtime for RHEL7 systems. This tunable is read-only for RHEL 6 systems

ibrs_enabled

When ibrs_enabled is set to 1 (spectre_v2=ibrs) the kernel runs with indirect branch restricted speculation, which protects the kernel space from attacks (even from hyperthreading/simultaneous multi-threading attacks). When IBRS is set to 2 (spectre_v2=ibrs_always), both userland and kernel runs with indirect branch restricted speculation. This protects userspace from hyperthreading/simultaneous multi-threading attacks as well, and is also the default on certain old AMD processors (family 10h, 12h and 16h). This feature addresses CVE-2017-5715, variant #2.

When ibrs_enabled is set to 3, only userland runs with indirect branch restricted speculation. This can be used in combination with retpoline (spectre_v2=retpoline,ibrs_user) to provide similar security to ibrs_always with less performance overhead.
Click to expand...

So since Core i7 4790K is Haswell based processor, Kernel level Retpolines are used to mitigate Spectre variant 2 instead of ibrs_enabled.

eva2000 · May 31, 2018

more Spectre fixes land in Google Chrome 67 Google Patches 34 Browser Bugs in Chrome 67, Adds Spectre Fixes

Most notably to the browser update are mitigations for Spectre. The fix includes an added feature called Site Isolation that essentially separates the processes between different tabs – so that if one tab crashes, the others will continue to work. This also protects against speculative side-channel CPU vulnerabilities like Spectre because it reduces the amount of data exposed to side channel attacks.
Click to expand...

Good to know, I already enabled Site Isolation using Chrome flags prior to Chrome 67 but good to know it's default now.

eva2000 · Jul 1, 2018

hmmm not all patched yet Rowhammer returns, Spectre fix unfixed, Wireguard makes a new friend, and much more

Spectre patches may need a patch
When is a fix not a fix? When it's an attempt patch up the Spectre vulnerability, apparently.

Researchers Noam Hadad and Jonathan Afek of Aleph Security said this week that they had devised a way to work around some of the measures browser vendors have used to mitigate the vulnerability.

It turns out the data-timing tricks browsers use to help prevent exploits can be overcome, provided the attackers don't mind a little performance hit.

"In our research we were able to overcome the cache access timing specific mitigations. Although these mitigations cause a serious slowdown in our POC, they are not effective in preventing this attack," the duo write.

"These mitigations also have some negative performance implications and are hurting the functionality of some legitimate JavaScript web application use-cases."
Click to expand...

eva2000 · Jul 20, 2018

Intel cpus, the gift that keeps giving New "Spectre" Variant Hits Intel CPUs, Company Promises Quarterly Microcode Updates !

A new variant of the "Spectre" CPU vulnerability was discovered affecting Intel processors, by security researchers Vladimir Kiriansky and Carl Waldspurger, who are eligible to bag a USD $100,000 bounty by Intel, inviting researchers to sniff out vulnerabilities from its processors. This discovery, chronicled under CVE-2018-3693, is among 12 new CVEs Intel will publish later this week. The company is also expected to announce quarterly CPU microcode updates to allay fears of its enterprise customers.

The new vulnerability, like most other "Spectre" variants, targets the speculative execution engine of the processor, in a bounds-check bypass store attack. A malicious program already running on the affected machine can alter function pointers and return addresses in the speculative execution engine, thereby redirecting the flow of data out of protected memory address-spaces, making it visible to malware. This data could be anything, including cryptographic keys, passwords, and other sensitive information, according to "The Register." Intel chronicled this vulnerability in section 2.2.1 of its revised speculative execution side-channel attacks whitepaper. You can also catch a more detailed whitepaper from the researchers themselves.
Click to expand...

eva2000 · Aug 15, 2018

More security vulnerabilities for Intel

INTEL-SA-00161

L1 Terminal Fault - The Latest Speculative Execution Side Channel Attack - Phoronix

While Meltdown breaks the user space to kernel space protection, L1TF allows to attack any physical memory address in the system and the attack works across all protection domains. It allows an attack of SGX and also works from inside virtual machines because the speculation bypasses the extended page table (EPT) protection mechanism.

Ouch, it's going to be a hot mess in the public cloud/virtualization space. Any exposure by bare-metal users appears minimal to unaffected. The initial Linux kernel mitigations:
Click to expand...

Indeed a hot mess.. if there's any reason to force me off Cloud VPS onto bare metal dedicated hosting, this would probably be it.

Summary:

Security researchers have identified a speculative execution side-channel method called L1 Terminal Fault (L1TF). This method impacts select microprocessor products supporting Intel® Software Guard Extensions (Intel® SGX). Further investigation by Intel has identified two related applications of L1TF with the potential to impact additional microprocessors, operating systems, system management mode, and virtualization software. If used for malicious purposes, this class of vulnerability has the potential to improperly infer data values from multiple types of computing devices.

Intel is committed to product and customer security and to coordinated disclosure. We worked closely with other technology companies, operating system, and hypervisor software vendors, developing an industry-wide approach to mitigate these issues promptly and constructively.
For facts about these new exploits, technical resources, and steps you can take to help protect systems and information please visit: Side Channel Methods – Analysis, News and Updates.

Description:

CVE-2018-3615 - L1 Terminal Fault: SGX

Systems with microprocessors utilizing speculative execution and Intel® software guard extensions (Intel® SGX) may allow unauthorized disclosure of information residing in the L1 data cache from an enclave to an attacker with local user access via a side-channel analysis.

7.9 High CVSS:3.0/AV:L/AC:L/PR:N/UI:N/S:C/C:H/I:L/A:N

CVE-2018-3620 - L1 Terminal Fault: OS/SMM

Systems with microprocessors utilizing speculative execution and address translations may allow unauthorized disclosure of information residing in the L1 data cache to an attacker with local user access via a terminal page fault and a side-channel analysis.

7.1 High CVSS:3.0/AV:L/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N

CVE-2018-3646 - L1 Terminal Fault: VMM

Systems with microprocessors utilizing speculative execution and address translations may allow unauthorized disclosure of information residing in the L1 data cache to an attacker with local user access with guest OS privilege via a terminal page fault and a side-channel analysis.

7.1 High CVSS:3.0/AV:L/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N

Affected products:

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

Intel® Core™ i3 processor (45nm and 32nm)
Intel® Core™ i5 processor (45nm and 32nm)
Intel® Core™ i7 processor (45nm and 32nm)
Intel® Core™ M processor family (45nm and 32nm)
2nd generation Intel® Core™ processors
3rd generation Intel® Core™ processors
4th generation Intel® Core™ processors
5th generation Intel® Core™ processors
6th generation Intel® Core™ processors **
7th generation Intel® Core™ processors **
8th generation Intel® Core™ processors **
Intel® Core™ X-series Processor Family for Intel® X99 platforms
Intel® Core™ X-series Processor Family for Intel® X299 platforms
Intel® Xeon® processor 3400 series
Intel® Xeon® processor 3600 series
Intel® Xeon® processor 5500 series
Intel® Xeon® processor 5600 series
Intel® Xeon® processor 6500 series
Intel® Xeon® processor 7500 series
Intel® Xeon® Processor E3 Family
Intel® Xeon® Processor E3 v2 Family
Intel® Xeon® Processor E3 v3 Family
Intel® Xeon® Processor E3 v4 Family
Intel® Xeon® Processor E3 v5 Family **
Intel® Xeon® Processor E3 v6 Family **
Intel® Xeon® Processor E5 Family
Intel® Xeon® Processor E5 v2 Family
Intel® Xeon® Processor E5 v3 Family
Intel® Xeon® Processor E5 v4 Family
Intel® Xeon® Processor E7 Family
Intel® Xeon® Processor E7 v2 Family
Intel® Xeon® Processor E7 v3 Family
Intel® Xeon® Processor E7 v4 Family
Intel® Xeon® Processor Scalable Family
Intel® Xeon® Processor D (1500, 2100)
** indicates Intel microprocessors affected by CVE-2018-3615 - L1 Terminal Fault: SGX

Please check with your system manufacturer for more information regarding updates for your system.

Recommendations:

Intel has worked with operating system vendors, equipment manufacturers, and other ecosystem partners to develop platform firmware and software updates that can help protect systems from these methods.

This includes the release of updated Intel microprocessor microcode to our customers and partners. This microcode was previously released as part of INTEL-SA-00115.

Status of available microcode can be found here.

End users and systems administrators should check with their system manufacturers and system software vendors and apply any available updates as soon as practical.
Click to expand...

Intel CPUs are affected but AMD CPUs, Intel Xeon Phi, and older Intel CPUs are among those not believed to be affected. Intel did post this video to YouTube when trying to dig up more on L1 Terminal Fault:
Click to expand...

eva2000 · Aug 22, 2018

More on Intel's next generation Cascade Lake and spectre/meltdown like protections at the cpu hardware level Intel at Hot Chips 2018: Showing the Ankle of Cascade Lake

eva2000 · Nov 15, 2018

Not over yet - 7 new meltdown and spectre vulnerabilities found Researchers discover seven new Meltdown and Spectre attacks | ZDNet !

A team of nine academics has revealed today seven new CPU attacks. The seven impact AMD, ARM, and Intel CPUs to various degrees.

Two of the seven new attacks are variations of the Meltdown attack, while the other five are variations on the original Spectre attack -- two well-known attacks that have been revealed at the start of the year and found to impact CPUs models going back to 1995.
Click to expand...

The new Meltdown attacks that the research team discovered are:

Meltdown-BR - exploits an x86 bound instruction on Intel and AMD

Meltdown-PK - bypasses memory protection keys on Intel CPUs

They also tried and failed to exploit other Meltdown attacks that targeted the following internal CPU operations:

Meltdown-AC - tried to exploit memory alignment check exceptions

Meltdown-DE - tried to exploit division (by zero) errors

Meltdown-SM - tried to exploit the supervisor mode access prevention (SMAP) mechanism

Meltdown-SS - tried to exploit out-of-limit segment accesses

Meltdown-UD - tried to exploit invalid opcode exception

Meltdown-XD - tried to exploit non-executable memory

Click to expand...

Based on the chart and table above, researchers found three new Spectre attacks that exploit the Pattern History Table mechanism and two new Spectre attacks against the Branch Target Buffer.

PHT-CA-OP

PHT-CA-IP

PHT-SA-OP

BTB-SA-IP

BTB-SA-OP

CPUs from AMD, ARM, and Intel are all affected by the five new Spectre attacks.
Click to expand...

VENDORS HAVE BEEN NOTIFIED
The research team says they reported all their findings to the three CPU vendors whose processors they've analyzed, but that only ARM and Intel acknowledged their findings.

In addition, the research team also discovered that some vendor mitigations that have been already deployed have also failed to stop the seven new attacks, even if they should have, at least in theory. They provide the following table with the results of their tests of existing mitigations.
Click to expand...

Revenge · Nov 16, 2018

GPUs are vulnerable to side-channel attacks
Researchers at UCLA Riverside discover GPUs can be victims of the same kinds of attacks as Meltdown and Spectre, which have impacted Intel and AMD CPUs.
Click to expand...

GPUs are vulnerable to side-channel attacks

eva2000 · Nov 16, 2018

wow now that's new !

3 types of GPU attacks
All three attacks require the victim to download a malicious program to spy on the victim’s computer.

The first attack tracks user activity on the web, since GPUs are used to render graphics in browsers. A malicious app uses OpenGL to create a spy program to infer the behavior of the browser as it uses the GPU. The spy program can reliably obtain all allocation events of each website visited to see what the user has been doing on the web and possibly extract login credentials.

In the second attack, the authors extracted user passwords because the GPU is used to render the login/password box. Monitoring the memory allocation events leaked allowed for keystroke logging.

The third attack is the one that hits the data center. It targets computational applications, using the same memory sniffing for grabbing passwords but this time on a neural network to learn the network’s structure. In short, malicious code could sniff out your neural network algorithms and steal them.

The researchers suggest turning off user mode access to the counters to defend against the third attack, but many existing applications depend on that functionality and would break, so it’s not a viable solution for many.

The researchers said they reported their findings to Nvidia, which said it intends to publish a patch that offers system administrators the option to disable access to performance counters from user-level processes. They also shared their findings with Intel and AMD, since they are also GPU makers.
Click to expand...

eva2000 · Dec 4, 2018

New Spectre attack, SplitSpectre Researchers discover SplitSpectre, a new Spectre-like CPU attack | ZDNet

For their academic paper, the research team says it successfully carried out a SplitSpectre attack against Intel Haswell and Skylake CPUs, and AMD Ryzen processors, via SpiderMonkey 52.7.4, Firefox's JavaScript engine.

Nonetheless, researchers said that existing Spectre mitigations would thwart the SplitSpectre attacks. This includes CPU microcode updates that CPU vendors have released over the past year, updates to popular code compilers to harden apps against Spectre-like attacks, and the browser-level modifications that browser vendors have shipped with post-January 2018 browser releases to make it infeasible to carry out web-based Spectre attacks.

However, if users have failed to install these updates, a SplitSpectre attack is theoretically possible.
Click to expand...

eva2000 · Dec 9, 2018

Good news Linux Networking Performance To Improve Thanks To Retpoline Overhead Reduction - Phoronix

One of the areas where Linux performance has been lower this year since Spectre came to light has been for networking performance, but with the upcoming Linux 4.21 cycle that will be partially addressed.

Linux networking performance took a hit from the introduction of Retpolines "Return Trampolines" at the start of the year for addressing Spectre Variant Two.

Developer Paolo Abeni has been working to offset the Retpoline overhead with a new patch series now destined for Linux 4.21. From the patch series, "We can partially address that when the function pointer refers to a builtin symbol resorting to a list of tests vs well-known builtin function and direct calls. Experimental results show that replacing a single indirect call via retpoline with several branches and a direct call gives performance gains even when multiple branches are added - 5 or more...This may lead to some uglification around the indirect calls...Overall this gives [greater than] 10% performance improvement for UDP GRO benchmark and smaller but measurable for TCP syn flood."

Linux networking subsystem maintainer David Miller has already expressed his plans to pull this into net-next, making it material for the Linux 4.21 cycle.
Click to expand...

eva2000 · Dec 21, 2018

Windows 10 also got a bunch of micro code updates today too https://support.microsoft.com/en-us...or-windows-10-version-1803-and-windows-server

Intel Microcode Updates around the following products (CPUs) have been revised. We recommend to take this latest update to stay current:

Broadwell Server E, EP, EP4S

Broadwell Server EX

Skylake Server SP (H0, M0, U0)

Skylake D (Bakerville)

Skylake X (Basin Falls)

Intel recently announced that they have completed their validations and started to release microcode for recent CPU platforms related to Spectre Variant 2 (CVE 2017-5715 [“Branch Target Injection”]). This update includes microcode updates from Intel for the following CPUs:
Click to expand...

eva2000 · Jan 1, 2019

OPTPOLINES - Formerly Relpolines, Lower Overhead To Retpolines For Spectre Mitigation - Phoronix

It's been nearly one year to the day since the Spectre and Meltdown vulnerabilities were made public. While the security vulnerabilities were quickly buttoned up in the Linux space, kernel developers continue working to offset the performance overhead introduced by these mitigations. They made a lot of overhead reductions in 2018 while still there are some patch-sets pending still for bettering the experience. One of these patch-sets was known as "Relpolines" but now has been updated and morphed into what is being called Optpolines.

Relpolines were announced a few months ago by a VMware developer as having lower overhead than Retpolines -- the return trampolines introduced as part of the Spectre mitigations back in January. The dynamic indirect call promotion work by VMware has been working on pairing relative calls and trampolines to reduce the overall Retpoline overhead. VMware found with their original patches it could deliver a 10% performance improvement to the Nginx web server, +4% for Redis, and other minor performance improvements -- well, recovering previously lost performance.
Click to expand...

eva2000 · Mar 6, 2019

Yup more goodies from Intel Intel CPUs Reportedly Vulnerable To New "SPOILER" Speculative Attack - Phoronix

Researchers out of the Worcester Polytechnic Institute and University of Lubeck discovered this new speculative attack dubbed SPOILER, Speculative Load Hazards Boost Rowhammer and Cache Attacks.

Intel was notified of this issue a few months ago but no software/hardware fix appears ready yet, while the researchers claim there might not be an effective software solution available at least anytime soon -- and any mitigation would likely come at a performance cost, as we've seen with Spectre and Meltdown over the past year. AMD and ARM CPUs aren't believed to be impacted by SPOILER.

In this work, we are the first to show that the dependency resolution logic that serves the speculative load can be ex-ploited to gain information about the physical page mappings. Microarchitectural side-channel attacks such as Rowhammer and cache attacks rely on the reverse engineering of the virtual-to-physical address mapping. We propose the SPOILER attack which exploits this leakage to speed up this reverse engineer-ing by a factor of 256. Then, we show how this can improve the Prime+Probe attack by a 4096 factor speed up of the eviction set search, even from sandboxed environments like JavaScript. Finally, we improve the Rowhammer attack by showing how SPOILER helps to conduct DRAM row conflicts deterministically with up to 100% chance, and by demonstrat-ing a double-sided Rowhammer attack with normal user’s privilege. The later is due to the possibility of detecting contiguous memory pages using the SPOILER leakage.
Click to expand...

The SPOILER research paper can be read here.

Update: An Intel spokesperson has provided us with the following statement:"Intel received notice of this research, and we expect that software can be protected against such issues by employing side channel safe software development practices. This includes avoiding control flows that are dependent on the data of interest. We likewise expect that DRAM modules mitigated against Rowhammer style attacks remain protected. Protecting our customers and their data continues to be a critical priority for us and we appreciate the efforts of the security community for their ongoing research."
Click to expand...

eva2000 · Mar 12, 2019

Latest benchmarks with spectre and meltdown patch fixes in place Spectre/Meltdown Performance Impact Across Eight Linux Distributions - Phoronix

With recent kernel releases we've also seen varying optimizations and other changes around the Spectre/Meltdown/L1TF mitigations. So for those wondering about the varying impact, here are some side-by-side benchmarks.

For those curious how the Spectre/Meltdown mitigation impact can vary between Linux distributions, on the same system I tested eight different Linux distributions while comparing the default mitigation costs to that of disabling all possible Spectre/Meltdown/L1TF mitigations that can be run-time disabled. The same up-to-date microcode of the BIOS/firmware was maintained the same with primarily going to the extents an end-user would if wanting to try to recover the performance costs involved with Spectre/Meltdown on each of the tested Linux distributions.

The Linux distributions tested were:

- CentOS 7
- Red Hat Enterprise Linux 8 Beta
- Fedora 29
- Manjaro 18.0.3
- openSUSE 15.0
- Ubuntu 18.04 LTS
- Ubuntu 18.10
- Clear Linux 28230

Each OS was tested "out of the box" except for when disabling the relevant Spectre/Meltdown mitigations. The same Intel Core i9 7960X system with MSI X299 SLI PLUS, 16GB RAM, 256GB Intel SSD, and Radeon RX 560 graphics was used for testing.
Click to expand...

eva2000 · Apr 6, 2019

More updates coming for improvements in Linux Kernel handling/controlling of meltdown/spectre patch fixes https://www.phoronix.com/scan.php?page=news_item&px=Linux-Improve-CPU-Spec-Switches

By the time the next Linux kernel is released it will have been roughly a year and a half since the Spectre and Meltdown CPU speculative execution vulnerabilities went public and the mitigations started appearing within the kernel. Finally now it's being discussed again by upstream developers over improving the switches / tunable knobs for easily configuring these performance-degrading mitigations.

It's been possible from the start to disable most of these mitigations at run-time (sans like __user pointer sanitization for Spectre V1) but the kernel command line parameters to use haven't been the most straight-forward or easy to remember... There hasn't been a global switch to kill Spectre/Meltdown mitigations in one easy-to-add option. At this stage to disable the mitigations on most patched Linux kernel releases it comes down to having to remember and add "pti=off spectre_v2=off l1tf=off nospec_store_bypass_disable." Similarly, if wanting to beef-up the security even more of the system with the "maximum mitigations" there are the "l1tf=full spec_store_bypass_disable=on spectre_v2_user=on" for better securing the system against these vulnerabilities but also hitting the performance even more severely due to HT/SMT being disabled among other measures.

Red Hat developer Josh Poimboeuf has reignited the upstream discussion over offering up some simpler command-line tunables for disabling these CPU speculation mitigations or driving up the protection, rather than having to remember all these multiple options. Poimboeuf's initial proposal came down to a cpu_spec_mitigations= kernel option with values of off/auto/nosmt.

There has been some resistance to the "cpu_spec_mitigations=" name itself as it's a bit long, but nothing conclusive has been decided for a shorter and better to remember string besides maybe just "spec_mitigations=" instead. The proposed patches cover just not x86_64 but also CPU spec vulnerabilities affecting ARM, s390, etc.

The work for now is still being discussed on the kernel mailing list and we'll see what comes of this work, stay tuned.
Click to expand...

eva2000 · May 15, 2019

Intel cpus keep on giving https://community.centminmod.com/th...-side-channel-vulnerability-zombieload.17496/

eva2000 · Feb 24, 2020

Looks like Meltdown and it's subsequent software or cpu hardware mitigations might not be totally fixed with new EchoLoad and KASLR - Kernel Address Space Layout Randomization and pdf linked in researcher's twitter post at https://twitter.com/cc0x1f/status/1230876597969969152 outlines it including proposed solution FLARE (Fake Load Address REsponse).
quoting from PDF

In this paper, we analyze the hardware-based Meltdown mitigations
in recent Intel microarchitectures, revealing that illegally accessed
data is only zeroed out. Hence, while non-present loads stall the
CPU, illegal loads are still executed. We present EchoLoad, a novel
technique to distinguish load stalls from transiently executed loads.
EchoLoad allows detecting physically-backed addresses from un-
privileged applications, breaking KASLR in 40 µs on the newest
Meltdown- and MDS-resistant Cascade Lake microarchitecture. As
EchoLoad only relies on memory loads, it runs in highly-restricted
environments, e.g., SGX or JavaScript, making it the first JavaScript-
based KASLR break. Based on EchoLoad, we demonstrate the first
proof-of-concept Meltdown attack from JavaScript on systems that
are still broadly not patched against Meltdown, i.e., 32-bit x86 OSs.
We propose FLARE, a generic mitigation against known microar-
chitectural KASLR breaks with negligible overhead. By mapping
unused kernel addresses to a reserved page and mirroring neigh-
boring permission bits, we make used and unused kernel memory
indistinguishable, i.e., a uniform behavior across the entire kernel
address space, mitigating the root cause behind microarchitectural
KASLR breaks. With incomplete hardware mitigations, we propose
to deploy FLARE even on recent CPUs.
Click to expand...

Even though new CPUs are not vulnerable anymore to the
original Meltdown attack, we show that they still show signs of
Meltdown-type effects. In this paper, we investigate CPUs that have
hardware-based Meltdown mitigations. We analyze these fixes and
develop the hypothesis that they only prevent the data from being
used in subsequent operations, not the actual load. We confirm this
hypothesis by showing that the fixes introduce new side effects,
namely that on illegal accesses to kernel addresses, the CPU zeroes
out the data but still performs the load. In contrast, loads from non-
present pages stall the CPU. We present a method based on Flush+
Reload [95] to distinguish the stalling behavior of loads. With this
method, we can exploit the side effects of the Meltdown mitigations
to break KASLR reliably. By probing the kernel space for load stalls,
we detect whether the probed virtual address is physically backed,
revealing the location of the kernel. We demonstrate that these
effects can also be exploited on older CPUs, which are affected by
Meltdown but protected by software mitigations.

Our KASLR break, EchoLoad, works on all major OSs (Linux,
Windows, macOS, and Android x86_64). We tested the KASLR break
on Intel microarchitectures from Arrandale (2010) to Cascade Lake
(2019) on Atom, Core, and Xeon CPUs. Even on Cascade Lake with
fixes for Meltdown and MDS [41], we de-randomize the kernel in
40 µs (F-score 1, n = 109). Hence, our KASLR break is the fastest
and most reliable one published. Moreover, EchoLoad is the only
KASLR break that only relies on memory loads and works on Intel
microarchitectures since at least 2010. EchoLoad even works on
KPTI, the Linux software mitigation for Meltdown.

As EchoLoad does not require anything but memory loads, it
works in restricted environments such as SGX and JavaScript. We
highlight that EchoLoad can aid kernel exploitation from within
SGX enclaves, facilitating SGX malware [81, 82]. In contrast to
previous ASLR breaks from JavaScript [7, 29, 76], we are the first
to demonstrate a microarchitectural KASLR break from JavaScript
on x86 OSs. We also show that on older unpatched x86 OSs, Melt-
down can even be exploited from JavaScript. This is particularly
dangerous for any Windows XP machines (1–3% of Desktop com-
puters [68]), for which no software patches are available, but which
are still running in official, commercial, industrial, or personal en-
vironments. Our attack will also soon be possible on unprotected
64-bit systems as WebAssembly plans to extend the size of linear
memory indices to 64 bit [90]. We pinpoint the remaining challenges
for widely deployable JavaScript-based Meltdown exploits.

To mitigate all microarchitectural attacks on KASLR, including
EchoLoad, we present FLARE (Fake Load Address REsponse). The
basic idea is to back the entire kernel address space with physical
pages. FLARE prevents previous attacks [9, 32, 37, 49, 76] by hiding
the kernel within a virtual-address range appearing to be valid. Our
proof-of-concept implementation has a memory overhead of only
12 kB, and no measurable runtime overhead.
FLARE is compatible with KPTI on Meltdown-affected CPUs,
and forms a low-cost mitigation on CPUs with hardware fixes. We
evaluated our open-source proof-of-concept implementation of
FLARE1 for Linux for both cases. Our results show that FLARE
indeed prevents all known microarchitectural attacks on KASLR.
We conclude that while the hardware mitigation for Meltdown
fixes the problem of Meltdown-US [10], they introduce a new side
effect by merely zeroing out data that is illegally accessed, enabling
EchoLoad. Based on our analysis of the behavior of AMD and ARM
CPUs, we believe that the only complete solution for Meltdown is
to treat inaccessible pages the same way as unmapped pages. Fur-
thermore, the software-based isolation of user and kernel space [31]
is not sufficient, and we thus suggest to deploy FLARE to prevent
microarchitectural attacks on the kernel.
Click to expand...

CONCLUSIO N
In this paper, we analyzed Intel’s recent hardware fixes for Melt-
down. Our analysis led to the understanding that illegal memory
accesses do not lead to a CPU stall, but instead, the illegally loaded
data is zeroed-out. With EchoLoad, we presented a novel tech-
nique based on Flush+Reload to distinguish stalling loads from
transiently executed ones. Hence, EchoLoad enables an attacker to
detect physically-backed kernel addresses and break KASLR. Our
KASLR break is the fastest and most reliable microarchitectural
KASLR break presented so far, taking only 40 µs to de-randomize
the kernel. The only requirement for EchoLoad are memory loads,
allowing it to be mounted from restricted environments such as
SGX and JavaScript. We presented the first JavaScript-based Melt-
down attack and KASLR break on the systems that do not receive
Meltdown patches, i.e., x86 32-bit OSs.
With FLARE, we proposed a generic approach for protecting
the kernel against microarchitectural KASLR breaks. We verified
that FLARE mitigates the root cause behind current microarchi-
tectural KASLR breaks and yields a uniform behavior across the
kernel address space. Thus, considering the state of the hardware
mitigations, we propose to deploy FLARE even on the most recent
CPU generations.
Click to expand...

jsg from LEB forum probably summarized the key points at Yet another serious attack on/vuln. of intel CPUs - "EchoLoad"

Welcome to yet another very serious attack on intel processors.

Why very serious?

Because all intel processors from Pentium 4 (Prescott) up to the newest Cascade Lake are vulnerable

Because KASLR (kernel address space layout randomization) can not protect the kernel against the attack.

Because kernel space can in fact be de-randomized ("unprotected") within tens of microseconds

Because it does not require intel TSX or knowledge of internal data structures

Because the attack is deeply rooted in the design of the microarchitecture, it cannot easily be fixed, neither in software nor hardware

Even on Cascade Lake with fixes for Meltdown and MDS the kernel can be de-randomized

The attack even works on KPTI, the Linux software mitigation for Meltdown.

The attack also works in restricted environments such as SGX

How about AMD? - AMD Zen is not vulnerable
Click to expand...

Looks like more folks will be moving to AMD Zen2 Rome based EPYC cpus eventually.

Cloudflare is making the move with their Gen X servers using AMD EPYC 7642 zen2 Rome based cpus Cloudflare - Cloudflare Outlines Gen X servers - AMD EPYC 7642 based

Revenge · Mar 13, 2020

You only LVI twice: Meltdown The Sequel strikes Intel chips – and full mitigation against data-meddling flaw will cost you 50%+ of performance

Computer security researchers involved in the discovery of the Meltdown and Spectre vulnerabilities affecting many modern processors have developed a related attack technique called Load Value Injection (LVI).

The attack relies on microarchitectural data leakage to inject and execute malicious code in a way that breaks the confidentiality of modern Intel systems.

Chipzilla's processors, already weighed down by defenses deployed against side-channel attacks over the past two years, could get slower still if they try to thwart this latest vulnerability: prototype compiler changes, for full mitigation, have produced performance reductions ranging from 2x to 19x.
Click to expand...

The Brutal Performance Impact From Mitigating The LVI Vulnerability - Phoronix

Ouch...

eva2000 · Mar 13, 2020

Ah you beat me to LVI posting LVI Attack Hits Intel SGX - Defeats Existing Mitigations, More Performance Hits - Phoronix

Load Value Injection (LVI) is being disclosed today as a new class of transient-execution attacks and the researchers claim can defeat all existing mitigations around Meltdown, Foreshadow, Zombieload, RIDL and Fallout. The researchers say LVI can affect virtually any access to memory and compiler-based mitigations can be expensive.

LVI combines Spectre-style code gadgets with Meltdown-type illegal data flows to bypass existing defenses and allow injecting data into a victim's transient execution. LVI was discovered in April of 2019 while today the researchers and Intel are making a coordinated disclosure. The initial discovery was made again by university researchers but Bitdefender ended up also discovering the same vulnerability.

It is important to note that LVI appears to be predominantly impact Intel SGX and Icelake's hardware mitigations do protect against this vulnerability while other partially mitigated Intel CPUs are only partially vulnerable.
Click to expand...

Yes brutal overhead for mitigations if you compile software with the new mitigations - though most YUM package apps aren't compiled with those mitigations as yet The Brutal Performance Impact From Mitigating The LVI Vulnerability - Phoronix

LVI attack researchers noted that with their testing "we observe extensive overheads of factor 2 to 19 for prototype implementations of the full mitigation." Of course, now having the GNU toolchain mitigations merged, I was eager to see the performance impact in real workloads.
Click to expand...

Look at the drop in OpenSSL performance when OpenSSL 1.1.1 compiled with the new mitigation fixes for LVI ! From 1,217.6 signs/sec to 138.1 signs/sec = 88.65% drop

Log in / Register

Forums

Learn about Centmin Mod LEMP Stack today

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

eva2000 Administrator Staff Member

eva2000 Administrator Staff Member

eva2000 Administrator Staff Member

eva2000 Administrator Staff Member

eva2000 Administrator Staff Member

eva2000 Administrator Staff Member

eva2000 Administrator Staff Member

Revenge Active Member

eva2000 Administrator Staff Member

eva2000 Administrator Staff Member

eva2000 Administrator Staff Member

eva2000 Administrator Staff Member

eva2000 Administrator Staff Member

eva2000 Administrator Staff Member

eva2000 Administrator Staff Member

eva2000 Administrator Staff Member

eva2000 Administrator Staff Member

eva2000 Administrator Staff Member

Revenge Active Member

eva2000 Administrator Staff Member

.

Log in / Register

Useful Searches

Learn about Centmin Mod LEMP Stack today

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

eva2000 Administrator Staff Member

eva2000 Administrator Staff Member

eva2000 Administrator Staff Member

eva2000 Administrator Staff Member

eva2000 Administrator Staff Member

eva2000 Administrator Staff Member

eva2000 Administrator Staff Member

Revenge Active Member

eva2000 Administrator Staff Member

eva2000 Administrator Staff Member

eva2000 Administrator Staff Member

eva2000 Administrator Staff Member

eva2000 Administrator Staff Member

eva2000 Administrator Staff Member

eva2000 Administrator Staff Member

eva2000 Administrator Staff Member

eva2000 Administrator Staff Member

eva2000 Administrator Staff Member

Revenge Active Member

eva2000 Administrator Staff Member

.