Spectre / Meltdown Code Gets Cleaned Up, Improvements For Linux 4.16

[bugmenot3]

I've read that PowerPC G3 and G4 cannot be actually exploited in practice (they are vulnerable, but their speculative execution doesn't go far enough to lead anything exploitable).

Regarding PPC this might be an interesting read:

http://tenfourfox.blogspot.de/2018/01/actual-field-testing-of-spectre-on.html

[DrYak]

I saw the same microcode and always Spectre variante 1 vulnerable..

Remember there are 2 variants of Spectre.

variant 1 is about bound check bypass -
it's still speculative execution working as it should, only some people have found way to measure indirectly side-effect (pages being fetched into cache).
But it's still a program only accessing data to which it has already access.

there isn't much to be done to *fix* it (beyond completely new CPUs that also flush speculatively fetched cache, in addition of not comiting result to memory register ; or CPUs that don't do speculative execution at all).

but you can fix your code and program: avoid running 3rd party provided code (eg.: Javascript JIT ; kernel EBPF JIT) in the same context as sensitive data (resp.: in the same process as password managing extension ; in the kernel context).
Also some CPUs like the Pentium4 support branch prediction hinting and you could use them to ask the processor to never speculatively execute past a boundary check in case of speculative execution of 3rd party code.

in other word: until some future CPU fixes its speculative execution, or using a CPU that doesn't execute speculatively (older Intel Atoms, lots of RISC CPU like older ARMs) it's going to say "Spectre_v1:Vulnerable" forever



variant 2 is about the indirect branch predictor getting confused and using the wrong table (e.g.: one that was filled by an attacker running a special program) when running an entirely unrelated and different program (e.g.: a Hyper Visor) due to the way the predictor is implemented (in Google's demo code : both the attacker's program and the targeted program have the same "hash" for the jump instruction) leading the CPU to jump and start speculatively predicting at a completely wrong target.

that's the one which is fixed by firmware updates and retpolines.
That's the one which should change status depending on the compiler that was used (only retpoline manually specified in ASM code, or GCC compiler able to also automatically do them in C code) and/or firmware.

Also it's entirely dependent on how each CPU implements its own peculiar indirect branch prediction.

Intel CPUs are known to be vulnerable, and Google has published demo code.

AMD should be vulnerable, but the way I read the official documentations is that it's not clear if you can actually use that to make an usable real-world exploit
(the Google demo code obviously won't work being taylored after the predictor of a completely different CPU).

A few modern ARM are reported to be vulnerable (I haven't read anything about this actually being exploitable).

I've read that PowerPC G3 and G4 cannot be actually exploited in practice (they are vulnerable, but their speculative execution doesn't go far enough to lead anything exploitable).

[starshipeleven]

And Diamondville Atoms (Family 3) being the "Hey, we can make this passively cooled half decent low power 64 bit x86 core. Let us pair it with a shitty power hungry northbridge (945GC), slap a whiny cooler on and call it day" ;-)

Yeah, I was amazed to see that a pretty normal industrial mini-itx board with a 8W Atom 330 processor was somehow burning 25W on idle and 30W on load.

Is Diamondville affected?

I severely doubt it. If later (better) Atoms still lacked that feature Diamondville could not have it either.

But still, the Pentium you got will still outperform the 330 on anything even after the software workarounds (with performance impact) are applied to the kernel, so it's not really worth it to pull up the old board.

Anyway, this is the relevant code from the patch:

+static const __initdata struct x86_cpu_id cpu_no_speculation[] = {
+ { X86_VENDOR_INTEL, 6, INTEL_FAM6_ATOM_CEDARVIEW, X86_FEATURE_ANY },
+ { X86_VENDOR_INTEL, 6, INTEL_FAM6_ATOM_CLOVERVIEW, X86_FEATURE_ANY },
+ { X86_VENDOR_INTEL, 6, INTEL_FAM6_ATOM_LINCROFT, X86_FEATURE_ANY },
+ { X86_VENDOR_INTEL, 6, INTEL_FAM6_ATOM_PENWELL, X86_FEATURE_ANY },
+ { X86_VENDOR_INTEL, 6, INTEL_FAM6_ATOM_PINEVIEW, X86_FEATURE_ANY },
+ { X86_VENDOR_CENTAUR, 5 },
+ { X86_VENDOR_INTEL, 5 },
+ { X86_VENDOR_NSC, 5 },
+ { X86_VENDOR_ANY, 4 },
+ {}
+};
+
+static const __initdata struct x86_cpu_id cpu_no_meltdown[] = {
+ { X86_VENDOR_AMD },
+ {}
+};
+
+static bool __init cpu_vulnerable_to_meltdown(struct cpuinfo_x86 *c)
+{
+ u64 ia32_cap = 0;
+
+ if (x86_match_cpu(cpu_no_meltdown))
+ return false;
+
+ if (cpu_has(c, X86_FEATURE_ARCH_CAPABILITIES))
+ rdmsrl(MSR_IA32_ARCH_CAPABILITIES, ia32_cap);
+
+ /* Rogue Data Cache Load? No! */
+ if (ia32_cap & ARCH_CAP_RDCL_NO)
+ return false;
+
+ return true;
+}
+

