Many modern processors have implementation issues that allow unprivileged attackers to bypass user-kernel or inter-process memory access restrictions, by exploiting speculative execution and shared resources (caches).

Details of these flaws were announced publicly on 3 January 2018.

Links

Background and General

x86

Arm

Power

MIPS

Per-architecture status

CVE:

CVE-2017-5753

CVE-2017-5715

CVE-2017-5754

P0 variant:

Variant 1

Variant 2

Variant 3

Nickname:

Spectre

Spectre

Meltdown

arch

microarch

amd64

AMD

Vulnerable

Mitigation [8]

Not vulnerable

Intel

Vulnerable

Mitigation [8]

Mitigation [1,5,6]

Via

i386

arm64

Cavium ThunderX

Not vulnerable

Not vulnerable

Not vulnerable

Cavium ThunderX2 *

Vulnerable

Vulnerable

Not vulnerable

Qualcomm Falkor *

Vulnerable

Cortex A53, A55

Not vulnerable

Not vulnerable

Not vulnerable

Cortex A57

Vulnerable

Mitigation [2]

Not vulnerable

Cortex A72

Vulnerable

Mitigation [2]

Not vulnerable

Cortex A73

Vulnerable

Mitigation [2]

Not vulnerable

Cortex A75

Vulnerable

Mitigation [2]

Vulnerable (3a)

armv7

Cortex A5, A7

Not vulnerable

Not vulnerable

Not vulnerable

Cortex A8, A9, A15, A17

Vulnerable

Mitigation [4]

Not vulnerable

armv4,5,6

Not vulnerable

Not vulnerable

Not vulnerable

mips

MIPS P5600

Vulnerable

Vulnerable

Not vulnerable

MIPS P6600

Vulnerable

Vulnerable

Not vulnerable

MIPS Other

Not vulnerable

Not vulnerable

Not vulnerable

sparc64

powerpc64

POWER6

Vulnerable

Vulnerable

Not vulnerable +

POWER7, POWER8, POWER9

Vulnerable

Vulnerable

Not vulnerable +

* These CPUs are not yet supported by FreeBSD
+ ppc64 hashed page tables use separate user/kernel address space and are not vulnerable to meltdown

NOTE: Empty cells and unlisted architectures either have an unknown status, or will be added to the table shortly.

This table represents the most up-to-date information we have, but as the understanding of these vulnerabilities is changing rapidly certain details may be out of date or incorrect.

Mitigation Patch Tracking

Commit

#

Description

Review

HEAD

stable/11

stable/10

1

amd64 PTI (Meltdown)

D13797, D13956, D13962

r328083, r328096, r328116, r328119, r328120, r328128, r328135, r328153, r328157, r328177, r328199, r328202, r328205, r328468

r329462

2

arm64 Spectre variant 2

D13812

r327876

3

amd64 bhyve partial Spectre variant 2

D13919

r328011

4

armv7 Spectre variant 2

D13931

r328467

5

amd64 PTI-PCID integration

D13985

r328470

r329462

6

amd64 PTI default setting

D13971

r328166, r328624

r329462

7

amd64 Spectre IBRS

D14029

r328625, r328627, r328628

r329462

8

x86 Clang retpoline Spectre variant 2

LLVM D41723, D14228, D14242

r328817, r328972, r330110, r330112

NOTE: Descriptions above indicate patch applicability (e.g. arch and variant) but are not necessarily the entire/full or final mitigation for the issue.

AMD64 user guide

Meltdown (CVE-2017-5754)

Meltdown vulnerability requires using separate kernel and user mode page tables, so that user mode does not have sensitive physical pages mapped even with restricted permissions. The technique is known as Page Table Isolation (PTI) and implemented for amd64 kernel. PTI is enabled by default for any non-AMD CPUs. You can enforce PTI, or instead disable it, with vm.pmap.pti=0 loader tunable.

The older Intel Atoms CPUs are in-order and there is a belief that they are not vulnerable to Meltdown. We do not try to distinguish the microarchitectures to not enable PTI on such CPUs, since we do not have conclusive answer to that question, and do not have exhaustive list of the microarchitecture identifiers.

At https://github.com/dag-erling/meltdown you can find a test for Meltdown, which might be used to verify the CPU. Note that positive result from it is definitive, while negative answer might indicate the required tweaking for the test instead of the bug free CPU.

Spectre variant 2 (CVE-2017-5715)

The patches for retpoline approach to mitigation of the Spectre variant 2 vulnerability are in work, meantime we provide IBRS-based mitigation on Intel CPUs. The IBRS mitigation main disadvantage is the significant performance penalty. Also, due to the situation with the Intel microcode releases, it is somewhat not trivial to find working and stable blob.

AMD promised to provide the same mechanism, but its presence on AMD CPUs is detected differently than on Intel CPUs. We do not yet see any AMD CPU with this capability, so the supposed code to detect and use IBRS on AMD is not committed. Also, it seems that AMD specifies that even if SMEP is enabled, user/kernel boundary IBRS protection still requires Return Stack Buffer (RSB) flush. On Intels, it is only needed for CPUs not providing the SMEP.

You can verify that the IBRS-enabling microcode is loaded by looking at the dmesg buffer after the microcode update. If the line Structured Extended Features3=0xc000000<IBPB,STIBP> appears in the CPU features report, then IBPB (the IBRS barrier) feature is patched in, so system can perform the mitigation on user/kernel boundary. Current status of the mitigation can be verified with the sysctl hw.ibrs_active. If the CPU feature is present and not disabled by the tunable/sysctl hw.ibrs_disable, it should indicate activation.

If you have access to the Intel microcode list, for instance https://newsroom.intel.com/wp-content/uploads/sites/11/2018/04/microcode-update-guidance.pdf, you can look at the version of the currently patched microcode as well. Use sysutils/x86info from ports, load the cpuctl(4) driver (already required for microcode load), and use the '-a' switch to see the microcode version among other things.

Spectre variant 1 (CVE-2017-5753)

<empty>

SpeculativeExecutionVulnerabilities (last edited 2018-04-04 20:16:06 by JungukKim)