3 ms·
Disclaimer: I work on software (Linux) at Intel. Spectre variant 1 is arguably a software problem. It's not about consuming "bad" data that was placed by an a
by hansendc 9y ago
Disclaimer: I work on software (Linux) at Intel.
Spectre variant 1 is arguably a software problem. It's not about consuming "bad" data that was placed by an adversary like variant 2, or allowing a rogue data cache loads like with Meltdown. It happens as the result of normal execution.
The processor manuals are also very clear that speculation can be wrong and can have observable side-effects[1][2]. The processors also have ways to constrain speculation architecturally (like lfence) in the case that speculation can do something that results in exposure to a vulnerability. Those two things put together make it a software problem _now_, and perhaps forever.
This means that those of us who write security-sensitive software have a long road ahead of us to learn how this affects us and to continue to enhance our defenses. Adding array_index_nospec()'s in Linux, for instance.
1. Intel SDM Vol 3a, 4.10.2.3 Details of TLB Use: "The processor may cache translations required ... for accesses that are a result of speculative execution that would never actually occur in the executed code path."
2. CLFLUSH instruction definition says: "processors are free to speculatively fetch and cache data from system memory regions assigned a memory-type allowing for speculative reads"
- modeless 9y agoThis is exactly my fear, that Intel and others will continue to go with the "working as designed" defense. The problem still exists. The design is bad, and users will pay the price with slower software, or less secure software, until the design is fixed.
- wilun 9y agoDisclaimer; I don't work at Intel, nor in any other processor design house, nor in a fab, etc. And honestly, look at what is variant 1, before spreading uninformed opinion. It is fundamental to speculative execution. You can have some form of hardware support, and actually both Intel, AMD, ARM, and probably others, have begun some work on the subject, but it is in the form of instructions that can be added or replaced in the software at the right spot, because there is absolutely no way to have a speculative enough HW enforce security for variant 1 without some software help: it is not an architectural or a microarchitectural problem; it is a fundamental logic problem... My opinion is that we need extensible tagging in programing languages quickly, for that, and other subjects.
- modeless 9y agoI understand variant 1, and I do not share your pessimism. It is not fundamental to speculative execution as a concept, only current implementations. Speculative execution in modern processors already requires performing heroic feats to enforce correctness in the face of mispredicted branches. Fixing Spectre variant 1 requires more heroic feats of a similar kind (rolling back state changes), and I don't think it is fundamentally impossible given what has already been done. It won't be easy, and it won't be free, but it needs doing. Nobody thought it was worth doing until now, so nobody tried, but that doesn't indicate that it's impossible.