There is a list of Atom families (and other obscure processors, like for VIA ones) that are whitelisted, "X86_VENDOR_INTEL, 5" should be the Intel Quark family of SoCs (Arduino Galileo and related embedded products), then AMD processors that don't have Meltdown because AMD, and then there is some logic looking for CPU features to determine if the CPU is susceptible to Meltdown.

[whitecat]

What is Family 4 / 5 of the Intel Atom? Given Avoton is relatively new, that probably still has the issue.

According to the code :

static const __initdata struct x86_cpu_id cpu_no_speculation[] = {
{ X86_VENDOR_INTEL, 6, INTEL_FAM6_ATOM_CEDARVIEW, X86_FEATURE_ANY },
{ X86_VENDOR_INTEL, 6, INTEL_FAM6_ATOM_CLOVERVIEW, X86_FEATURE_ANY },
{ X86_VENDOR_INTEL, 6, INTEL_FAM6_ATOM_LINCROFT, X86_FEATURE_ANY },
{ X86_VENDOR_INTEL, 6, INTEL_FAM6_ATOM_PENWELL, X86_FEATURE_ANY },
{ X86_VENDOR_INTEL, 6, INTEL_FAM6_ATOM_PINEVIEW, X86_FEATURE_ANY },
{ X86_VENDOR_CENTAUR, 5 },
{ X86_VENDOR_INTEL, 5 },
{ X86_VENDOR_NSC, 5 },
{ X86_VENDOR_ANY, 4 },
{}
};

[Veto]

Cedarview being the total bullshit "we didn't totally suck on CPU but we have PowerVR GPU and since IT is notoriously a bag of dicks we won't even have 64bit GPU drivers for windows, go figure how well the GPU runs in Linux". I remember the flaming Intel got for that screwup.

Pineview were the first gen of Atoms that were somehow usable (with Linux anyway), at least back then, and also support a 64bit OS even if their memory controller can only use 2GB of ram total.

And Diamondville Atoms (Family 3) being the "Hey, we can make this passively cooled half decent low power 64 bit x86 core. Let us pair it with a shitty power hungry northbridge (945GC), slap a whiny cooler on and call it day" ;-) However, I believe Diamondville was quite popular when paired with the more powerful Nvidia ION chipset.

I recently changed my home server from an Atom 330 board to a Pentium G4400 and gained a 12 W saving - but apparently also got a Meltdown vulnerability.

Is Diamondville affected?

[devius]

I'm pretty sure there are no Atoms in Family 4 or 5, considering those families are comprised of 486 and original Pentium CPUs. All Atoms are family 6 or newer, however looking at the linked PR the unaffected Atoms have the following codenames: CEDARVIEW, CLOVERVIEW, LINCROFT, PENWELL and PINEVIEW.

[scorpio810]

Does anyone actually have an overview regarding Spectre mitigation techniques? I'm curious about the performance impact of both, retpoline or the microcode based approach, and also how bad the performance impact of the microcode based approach is on different CPUs (given that Ryzen for instance should not need IBRS afaik).

Also: Any news regarding the microcode update for Ryzen? The last microcode update was Epyc only afaik...

No microcode has availlable for ryzen and TR now, latest is only for 800F12 (Epyc).
Flashed my B350 Tomahawk to latest 1.C4 beta bios (AGESA version: Raven PI 1.1.0.1), I saw the same microcode and always Spectre variante 1 vulnerable..

grep microcode /proc/cpuinfo                    
microcode       : 0x8001129


