formulav8
Diamond Member
- Sep 18, 2000
- 7,004
- 522
- 126
Intel slides on the security issue
https://s21.q4cdn.com/600692695/files/doc_presentations/2018/Side-Channel-Analysis-Security.pdf
Investor call going on right now
https://edge.media-server.com/m6/p/wauzyn2f
intel said:
- NOT a result of product errata; processors are operating to specification
- Mitigations include. . . future hardware
Interesting slides.
Name dropping AMD is a bold move after an engineer claims they are not affected.
Google Zero claims basically everyone is affected
https://security.googleblog.com/2018/01/todays-cpu-vulnerability-what-you-need.html
Which systems are affected by Meltdown?
Desktop, Laptop, and Cloud computers may be affected by Meltdown. More technically, every Intel processor which implements out-of-order execution is potentially affected, which is effectively every processor since 1995 (except Intel Itanium and Intel Atom before 2013). We successfully tested Meltdown on Intel processor generations released as early as 2011. Currently, we have only verified Meltdown on Intel processors. At the moment, it is unclear whether ARM and AMD processors are also affected by Meltdown.
Which systems are affected by Spectre?
Almost every system is affected by Spectre: Desktops, Laptops, Cloud Servers, as well as Smartphones. More specifically, all modern processors capable of keeping many instructions in flight are potentially vulnerable. In particular, we have verified Spectre on Intel, AMD, and ARM processors.
What is the difference between Meltdown and Spectre?
Meltdown breaks the mechanism that keeps applications from accessing arbitrary system memory. Consequently, applications can access system memory. Spectre tricks other applications into accessing arbitrary locations in their memory. Both attacks use side channels to obtain the information from the accessed memory location. For a more technical discussion we refer to the papers ( Meltdown and Spectre)
"These vulnerabilities affect many CPUs, including those from AMD, ARM, and Intel, as well as the devices and operating systems running them."
I think that is pretty conclusive, it is coming from Google afterall. The key question however is are certain cpus performance impacted more than others? I hear it is. That AMD and Coffee Lake will be less impacted.
"These vulnerabilities affect many CPUs, including those from AMD, ARM, and Intel, as well as the devices and operating systems running them."
I think that is pretty conclusive, it is coming from Google afterall. The key question however is are certain cpus performance impacted more than others? I hear it is. That AMD and Coffee Lake will be less impacted.
I just received an email from Amazon regarding several hundred of our VM's. There will be a forced reboot of many of our instances on JAN04. It looks like Amazon is on top of this and has known about it for some time. I'm interested to know if they are pathing their physical servers or their hypervisor software. My guess is their Hypervisor.
"These vulnerabilities affect many CPUs, including those from AMD, ARM, and Intel, as well as the devices and operating systems running them."
I think that is pretty conclusive, it is coming from Google afterall. The key question however is are certain cpus performance impacted more than others? I hear it is. That AMD and Coffee Lake will be less impacted.
During the course of our research, we developed the following proofs of concept (PoCs):
- A PoC that demonstrates the basic principles behind variant 1 in userspace on the tested Intel Haswell Xeon CPU, the AMD FX CPU, the AMD PRO CPU and an ARM Cortex A57 [2]. This PoC only tests for the ability to read data inside mis-speculated execution within the same process, without crossing any privilege boundaries.
- A PoC for variant 1 that, when running with normal user privileges under a modern Linux kernel with a distro-standard config, can perform arbitrary reads in a 4GiB range [3] in kernel virtual memory on the Intel Haswell Xeon CPU. If the kernel's BPF JIT is enabled (non-default configuration), it also works on the AMD PRO CPU. On the Intel Haswell Xeon CPU, kernel virtual memory can be read at a rate of around 2000 bytes per second after around 4 seconds of startup time. [4]
- A PoC for variant 2 that, when running with root privileges inside a KVM guest created using virt-manager on the Intel Haswell Xeon CPU, with a specific (now outdated) version of Debian's distro kernel [5] running on the host, can read host kernel memory at a rate of around 1500 bytes/second, with room for optimization. Before the attack can be performed, some initialization has to be performed that takes roughly between 10 and 30 minutes for a machine with 64GiB of RAM; the needed time should scale roughly linearly with the amount of host RAM. (If 2MB hugepages are available to the guest, the initialization should be much faster, but that hasn't been tested.)
- A PoC for variant 3 that, when running with normal user privileges, can read kernel memory on the Intel Haswell Xeon CPU under some precondition. We believe that this precondition is that the targeted kernel memory is present in the L1D cache.
Wed, 3 Jan 2018 08:21:47 -0800
From tip-bot for Tom Lendacky <>
Subject [tip:x86/pti] x86/cpu, x86/pti: Do not enable PTI on AMD processors
Commit-ID: 694d99d40972f12e59a3696effee8a376b79d7c8
Gitweb: https://git.kernel.org/tip/694d99d40972f12e59a3696effee8a376b79d7c8
Author: Tom Lendacky <thomas.lendacky@amd.com>
AuthorDate: Tue, 26 Dec 2017 23:43:54 -0600
Committer: Thomas Gleixner <tglx@linutronix.de>
CommitDate: Wed, 3 Jan 2018 15:57:59 +0100
x86/cpu, x86/pti: Do not enable PTI on AMD processors
AMD processors are not subject to the types of attacks that the kernel
page table isolation feature protects against. The AMD microarchitecture
does not allow memory references, including speculative references, that
access higher privileged data when running in a lesser privileged mode
when that access would result in a page fault.
Disable page table isolation by default on AMD processors by not setting
the X86_BUG_CPU_INSECURE feature, which controls whether X86_FEATURE_PTI
is set.
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Borislav Petkov <bp@suse.de>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: stable@vger.kernel.org
Link: https://lkml.kernel.org/r/20171227054354.20369.94587.stgit@tlendack-t1.amdoffice.net
---
arch/x86/kernel/cpu/common.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
index f2a94df..b1be494 100644
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -899,8 +899,8 @@ static void __init early_identify_cpu(struct cpuinfo_x86 *c)
setup_force_cpu_cap(X86_FEATURE_ALWAYS);
- /* Assume for now that ALL x86 CPUs are insecure */
- setup_force_cpu_bug(X86_BUG_CPU_INSECURE);
+ if (c->x86_vendor != X86_VENDOR_AMD)
+ setup_force_cpu_bug(X86_BUG_CPU_INSECURE);
fpu__init_system(c);
Data shows near zero risk to AMD. AMD may need one patch that negligibly affects performance.
I'm guessing Intel needs all of the patches...
"near zero" and "not yet" those are words play, they are unsure yet.
Meltdown and Spectre
Prior to the official revelation of Meltdown and Spectre on Wednesday, Erik Bosman, a colleague of Gras in Vrije Universiteit Amsterdam's VUSEC security group, successfully reproduced one of the Intel attacks, which take advantage of a feature in chips known as "speculative execution." When modern Intel processors execute code and come to a point in an algorithm where instructions branch in two different directions, depending on input data—whether there's enough money in an account to process a transaction, for instance—they save time by "speculatively" venturing down those forks. In other words, they take a guess, and execute instructions to get a head start. If the processor learns that it ventured down the wrong path, it jumps back to the fork in the road, and throws out the speculative work.
VUSEC's Bosman confirmed that when Intel processors perform that speculative execution, they don't fully segregate processes that are meant to be low-privilege and untrusted from the highest-privilege memory in the computer's kernel. That means a hacker can trick the processor into allowing unprivileged code to peek into the kernel's memory with speculative execution.
"The processor basically runs too far ahead, executing instructions that it should not execute," says Daniel Gruss, one of the researchers from the Graz University of Technology who discovered the attacks.
Retrieving any data from that privileged peeking isn't simple, since once the processor stops its speculative execution and jumps back to the fork in its instructions, it throws out the results. But before it does, it stores them in its cache, a collection of temporary memory allotted to the processor to give it quick access to recent data. By carefully crafting requests to the processor and seeing how fast it responds, a hacker's code could figure out whether the requested data is in the cache or not. And with a series of speculative execution and cache probes, he or she can start to assemble parts of the computer's high privilege memory, including even sensitive personal information or passwords.
Many security researchers who spotted signs of developers working to fix that bug had speculated that the Intel flaw merely allowed hackers to defeat a security protection known as Kernel Address Space Layout Randomization, which makes it far more difficult for hackers to find the location of the kernel in memory before they use other tricks to attack it. But Bosman confirms theories that the bug is more serious: It allows malicious code to not only locate the kernel in memory, but steal that memory's contents, too.
"Out of the two things that were speculated, this is the worst outcome," Bosman says.
A Tough Fix
In a statement responding to the Meltdown and Spectre research, Intel noted that "these exploits do not have the potential to corrupt, modify, or delete data," though they do have the ability to spy on privileged data. The statement also argued that "many types of computing devices—with many different vendors’ processors and operating systems—are susceptible to these exploits," mentioning ARM and AMD processors as well.
"I can confirm that Arm have been working together with Intel and AMD to address a side-channel analysis method which exploits speculative execution techniques used in certain high-end processors, including some of our Cortex-A processors," says ARM public relations director Phil Hughes. "This method requires malware running locally and could result in data being accessed from privileged memory." Hughes notes that ARM's IoT-focused Cortex-M line is unaffected.