Spectre NG - ... "but wait, there's more"

Hardware CPU
, ,
61

They all work great and kick ass as long as you use a chiller for cooling.

2 Likes
62

Meltdown and Spectre comes from a time where security wasnt even thought about. was just something people didnt think about or even knew about it. The security field has advanced alot since then and we now know what is and isnt good.

They might have known about it but we will never know

You have to run it before the code is executed because reading memory is beyond slow in terms of CPU speed. You can execute hundreds of instructions by the time you get back the value you asked for. So it makes sense to just not waste away that time and continue working ahead while you wait for the memory to get back too you.

There is no hoping you back out of the state properly because you do back out of it properly. The problem lie in the fact that doing some things take longer than others and you can measure that to figure out what the cpu is doing.

There is even hardware that can do this to break stuff like AES though its on a much harder scale. Same type of attack but done in a different method. Spectre is time based while the AES one is powerdraw

1 Like
63

Oh really? Its from the mid-90s, and i was there. Security was thought about. That’s the same era or later that IPSEC was developed, kerberos was developed, etc.

Security was thought about because intel put multiple privilege levels into the processor.

Yes, that’s all well and good, but when a security exception is reached, speculative execution should stop rather than carry on down both paths and attempt to back out state. That’s the way AMD did it. Yes, it’s slower, but you don’t clobber CPU state and leave cache artifacts, which is what meltdown relies on to function.

I very much doubt AMD took the performance hit (by not doing what intel did) because they didn’t think about executing ahead beyond security boundaries.

1 Like
64

Is this the next generation of the “hot and loud” meme? I like it.

1 Like
65

Frankly the complexity of these attacks are so great that I can’t fault Intel for being vulnerable to them. I don’t know that I would have been able to foresee this when designing a processor, but I’m probably the wrong person to ask.

1 Like
66

See, i’m no CPU designer, but to me, executing things, even speculatively, prior to actually validating the permission to execute is a (IMHO) violation of basic security best practice (i.e., don’t permit/do anything unless you’re sure it is checked off as OK). Akin to setting up an open by default firewall and then blocking things you know to be dodgy.

To me, that’s just insane, and i can see why AMD did not go that way. I truly do not think it is a mistake or accident that AMD didn’t make that optimization vs. security call.

It’s an obvious speed optimization win, but the trade-off is risky and IMHO unacceptable. Obviously i have the benefit of hindsight, but IMHO when your job is to build a device that enforces security privileges, setting up speculative execution to ignore them should have been a pretty obvious risk.

Spectre is another story… but meltdown… man…

3 Likes
67

That is exactly what I was thinking.

There it is. Give it a couple hours and it should be everywhere.

1 Like
68

More. Affects Intel, ARM and most likely AMD too :

And this is still not the end of the line as far as I understand it.

Also Chrome is supposedly doing something against spectre. To please the gods you only have to update and let it feast even more on your RAM.

69

We have discovered a whole new class of exploits. Gonna be a few years before we manage to flesh it all out. This is just the beginning of what we are to see

70

Any idea if Chromium also has the “something” implemented in Chrome?

A “fun” tool to check if exploit mitigations are installed on your linux system: https://github.com/speed47/spectre-meltdown-checker

spectre-meltdown-checker output

$ sudo sh spectre-meltdown-checker.sh
Spectre and Meltdown mitigation detection tool v0.37+

Checking for vulnerabilities on current system
Kernel is Linux 4.17.3-200.fc28.x86_64 #1 SMP Tue Jun 26 14:17:07 UTC 2018 x86_64
CPU is AMD Ryzen 7 2700X 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
      • CPU indicates preferring IBRS always-on: NO
      • CPU indicates preferring IBRS over retpoline: NO
    • Indirect Branch Prediction Barrier (IBPB)
      • PRED_CMD MSR is available: YES
      • CPU indicates IBPB capability: YES (IBPB_SUPPORT feature bit)
    • Single Thread Indirect Branch Predictors (STIBP)
      • SPEC_CTRL MSR is available: NO
      • CPU indicates STIBP capability: NO
      • CPU indicates preferring STIBP always-on: NO
    • Speculative Store Bypass Disable (SSBD)
      • CPU indicates SSBD capability: YES (AMD non-architectural MSR)
    • CPU explicitly indicates not being vulnerable to Variant 4 (SSB_NO): NO
    • CPU microcode is known to cause stability problems: NO (model 0x8 family 0x17 stepping 0x2 ucode 0x8008206 cpuid 0x800f82)
  • CPU vulnerability to the speculative execution attack variants
    • Vulnerable to Variant 1: YES
    • Vulnerable to Variant 2: YES
    • Vulnerable to Variant 3: NO
    • Vulnerable to Variant 3a: NO
    • Vulnerable to Variant 4: YES

CVE-2017-5753 [bounds check bypass] aka ‘Spectre Variant 1’

  • Mitigated according to the /sys interface: YES (Mitigation: __user pointer sanitization)
  • Kernel has array_index_mask_nospec (x86): YES (1 occurrence(s) found of 64 bits array_index_mask_nospec())
  • Kernel has the Red Hat/Ubuntu patch: NO
  • Kernel has mask_nospec64 (arm): NO

STATUS: NOT VULNERABLE (Mitigation: __user pointer sanitization)

CVE-2017-5715 [branch target injection] aka ‘Spectre Variant 2’

  • Mitigated according to the /sys interface: YES (Mitigation: Full AMD retpoline, IBPB)
  • Mitigation 1
    • Kernel is compiled with IBRS support: YES
      • IBRS enabled and active: NO
    • Kernel is compiled with IBPB support: YES
      • IBPB enabled and active: YES
  • Mitigation 2
    • Kernel has branch predictor hardening (arm): NO
    • Kernel compiled with retpoline option: YES
      • Kernel compiled with a retpoline-aware compiler: YES (kernel reports full retpoline compilation)

STATUS: NOT VULNERABLE (Full retpoline + IBPB are mitigating the vulnerability)

CVE-2017-5754 [rogue data cache load] aka ‘Meltdown’ aka ‘Variant 3’

  • Mitigated according to the /sys interface: YES (Not affected)
  • Kernel supports Page Table Isolation (PTI): YES
    • PTI enabled and active: NO
    • Reduced performance impact of PTI: NO (PCID/INVPCID not supported, performance impact of PTI will be significant)
  • Running as a Xen PV DomU: NO

STATUS: NOT VULNERABLE (your CPU vendor reported your CPU model as not vulnerable)

CVE-2018-3640 [rogue system register read] aka ‘Variant 3a’

  • CPU microcode mitigates the vulnerability: YES

STATUS: NOT VULNERABLE (your CPU vendor reported your CPU model as not vulnerable)

CVE-2018-3639 [speculative store bypass] aka ‘Variant 4’

  • Mitigated according to the /sys interface: YES (Mitigation: Speculative Store Bypass disabled via prctl and seccomp)
  • Kernel supports speculation store bypass: YES (found in /proc/self/status)

STATUS: NOT VULNERABLE (Mitigation: Speculative Store Bypass disabled via prctl and seccomp)

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

3 Likes
71

V4 fixes seem to cost about 1-3% performance in Windows and 2-8% in Linux on Intel.
AMD sees no performance penalty.

1 Like
72

A 2-8% performance hit is huge on those chromebooks, as they have bottom of the barrel processors. But since it’s Gentoo based i guess at the end of the day chrome os users won’t notice a difference.

73

Maybe a little zombi thread here, but were “Ret2Spec” and “SpectreRSB” covered in this thread?