17 ms·
Like many with a background in programming languages and their implementations, the idea that safe languages enforce a proper abstraction boundary, not allowing
by samth 7y ago
Like many with a background in programming languages and their implementations, the idea that safe languages enforce a proper abstraction boundary, not allowing well-typed programs to read arbitrary memory, has been a guarantee upon which our mental models have been built. It is a depressing conclusion that our models were wrong — this guarantee is not true on today’s hardware. Of course, we still believe that safe languages have great engineering benefits and will continue to be the basis for the future, but… on today’s hardware they leak a little.
We should all be more angry at chip makers for this. Intel isn't willing to admit that they broke things because then they'd have to fix it, but we shouldn't accept that kind of approach.
- TheSoftwareGuy 7y agoEverybody who studied even a little bit about processor hardware new about speculative execution. And it was never just intel that was using it, (they all were). Until Spectre that technology was not considered controversial. the crazy thing is that nobody saw this until recently.
- samth 7y ago"Until event X, doing <thing that X demonstrated was bad> was not considered controversial" is an explanation of behavior, but not really a defense.
- marcoperaza 7y agoNegligence, recklessness, knowledge, or purposefulness are probably the only way actions can be wrongful. To have acted negligently, you at least ought to have known that it carried an unacceptable risk. So you need a story on how it was at least negligent and why they ought to have known the risk before releasing the product.[0] Mere causation can’t get you there. E.g. when a car hits a pedestrian, the driver and pedestrian equally “caused” the accident. It is only by way of characterizing their behaviors in one of the ways above that we can identify wrongdoing. Perhaps the driver wasn’t paying attention (negligent or reckless) and ran a red light. Or perhaps the pedestrian was intentionally throwing themselves in front of traffic. Etc. [0] Products liability law on its surface does eschew the moral-wrongdoing requirement in favor of strict liability for some kinds of product defects. But that has to do with economic incentives, practical ability to prove claims, etc.
- rayiner 7y agoHere, chip makers never promised to prevent X. Maybe preventing X is desirable now that people do Y, but you can hardly blame them for not preventing something they didn’t promise to prevent.
- shawnz 7y agoThey promised to develop general purpose chips which can meet as many desktop computing needs as possible, which now implicitly includes need Y (but they didn't anticipate that at the time). They could of course just reject the necessity of need Y, but if the majority of their clients actually do have need Y, can it really be said that the chip is successful at being general purpose?
- rat9988 7y agoYeah you can. Because the chip provides capabilities so you can do such protections in software if you want, or get more speed if you don't want.
- orbital-decay 7y ago> the crazy thing is that nobody saw this until recently. Correct me if I'm wrong, but speculative execution attacks (or at least the possibility) were known for several years before Spectre.
- MiroF 7y agoYou're not wrong - side channel attacks have been around for forever
- gpderetta 7y agoNot all side channel attacks rely on speculation, although I think all known speculation attacks necessarily rely on side channels to exfiltrate information. I'm not an expert but I think that specifically attacking speculation was novel.
- mrfredward 7y agoFor anyone who hasn't come across it, here's a really interesting blog post about speculative execution and a cache bug in the Xbox360 (2018 post about stuff that happened in 2005): https://randomascii.wordpress.com/2018/01/07/finding-a-cpu-design-bug-in-the-xbox-360/ https://randomascii.wordpress.com/2018/01/07/finding-a-cpu-d...
- marcosdumay 7y agoYou say that like if Intel flaws were comparable to the ones from ARM and AMD. They aren't.
- kllrnohj 7y agoAnd this post isn't about those flaws, so that's irrelevant.
- gcb0 7y agothat's victim blaming. chip consumers missing a communication is very different from intel actively developing this to cut corners for raw performance (which is the only reason they cornered the market) and forcing all other manufacturers to follow up or die.
- jcranmer 7y agoSpeculative execution was developed by IBM in the 1960s, before Intel made CPUs.
- monocasa 7y agoTo be fair, untrusted code wasn't part of the security model for mainframes for the longest time.
- wglb 7y agoThis is one of the discoveries that you see then slap your forehead saying "Duh of course!"
- rayiner 7y agoChip makers never “broke” anything. Resistance to side channel attacks was never part of the protection model. Remember, these protection models were designed when if an attacker was running code in your address space things had already gone completely sideways. To the extent anyone is at fault, it’s the folks who designed browsers with in-process JS engines without realizing that they were assuming the hardware was providing protections that the hardware didn’t claim to provide.
- jnordwick 7y agoWhy do comments like this get rated down so quickly. The process boundary was supposed to be the level of protection. Preventing your own process from accessing itself was never part of the memory model.
- monocasa 7y agoChip manufacturers have known about JavaScript and it's implementations for decades. ARM for instance had gone so far as to make JS specific instructions (FJCVTZS, Floating-point Javascript Convert to Signed fixed-point, rounding toward Zero), and before that they had instructions to help a JIT (ThumbEE). Not sure why we're buying the chip companies' shtick of "oh, poor us, we never knew people would use our chips like that, we just specifically optimized for it and provided support instructions"
- rayiner 7y agoSo chip makers should have redesigned their hardware to match the erroneous assumptions JS vendors were making about how memory protection works?
- monocasa 7y agoThey should have provided mechanisms for multiple memory domains in the same process, so that people can use their chips securely to do the work the expect to do with them, yes.
- bitwize 7y agoChip makers favored speed over security to get a leg up in the megahertz wars. They may have even been aware of the risks, but at the time thought they were obscure and difficult to exploit. They made sound decisions at the time, which makes Meltdown and Spectre even scarier, because what sound compromises made since then will come back to bite us in the ass later? Sometimes I think that humanity is not ready for computers, and it's time to go full-on Butlerian jihad.
- tus87 7y agoIt's more depressing that some people think of programming as programming a language rather than a machine. Languages are just fluff that all reduce to the same thing when crunched through a compiler or interpreter.
- johncolanduoni 7y agoWriting your code in assembly wouldn’t have isolated you from any of these issues; in fact it would make deploying the kinds of mitigations mentioned in the article drastically more difficult. And even if you’re actively thinking about micro-architectural concerns, it is evident that these issues are not obvious, since it took a long time for anybody to put their finger on a concrete problem with speculative execution.