Discussion in 'Article Discussion' started by bit-tech, 9 Oct 2018.
I doubt there will be fixes in silico for at least another two years from Intel, unless they dump an entire architecture branch and live with breaking Tick/Tock.
...oh wait, they already did that...
I doubt there will be in silico from AMD in the same timeframe either, just to point out the obvious.
Somebody somewhere mentioned that people 'in da biz' estimate another 5 to 25 variants of Spectre to be lurking in the shadows. So how do you fix anything in hardware without knowing what it is you should fix?
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.)
OK, I should have clarified my point a little better. Some fixes are a start. But all fixes will take time as they need to come up with ways around the issue without sacrificing insane amounts of performance.
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.
A fix that fixes by just turning something off isn't a fix, it's a workaround, whether software or hardware. Some times things aren't "fixable", true, so some other method needs to be used - perhaps it will result in a permament performance loss. Whether that is by giving up and just living with the workaround, or finding some novel way to do something that maintains functionality without sacrificing something else... time will tell.
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.
I know what you mean here but the idea of taking away a hole made me chuckle
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."
Now we're talking about boats? OK. Well, you do "make the hole better" in that respect by... well, fixing it. In the short term by a patch, or longer term by a replacement of the relevant section. They've done the patch - that's the microcode mitigation which is a workaround to not sink without trace - the full fix is to replace the damaged part. Perhaps it's an oversimplification, but a full in silico fix for these vulnerabilities will require the Intel equivalent of drydock. For a full "fix" like that, you'd cut out or remove a much larger section around the damaged area and that it's really hard to do "in service" without sinking the thing.
Hence my lack of surprise about Intel not having fully fixed the vulnerability.
...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.
I know there are some hardware fixes already in place, but that wasn't my point. Maybe I should've been clearer: they have fixes for some variants of the vulnerabilities, but not all of them (yet). My point was that they don't even know yet what and how many future variants will be discovered.
Trying to keep my head above metaphors here.
What with their marketing BS i'm surprised they didn't try to sell any of this as a 'feature' that we should pay extra for.
* checks prices guesstimates *
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.
As they should. No way they should be allowed to gloss over the fact the whole story is just a connect-the-dots of failure.
Separate names with a comma.