News Intel details Spectre, Meltdown protection in its latest CPUs

Read more

 

I'm not sure if you guys skimmed the article and missed the key points, or I just did a really bad job of writing it: Intel has already fixed some of the vulnerabilities in-silicon. Just not all of them.

Which, incidentally, is how you fix things in hardware: you fix the stuff you know is vulnerable, and if you're really lucky the same fixes will prevent or at least mitigate future vulnerabilities based on the same attack vector. (Like how disabling HyperThreading immediately protects you against a whole bunch of run-your-attack-thread-on-the-same-physical-core-as-your-target-thread vulnerabilities, even the ones we don't know about yet.)

 

Yes and no: the performance is already sacrificed. There's no difference between "disable this part of the CPU in microcode" and "disable this part of the CPU when we build it," beyond the behaviour when the CPU is installed in a system that doesn't have updated microcode. There's little Intel can do to mitigate the performance impact, beyond coming up with new alternatives to replace the removed functionality which aren't (known to be) vulnerable - and that's a separate thing to fixing the security flaws themselves.

 

That's not even close to being true. You fix a hole in a boat by removing the hole, not by making the hole better. When your house is insecure because you keep your front-door key under the doormat, the fix is to stop keeping your front-door key under the doormat. Even if it means it now takes you longer to get in when you're drunk. That's not a workaround; that's the fix.

Intel isn't trying to make the L1 Terminal Fault vulnerability better; it's trying to remove it altogether so that you don't get pwned by 1337 Russian h4x0rz.

 

Technically speaking, that's what you're doing! It's like the famous smart-alec response to "what is the one thing you would take out of your house if it was on fire," as popularised by Pterry: "the fire."

 

...I think our metaphors just lost each other in the mist.

The current in-silicon fixes are fixes, for the vulnerabilities which they target. They are not patches, they are not workarounds, they are fixes: the vulnerabilities are gone. They will not be replaced with different fixes in the future, because they work by removing the vulnerability; to put in a different fix, you'd have to start by putting the vulnerability back in (cutting another hole in the boat, if you will.)

The other vulnerabilities have not been fixed in-silicon. They probably will be in the future, but that's not guaranteed. They, too, will be fixes, not patches or workarounds. They will almost certainly all work by disabling the functionality that turns out to have been a really bad idea to add in the first place, just as the currently-available fixes for the vulnerabilities do.

There's no other way.

Now, in the future Intel may come up with a processor feature which is functionally equivalent to the removed, vulnerable functionality to restore performance. That won't be a fix, though; that's a new feature, albeit one which replaces an older and since-removed feature.

 

They never will, either: but here they're being criticised for not fixing the problems they do know about, not for not fixing the ones they don't know about.