On Thu, 4 Jan 2018 20:16:18 +0000 Ken Moffat <zarniwh...@ntlworld.com> wrote:
> There are two vulnerabilities, with the shiny names of Meltdown and > Spectre. Both refer to ways of userspace finding where the kernel > has been mapped, to try to do harm. Page Table Isolation addresses > the first of these. Google claim it affects some AMD processors, > AMD deny this. Most interesting, but also scary. Here's my own summary take on the info which I found at: http://www.tomshardware.com/news/meltdown-spectre-exploits-intel-amd-arm-nvidia,36219.html https://wccftech.com/intel-affected-by-critical-kernel-bug-amd-hit/ https://overclock3d.net/news/cpu_mainboard/amd_releases_response_to_meltdown_and_spectre_exploits/ https://www.phoronix.com/scan.php?page=news_item&px=Linux-Tip-Git-Disable-x86-PTI https://www.theregister.co.uk/2018/01/04/intel_amd_arm_cpu_vulnerability/ There are three variants of this new class of vulnerability which all involve gaining illegal read access to memory: Variant 1: Bounds check bypass, aka "Spectre (Version 1)", CVE-2017-5753, Supposedly, is to be fixed within the kernel. It is promised to be an easy and painless fix. Almost all modern processors are affected. Variant 2: Branch target injection, aka "Spectre (Version 2)", CVE-2017-5715 May require a CPU microcode update or recompiling all the applications to fix. More mystery and conflicting info over this one than the other variants. AMD claims vulnerability is "almost zero". The Zen family may be an exception (see below). Variant 3: Rogue data cache load aka "Meltdown", CVE-2017-5754 The new Linux kernel Page Table Isolation (PTI) feature protects against this exploit. All post-1995, except Itanium and pre-2013 Atom, Intel CPUs and Arm Cortex-A15, Cortex-A57, Cortex-A72 and Cortex-A75 cores are vulnerable. No AMD CPUs are vulnerable to variant 3. From https://wccftech.com/intel-affected-by-critical-kernel-bug-amd-hit/ "Variant 1 is software [OS] patchable and affects almost all modern processors. The patch itself will have negligible performance hit. Variant 2 and 3 are rooted further in hardware and are not patchable by any known means of code. Attempting to patch these using software will result in performance hits and so far these only seem to affect Intel and ARM processors with near zero risk to AMD CPUs." However, the above quote is a little misleading because the Linux kernel Page Table Isolation (PTI) feature should be able to prevent Variant 3, albeit with a load dependent performance penalty. Tis real bad news for folks using Intel because Intel's processors are impacted much more severely than those of AMD. In particular, "it is said that Meltdown (Variant 3) has been tested on all Intel processor generations since 2011, with 'effectively every processor since 1995' being affected (with a few exceptions)". AMD claims its processors are not vulnerable to Variant 3 (and the upcoming Linux kernel releases will disable the PTI protection config option by default for AMD processors), and that they have "near zero" risk from variant 2 (but see below for evidence that Ryzen CPUs might have an issue with variant 2). Variant 1 affects almost all modern processors, including those of AMD, and may require future hardware architecture changes to totally mitigate without the need for OS patches/protection. However, AMD now claims it has developed a patch (kernel or microcode level?) that "can mitigate variant 1 with minimal performance impact." From https://wccftech.com/intel-affected-by-critical-kernel-bug-amd-hit/ there were four proof of concept exploits that have been demonstrated: "During the course of our research, we developed the following proofs of concept (PoCs): 1. 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. This PoC only tests for the ability to read data inside mis-speculated execution within the same process, without crossing any privilege boundaries. 2. 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. 3. 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 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.) 4. 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. " Thus, from PoC #1, the AMD exploit can only read data from the same process space, in a conditional branch of code that was not taken, in which there would be no privilege violation for so doing. If I understand correctly, this means that memory for a process can be read by a part of that process (with the same process owner), even if the application/process code itself would not provide for the means to do that at the other (exploited) part of the process. However, from PoC #2, AMD pro (laptop) CPUs can allow arbitrary reads from *kernel* memory, if and only if, the Linux kernel Berkeley packet filter just in time compiler kernel option (> Networking support > Networking options, CONFIG_BPF_JIT) is enabled, which it is not by default. Therefore, at present, it seems all Linux AMD users will need to do is: 1. Do not enable CONFIG_BPF_JIT when using AMD Pro CPUs. 2. Upgrade the CPU microcode and/or kernel when a version is released that incorporates AMD's variant 1 fix. There is, however, conflicting information when it comes to the AMD (Zen/Ryzen) CPUs and variant 2: https://www.realworldtech.com/forum/?threadid=173741&curpostid=173810 Suse and Red Hat have released a firmware/microcode update for the AMD 17h family (Zen). This new firmware claims to " This new firmware disables branch prediction on AMD family 17h processor. Also the CPU microcode for Intel Haswell-X, Skylake-X and Broadwell-X chipsets was updated to report both branch prediction control via CPUID flag and ability to control branch prediction via an MSR register. " to overcome variant 2. Disabling branch prediction is a serious matter. So, if this really is true, AMD Zen CPUs (and the Intel CPUs if/whenever branch prediction is disabled via the new register control) will experience a severe performance hit when using this new microcode to overcome variant 2. With Intel, the kernel patch for variant 3 can result in a double digit performance hit in some applications. "Intel's CEO, Brian Krzanich, also sold $39 million in stocks in November 2017 (this doesn't include the amount he paid for the stock options)." Oh brother! This is just another example of why it is important to have multiple players (eggs) of the CPU manufacturers (in different baskets). Intel has too much of a share of the CPU market for the health of the industry. (Of course, this is coming from someone who always wanted the Motorola 68000 series to be the winner of the CPU world.) Cheers, Mike Shell -- http://lists.linuxfromscratch.org/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page Do not top post on this list. A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? http://en.wikipedia.org/wiki/Posting_style