grep . /sys/devices/system/cpu/vulnerabilities/*
/sys/devices/system/cpu/vulnerabilities/meltdown:Not affected
/sys/devices/system/cpu/vulnerabilities/spectre_v1:Vulnerable
/sys/devices/system/cpu/vulnerabilities/spectre_v2:Mitigation: Full AMD retpoline

Spectre and Meltdown mitigation detection tool v0.33+

Checking for vulnerabilities on current system
Kernel is Linux 4.14.15-vanilla #1 SMP Wed Jan 24 22:00:42 CET 2018 x86_64
CPU is AMD Ryzen 7 1700X Eight-Core Processor

Hardware check
* Hardware support (CPU microcode) for mitigation techniques
 * Indirect Branch Restricted Speculation (IBRS)
   * SPEC_CTRL MSR is available:  NO  
   * CPU indicates IBRS capability:  NO  
 * Indirect Branch Prediction Barrier (IBPB)
   * PRED_CMD MSR is available:  NO  
   * CPU indicates IBPB capability:  NO  
 * Single Thread Indirect Branch Predictors (STIBP)
   * SPEC_CTRL MSR is available:  NO  
   * CPU indicates STIBP capability:  NO  
 * Enhanced IBRS (IBRS_ALL)
   * CPU indicates ARCH_CAPABILITIES MSR availability:  NO  
   * ARCH_CAPABILITIES MSR advertises IBRS_ALL capability:  NO  
 * CPU explicitly indicates not being vulnerable to Meltdown (RDCL_NO):  NO  
 * CPU microcode is known to cause stability problems:  NO  
* CPU vulnerability to the three speculative execution attacks variants
 * Vulnerable to Variant 1:  YES  
 * Vulnerable to Variant 2:  YES  
 * Vulnerable to Variant 3:  NO  

CVE-2017-5753 [bounds check bypass] aka 'Spectre Variant 1'
* Mitigated according to the /sys interface:  NO  (kernel confirms your system is vulnerable)
> STATUS:  VULNERABLE  (Vulnerable)

CVE-2017-5715 [branch target injection] aka 'Spectre Variant 2'
* Mitigated according to the /sys interface:  YES  (kernel confirms that the mitigation is active)
* Mitigation 1
 * Kernel is compiled with IBRS/IBPB support:  NO  
 * Currently enabled features
   * IBRS enabled for Kernel space:  NO  
   * IBRS enabled for User space:  NO  
   * IBPB enabled:  NO  
* Mitigation 2
 * Kernel compiled with retpoline option:  YES  
 * Kernel compiled with a retpoline-aware compiler:  YES  (kernel reports full retpoline compilation)
 * Retpoline enabled:  YES  
> STATUS:  NOT VULNERABLE  (Mitigation: Full AMD retpoline)

CVE-2017-5754 [rogue data cache load] aka 'Meltdown' aka 'Variant 3'
* Mitigated according to the /sys interface:  YES  (kernel confirms that your CPU is unaffected)
* Kernel supports Page Table Isolation (PTI):  YES  
* PTI enabled and active:  NO  
* Running as a Xen PV DomU:  NO  
> STATUS:  NOT VULNERABLE  (your CPU vendor reported your CPU model as not vulnerable)

A false sense of security is worse than no security at all, see --disclaimer

[starshipeleven]

What is Family 4 / 5 of the Intel Atom? Given Avoton is relatively new, that probably still has the issue.

https://en.wikipedia.org/wiki/Intel_Atom
It probably means Pineview and Cedarview Atoms.

Cedarview being the total bullshit "we didn't totally suck on CPU but we have PowerVR GPU and since IT is notoriously a bag of dicks we won't even have 64bit GPU drivers for windows, go figure how well the GPU runs in Linux". I remember the flaming Intel got for that screwup.

Pineview were the first gen of Atoms that were somehow usable (with Linux anyway), at least back then, and also support a 64bit OS even if their memory controller can only use 2GB of ram total.

But yeah, that's still Atoms from 2010. Modern smartphones run better than that.

[pal666]

What is Family 4 / 5 of the Intel Atom? Given Avoton is relatively new, that probably still has the issue.

age does not matter. if it can't do speculative execution, it can't have bugs in speculative execution

[soulsource]

Does anyone actually have an overview regarding Spectre mitigation techniques? I'm curious about the performance impact of both, retpoline or the microcode based approach, and also how bad the performance impact of the microcode based approach is on different CPUs (given that Ryzen for instance should not need IBRS afaik).

Also: Any news regarding the microcode update for Ryzen? The last microcode update was Epyc only afaik...