Massive CPU Security Flaws Revealed


#402

If you read the article you will flip into the Berenstein Bears universe from the Berenstain Bears one.


#403

How long until engineers discover that a CPU can’t be designed and built that can’t also be hacked?


#404

As long as human beings create them.

One thing about modern CPUs is that they rely heavily on quantum mechanics, and if anyone told you they knew exactly how quantum mechanics worked they’re lying to your face.


#405

The combination of Meltdown and Spectre, and the Russian meddling in the 2016 election, mean I pretty much hate computers now.


#406

This was teased months ago, but that big bad spectre variant has finally been revealed.

OS patches have been issued.

The bad news is that Foreshadow attacks the L1 cache, and in cloud environments attackers could read the page tables of other VMs. The only way to fix this is to disable hyperthreading.


#407

It’s not really Spectre because it’s Intel only. The hyperthreading bit is really scary for the enterprise.


#408

The hits just keep on coming. This is separate from Spectre or Meltdown

Intel Statement:


#409

So i guess we really do need to run everything on iPads.


#410

Given the nature of this exploit it really aren’t a big deal unless you’re running VMs for third parties or working on shared infrastructure.

The moral to the story here is that SMT is insecure by design. That’s why OpenBSD no longer supports it.


#411

Google researchers say Spectre is not going away:


#412

It isn’t going away on existing hardware.


#413

How bad is any future hardware going to suck?


#414

It’s hard to … speculate


#415

They’ll address Spectre but don’t worry, a new flaw will come eventually complete with a new spiffy name.


#416

Addressing spectre without losing massive performance isn’t easy, it’s an entire class of attacks. It may not even be possible to fix it without giving up that performance, and we may see configurable “tolerance” for these vulnerabilities become a real mainstream thing.


#417

Easy, just fix the problem, take the performance hit and then make the next round that much faster ;). heh


#418

Well you were joking, but that probably is the answer. We’re coming to the end of the road with silicon, and will need to move to a compound semiconductor like gallium nitride to hop back on Moore’s law. And then by the time they tap out, the hope is that quantum computing can save us, which (and I actually don’t jest) leverages alternate universes to speed calculations.

All that stuff is possible, but really really expensive and hard to do, while silicon manufacturing is extremely mature and high yield today, so they’re trying to eke out as much performance as possible using “tricks” like symettric multiprocessing and speculative execution. Ultimately those tricks need to go away.


#419

On the client side, if this becomes a “thing”, we might see a move towards a safer net, less javascript, better ability to control what we’re running on the machine.

On the server, VM side. Good luck.


#420

That won’t happen. Software mitigations will be developed for each exploit, and they will move to hardware with new revisions.


#421

No.

|3> |4> |5>