3 ms·

Should I hold off on buying a computer until this spectre and meltdown issues are fixed?

by crimsonalucard 9y ago

bhouston 9y ago
That will take a year no?
- jerf 9y ago
  A year would be a fairly aggressive timeline. Ultimately SPECTRE et al are just exemplars of a class of exploit that I'm not sure anybody has seriously thought about how to deal with systematically. I've done the "daydream off for five minutes and try to solve the problem" a couple of times and I generally get to "let's design a new CPU from the ground up, using an entirely new set of formalisms"[1] pretty quickly, which is, ah, let's say, not a one-year effort to get it into customer hands. Timing attacks suck. [1]: By this I mean that in general, our formal systems dump time as a consideration as quickly as they can. The systems designing the CPUs themselves don't, of course, because time is a big deal in making a modern CPU work at all, but otherwise, we dump it as a consideration as quickly as we can, for lots of reasons, like not overspecifying a system and overconstraining it, and because it's really, really hard to keep track of time, and generally doesn't bring value commensurate with that complexity. Having built our stack of software and formalisms without very much thought about tracking time precisely, we generally only once at the very end recapture some time information, when we care, via O() analysis, and generally via the use of a whole crapton of explicitly-approximated values, which for what we care about is almost always good enough.... until timing attacks. Timing attacks suck. I think we're just barely beginning to come to grips with how much they suck.
  - mort96 9y ago
    My day dream for fixing Spectre is as follows: Basically double the amount of L1 cache (where the second half doesn't need to be as fast as actual L1 cache), make only the first half usable as cache. When an instruction the CPU speculatively executes an instruction which would replace the content in its L1 cache, first copy the existing content to the second, usually unused, half, and _then_ replace the content of the first half with the new data. Then, if the CPU decides that the branch was correct, just do nothing; if the CPU decides that the branch was incorrect, just copy back the "backup" of the original cache. Copying the cache to and from the "backup" would obviously have to be done really quickly with dedicated hardware, and not be done by going through each byte and copying it, but that should be possible. Another solution I've thought of, which should probably be easier and/or cheaper: When speculatively executing an instruction, just don't write to cache at all. This would potentially make the speculatively executed instructions slower, but I can't imagine it would have a big effect. Of course, both of those solutions would just mitigate this specific attack. You're probably exactly correct that timing attacks are going to continue to be a big problem.
ihsw2 9y ago
Get an AMD, there will be many new models coming out soon.
mort96 9y ago
Meltdown, ...maybe. I personally doubt it will be fixed in Coffee Lake, as that's probably too far along the pipeline for such big silicon changes in my (unprofessional) opinion. I would therefore assume that Meltdown won't be fixed before Cannonlake, the generation after Coffe Lake. If you don't need a new computer for a while, it might be worth waiting for Cannonlake and hope Meltdown gets fixed by then. This would let you avoid the performance hit from syscalls caused by the patches which fix Meltdown. It might also seem like just getting an AMD CPU instead of an Intel one would let you avoid the Meltdown performance hit, because AMD claims their CPU is not vulnerable to it, and the Meltdown paper says that they didn't get it to work with AMD CPUs, though the people behind the paper didn't seem to be 100% sure that there is no way to do a similar attack on AMD CPUs. Spectre is a different beast. I imagine that one will take significantly longer to fix; from what I understand, the issue is pretty fundamental to branch prediction and speculative execution, which is a big reason why CPUs are fast. Also, since that issue applies to everyone and not just Intel, I imagine Intel will be less focused on fixing it since there's less bad PR directed specifically at Intel for that. I personally wouldn't expect it to be fixed within some years. I'd love if someone more knowledgable about CPU design would correct me if I'm wrong or clarify something.

Should I hold off on buying a computer until this spectre and meltdown issues are fixed?

bhouston 9y ago

That will take a year no?

jerf 9y ago
A year would be a fairly aggressive timeline. Ultimately SPECTRE et al are just exemplars of a class of exploit that I'm not sure anybody has seriously thought about how to deal with systematically. I've done the "daydream off for five minutes and try to solve the problem" a couple of times and I generally get to "let's design a new CPU from the ground up, using an entirely new set of formalisms"[1] pretty quickly, which is, ah, let's say, not a one-year effort to get it into customer hands. Timing attacks suck. [1]: By this I mean that in general, our formal systems dump time as a consideration as quickly as they can. The systems designing the CPUs themselves don't, of course, because time is a big deal in making a modern CPU work at all, but otherwise, we dump it as a consideration as quickly as we can, for lots of reasons, like not overspecifying a system and overconstraining it, and because it's really, really hard to keep track of time, and generally doesn't bring value commensurate with that complexity. Having built our stack of software and formalisms without very much thought about tracking time precisely, we generally only once at the very end recapture some time information, when we care, via O() analysis, and generally via the use of a whole crapton of explicitly-approximated values, which for what we care about is almost always good enough.... until timing attacks. Timing attacks suck. I think we're just barely beginning to come to grips with how much they suck.
- mort96 9y ago
  My day dream for fixing Spectre is as follows: Basically double the amount of L1 cache (where the second half doesn't need to be as fast as actual L1 cache), make only the first half usable as cache. When an instruction the CPU speculatively executes an instruction which would replace the content in its L1 cache, first copy the existing content to the second, usually unused, half, and _then_ replace the content of the first half with the new data. Then, if the CPU decides that the branch was correct, just do nothing; if the CPU decides that the branch was incorrect, just copy back the "backup" of the original cache. Copying the cache to and from the "backup" would obviously have to be done really quickly with dedicated hardware, and not be done by going through each byte and copying it, but that should be possible. Another solution I've thought of, which should probably be easier and/or cheaper: When speculatively executing an instruction, just don't write to cache at all. This would potentially make the speculatively executed instructions slower, but I can't imagine it would have a big effect. Of course, both of those solutions would just mitigate this specific attack. You're probably exactly correct that timing attacks are going to continue to be a big problem.

ihsw2 9y ago

Get an AMD, there will be many new models coming out soon.

mort96 9y ago

Meltdown, ...maybe. I personally doubt it will be fixed in Coffee Lake, as that's probably too far along the pipeline for such big silicon changes in my (unprofessional) opinion. I would therefore assume that Meltdown won't be fixed before Cannonlake, the generation after Coffe Lake. If you don't need a new computer for a while, it might be worth waiting for Cannonlake and hope Meltdown gets fixed by then. This would let you avoid the performance hit from syscalls caused by the patches which fix Meltdown. It might also seem like just getting an AMD CPU instead of an Intel one would let you avoid the Meltdown performance hit, because AMD claims their CPU is not vulnerable to it, and the Meltdown paper says that they didn't get it to work with AMD CPUs, though the people behind the paper didn't seem to be 100% sure that there is no way to do a similar attack on AMD CPUs. Spectre is a different beast. I imagine that one will take significantly longer to fix; from what I understand, the issue is pretty fundamental to branch prediction and speculative execution, which is a big reason why CPUs are fast. Also, since that issue applies to everyone and not just Intel, I imagine Intel will be less focused on fixing it since there's less bad PR directed specifically at Intel for that. I personally wouldn't expect it to be fixed within some years. I'd love if someone more knowledgable about CPU design would correct me if I'm wrong or clarify something.