7 ms·

I'm disheartened by the number of comments here who are taking the stance that Intel has idiot designers or that management doesn't care about security. This a

I'm disheartened by the number of comments here who are taking the stance that Intel has idiot designers or that management doesn't care about security. This attack is very clever and unexpected. Even though side-channel attacks have been talked about for awhile, even the guy who developed Meltdown was surprised that it worked. It just seemed like an "in theory" security hole, not an exploitable one. AMD isn't vulnerable to Meltdown not because they foresaw this issue, but probably because they simply weren't as aggressive as Intel in allowing speculative execution. For years people have preferred Intel over AMD cpus due to their performance advantage, due in part to that higher sophistication of their pipeline. Or to recast it, nobody is hating on AMD right now, but AMD CPUs do allow a user process to learn some things about the kernel via timing attacks. If next month a researcher develops Meltdown2 for AMD, are AMDs designers now suddenly idiots for missing an obvious security hole?

mellow_ 9y ago
I mean... yes? Why would it be any different?
lawrenceyan 9y ago
AMD did things the right way competing for performance without sacrificing security. What's happening right now are the consequences of Intel's actions.
- chirau 9y ago
  I think you are missing the point. What the commenter is saying is this... right now you are saying AMD did things the right way, but if a loophole is exposed next month, will you say the same thing? I'm neither supporting or refuting the commenter. Just explaining to you the meaning of the comment.
- thecompilr 9y ago
  AMD did things the "right" way, not because they understood the security implication, but because it was very hard to achieve such high level of speculation, and I think the performance gains didn't justify the effort for them.
  - pas 9y ago
    How do you know this? I think it's worth noting that it's entirely possible, that if you are a CPU execution pipeline designer that you think about memory loads/stores, L1 cache, branch prediction and speculative execution, and it occurs to you that the cache gets polluted by spec exec, and the branches can be security checks. But the solution is simple. If the branch is important, wait for it. (Load it into L1 cache before the branch - use a memory barrier.) The fact that this is not in any ISA docs is a likely pointer toward the possibility that it in fact hadn't occurred to them. These attacks are the same as any new invention. Easy to see once you've grasped the concept.
  - pja 9y ago
    Have you got a reference for that statement? Because my interpretation of what has been said so far is that AMD deliberately chose not to allow speculative dependent loads that crossed privilege boundaries by enforcing permission checks on all reads whereas Intel chose to permit all loads & rely on the fixup at the retirement stage of the pipeline to enforce privilege boundaries. Happy to be proven wrong however.
    - thecompilr 9y ago
      I don't have hard evidence, but A) they are vulnerable to two out of the three attacks, which indicates they did not in fact consider speculative execution a danger B) it is hard to believe that if they researched the topic at AMD, they wouldn't find this vulnerability in Intel processors a long time ago
      - jacksmith21006 9y ago
        They did across priv boundaries which was the point.
      - pja 9y ago
        I note in passing that the AMD processor manual is explicit that all reads are checked against the privilege bit before being issued. It’s this protection that means that AMD processors are not subject to meltdown. All CPU manufacturers appear to have been caught on the hop by Spectre (branch prediction history side channels).
- willvarfar 9y ago
  If AMD spotted the issue and avoided it deliberately all those years ago, why didn't they tell anyone?
  - suryamp 9y ago
    Because they knew it was an obvious security risk?
  - lomnakkus 9y ago
    What are you even arguing here? If I observe fact X which is "bleeding obvious", then it's not my responsibility to tell the world about X. Of course this stuff isn't "bleeding obvious", but I'm going to assume that the AMD engineers thought that it was "obvious enough" to not explicitly to tell the world about it. Besides... do you have any idea what kind of NDAs those engineers are going to have to sign?
  - m_mueller 9y ago
    There is a difference between following good security practices (gratuitous isolation, defensive design) and having exploits ready to show the world how valuable it is. Noone was claiming AMD knew of such exploits beforehand.
  - abhorrence 9y ago
    Perhaps whoever thought about it assumed it was obvious enough that others would have realized it as well. It may simply have never occurred to them that it was worth sharing.
noncoml 9y ago
> I'm disheartened by the number of comments here who are taking the stance that Intel has idiot designers or that management doesn't care about security. I think you are being unfair as the GP didn't call anybody an idiot for not caring about security. It just calls them out for insisting that this is not a flaw or a bug.
- derefr 9y ago
  I think it makes sense in a really pedantic way: "flaw" and "bug" have always been, in my observed experience of usage, terms used to refer to the consequences of oversights. This wasn't an oversight; this was more like... whatever you call the fact that we're still, today, choosing to employ (and even design new!) hash functions that quantum computers could probably break easily. We're making an intentional design choice, based on the perceived difficulty and current infeasability of a particular known class of attack against that design. That current hashes are vulnerable if-and-when a quantum computer comes along to crack them isn't really a "bug" or a "flaw" in our hashing algorithms; it's a known property of our hashing algorithms. Or, for another analogy: there was a point in history when the peak of warfare was ships shooting guided missiles at other ships, and the targeted ships shooting smaller "countermissiles" that attempted to get in the way of the incoming missiles before they could hit anything important. Every missile had a faint heat signature, making it visible to infrared optics—this was an unavoidable consequence of the fact that missiles need engines to make them move. But for a long time, the idea of a heat-seeking countermissile was just infeasible or un-economical to implement, so little work was done to hide the emissions signatures of missiles. The emissions signature certainly wasn't a "bug"—it wasn't the result of an oversight; and it's a bit strange to call it a "flaw", insofar as there was no such thing as a missile that didn't have said "flaw" while still being a missile. It was a known property of the missile technology of the time. Or, if you want to think of it on a higher level, "missiles" themselves—anything that you might call a missile—had a categorical flaw. In the same way, anything we might call a modern-day CPU is now known to have the categorical flaw of leaking at least some amount of information through speculative execution. You can minimize it (like you can minimize a missile's heat signature), but you can't get rid of it without making something we wouldn't even call a CPU any more (most things without speculative execution are, these days, considered microcontrollers.) In that sense, I can understand Intel's insistence that they didn't make a flawed product: they made a perfectly good instance of a "computer processor"—it's just that "computer processors", as a category of product, have a problem. You wouldn't blame the missile manufacturer for making missiles with visible emissions signatures, before heat-seeking countermissiles were invented. They didn't introduce a flaw. They made their product to order, and the order—the requirements, the demands of the customer—themselves contained the flaw, contained the supposition that it was okay to make a particular trade-off because it wasn't currently exploitable. In the missile manufacturer's case, it was the government that said "sure, heat doesn't matter, just make it go fast"; and when heat-seeking countermissiles were invented, it was the government whose (lack of) intelligence foresight was to blame for not changing their requirements to anticipate that exploit. In Intel's case, some customer could have foreseen the exploit and shifted the market toward demanding non-speculative-execution CPUs. Intel was just making what the customers asked for, and right up until the end, they were asking for the categorically-flawed product.
deleted 9y ago
[deleted]
willtim 9y ago
I disagree. The attacks are clever to focus on Speculative evaluation but are otherwise fairly simple (timing attacks are well known). I'm surprised such attacks have not been discovered earlier, as speculative evaluation seems quite broken. Security is likely not a top priority for Intel and probably not something their verification teams are targeting. There is perhaps a gap in the market for a vendor focusing on secure CPUs.
- alphakappa 9y ago
  For an architecture that has been around for so long, if the attack was only discovered recently, then is it fair to call it 'simple'? In retrospect, anything can be obvious.
  - Nexxxeh 9y ago
    We don't know when it was discovered first though. We only know that it's been disclosed now.
    - halflings 9y ago
      From [1]: > We reported this issue to Intel, AMD and ARM on 2017-06-01. I don't think they have been twidling their thumbs with such a huge discovery without informing constructors. [1] https://googleprojectzero.blogspot.com/2018/01/reading-privileged-memory-with-side.html https://googleprojectzero.blogspot.com/2018/01/reading-privi...
      - bri3d 9y ago
        Right - but as always with a vulnerability, especially one that's borderline-undetectable through any kind of log analysis, the question becomes "were Google really the first to think of this?" and the tinfoil kingdom builds itself from there.
      - mort96 9y ago
        We know (or can guess) approximately when the project zero team discovered the issue, but I think your parent comment meant that we don't know when _someone_ discovered it first. Maybe the project zero team were the very first to discover it, or maybe some state actor discovered it a decade ago and has been using it since then.
anigbrowl 9y ago
AMD isn't vulnerable to Meltdown not because they foresaw this issue, but probably because they simply weren't as aggressive as Intel in allowing speculative execution What do you mean by 'aggressive' here? Cause frankly, I think aggression isn't a good trait to be exploiting in business - it's not the same as competitiveness. Is it 'they would have done this if they could but they didn't try hard enough', or is it 'they could have done this but didn't have the nerve to take the risk'? In the latter case, I'd argue that a lack of willingness to trade off security against performance is a Good Thing in line with engineering ethics. In the former case, it seems like you're assuming business comeptition is always construed as a zero-sum game - is this correct?
- JamesBarney 9y ago
  They weren't making a trade-off because it was not a known risk. No one had any reason to think that speculative jumps would lead to a large security hole.
  - anigbrowl 9y ago
    This seems to be subject to debate...
  - cookiecaper 9y ago
    My understanding is that it was a known risk, see the various citations already provided throughout this thread. Meltdown is a bugged design decision because it failed to consider the consequences of asynchronously verifying permission for speculative executions that reach into kernel space, which allows the Spectre attack to affect kernel memory too. That's the limitation of the reach of the "Intel bug" as far as I know, the rest is generally applicable. The Spectre attack is a side effect of performing speculative execution without wiping caches, something that was, until yesterday, an intentional and clearly-chosen industry design direction, standard across almost every commercial CPU produced in the last 20 years, despite the known risk of "theoretical" timing attacks. The only reason for Intel to make the decisions that led them to be vulnerable to Meltdown was to sacrifice correctness/safety for performance, and failing to consider the potential side effects of that sacrifice (cache heat). They obviously made a bad risk tradeoff there (though I don't necessarily fault them). AMD could definitely make the argument that Meltdown was an irresponsible "benchmark cheat" from Intel. EDIT: And let me further clarify, ARM was "cheating" and doing the permission check asynchronously on some models too (i.e., some of their chips are also vulnerable to Spectre in Kernel-space aka Meltdown). It's not solely an Intel issue.
chris_wot 9y ago
The poster you responded to never said that Intel engineers are idiots. Intel made a huge hole for themselves in the way they implemented ME. The reason for the strong reaction over these flaws is not because of the severity of this issue, nor does anyone believe Intel engineers are idiots. They are getting blowback because they implemented a closed solution for a powerful feature - Management Extensions. They lost a lot of trust, which makes it far harder to recover when new issues occur.
tptacek 9y ago
The researchers were surprised that it worked because it shouldn't have worked. I don't think Intel's engineers are incompetent, but be careful about the reasoning you're using.
netcraft 9y ago
meta comment - but when I first saw this comment it was in reply to carwyn's top level comment but now it is a top level comment unto itself? that makes a lot of the replies not make sense now - was this comment moved?
pishpash 9y ago
Did Intel promise in their docs that side channel attacks are not possible? If not, then OS writers are equally to blame for making incorrect assumptions. I don't think this is Intel's fault alone. On a grander note, there are probably hundreds of even more esoteric side channel attacks all across the system since every process changes the system state. This is more like the beginning of a new style of attacks now that one is shown to be practical, rather than any particular entity's fault. Hardware designers will need to consider informational and physical isolation in a more rigorous way, and there may be theoretical limits that bound the performance-security tradeoff when you share resources.
- mike_hearn 9y ago
  They do not. And more problematically for the "It's all Intel's fault" story, in the SGX documentation they explicitly state that their chips do not protect against side channel attacks and that it's up to the software developer to handle it. As SGX is a part of the CPU effectively that means their official chip docs rule out side channel protection as a feature. I don't know if playing the blame game here is going to be productive. All CPUs are vulnerable to side channel attacks of various kinds and focusing on Meltdown specifically seems like missing the forest for the trees - especially as ARM has the same issue in some of their designs.
rdtsc 9y ago
> AMD isn't vulnerable to Meltdown not because they foresaw this issue, but probably because they simply weren't as aggressive as Intel in allowing speculative execution. You don't see why being "aggressive" with speculatively loading data over a _protection boundary_ could be considered irresponsible? I for one, think AMD has the right to gloat if they want. It's not just AMD, besides the latest version of ARM it seems all the other CPU vendors decided to not be "aggressive" with their users' protected data (sparc, mips, amd, power, s390x). Does it mean all those vendors and architects had PoC for years for this and were sitting on it? No but they could have had a hunch not to go that route. Just like a sane developer might have a hunch over opening a wide API surface to a server that contains sensitive data. It doesn't mean they know there is security vulnerability in one of the API endpoints, it's just sane practice. > If next month a researcher develops Meltdown2 for AMD, are AMDs designers now suddenly idiots for missing an obvious security hole? But who called any developers idiots here? I think you were the only one.
- isatty 9y ago
  Such bullshit - there are loads of people, maybe not on SO, but on reddit etc that called them "idiot CPU developers", possibly misinterpreting what Linus said.
  - amazingman 9y ago
    Why not just chalk this up to Dunning-Kruger and then move on to some other, more interesting/productive use of attention?
  - rdtsc 9y ago
    Someone on the internet is mean, I have no doubt. I haven't seen a lot name-calling here. Let's stick to HN and let reddit deal with its own drama.
  - deleted 9y ago
    [deleted]
- im3w1l 9y ago
  Side channels are really hard to protect against. Caches, buffers (maybe you can check when they are full), branch prediction, sound, vibrations, timing, electricity consumption, em waves, temperature. Things leak all over the place.
tanilama 9y ago
Intel grabs tens of billions revenue year after year, people of course expect the best of the best from them. Playing victim here doesn't work when u r an industry leader. U can not have the cake and eat it.
goalieca 9y ago
Well the first problem is obvious with hindsight. Consider all the state changes that occur when an instruction is speculatively executed. Are any of these rolled back? In this case, the cache is not being rolled back. Neither (presumably) is the branch predictor. And then what of the performance counters? (do they count if an instruction is not retired?). I see many potential attack vectors opening up and it's much harder to prove that any of these state changes can't be exploited.
3pt14159 9y ago
The problem is that there are a lot of us trying to get people to take these "completely unlikely" attack vectors seriously. It's like talking to a dog or a wall. Too many humans are hardwired to respond only when confronted with an actual situation. We get frustrated because our "in theory it works..." attacks work in reality eventually and then the rest of the world is all "oh who could have predicted that ____". We did. We, the people you called "paranoid" while we quietly try to fix things. We're the ones trying to make sure that people don't die when cyber vulnerabilities are exploited by shitty actors.
- jacques_chester 9y ago
  I've encountered this, with great unhappiness. I have a theory that this heavily relates to the feedback loops and signals in play. New features are positively observable and their impact is observable from release onwards. When defending against unknown unknowns, security is unobservable. It's observable only in its absence. All that's left are heuristics and synthetic signals like pentesting. I wrote a multi-thousand word essay on the topic, but for an internal audience. I don't know if I could properly share it.
  - erkkie 9y ago
    Please do share if you can, I've been thinking a lot about this topic in context of ops / "janitorial" work in general.
  - FullyFunctional 9y ago
    Yes, that's exactly right and why it's hard to sell "security" and how we get to an voluminous x86 ISA. My own speculation is that we got here in this industry though a complete absence of liability. Bugs are not a big deal, they are _expected_ now. The only counter example I know of is Knuth's bug reward system.
dis-sys 9y ago
Latest AMD processors are on par with INTEL in terms of IPC performance, there is no evidence showing AMD's pipeline design is anything less smart than Intel's. AMD processors do not have the issue because they don't speculatively load data across the defined boundary. It is _NOT_ an "in theory" security hole, it is a security hole that managed to lower the computing performance of the entire world due to Intel's market share. Intel designers should of course be blamed for such issues - full price paying customers are now suffering from performance penalises for up to 30% on some workload, when each new generation of Intel processors give you 5-10% performance boost in the last 5-10 years. Sure, the issue is a surprise for everyone, but if they are designing processors to power billions of devices, they are expected and required to be exceptional. Let's make it perfect clear - Intel designers don't have to be smarter, they can give up their market share to AMD. It is a privilege to design chips for the entire world, it is not a right. When things go wrong, they need to admit the mistakes and fix their craps, sadly Intel is putting too much efforts into its PR rubbish ATM.
wilun 9y ago
Meltdown could have been avoided by following what is in CPU design text books about speculative execution. Spectre is clever. Meltdown, as known today, is (mainly) an Intel major fuck-up.

mellow_ 9y ago

I mean... yes? Why would it be any different?

lawrenceyan 9y ago

AMD did things the right way competing for performance without sacrificing security. What's happening right now are the consequences of Intel's actions.

chirau 9y ago
I think you are missing the point. What the commenter is saying is this... right now you are saying AMD did things the right way, but if a loophole is exposed next month, will you say the same thing? I'm neither supporting or refuting the commenter. Just explaining to you the meaning of the comment.
thecompilr 9y ago
AMD did things the "right" way, not because they understood the security implication, but because it was very hard to achieve such high level of speculation, and I think the performance gains didn't justify the effort for them.
- pas 9y ago
  How do you know this? I think it's worth noting that it's entirely possible, that if you are a CPU execution pipeline designer that you think about memory loads/stores, L1 cache, branch prediction and speculative execution, and it occurs to you that the cache gets polluted by spec exec, and the branches can be security checks. But the solution is simple. If the branch is important, wait for it. (Load it into L1 cache before the branch - use a memory barrier.) The fact that this is not in any ISA docs is a likely pointer toward the possibility that it in fact hadn't occurred to them. These attacks are the same as any new invention. Easy to see once you've grasped the concept.
- pja 9y ago
  Have you got a reference for that statement? Because my interpretation of what has been said so far is that AMD deliberately chose not to allow speculative dependent loads that crossed privilege boundaries by enforcing permission checks on all reads whereas Intel chose to permit all loads & rely on the fixup at the retirement stage of the pipeline to enforce privilege boundaries. Happy to be proven wrong however.
  - thecompilr 9y ago
    I don't have hard evidence, but A) they are vulnerable to two out of the three attacks, which indicates they did not in fact consider speculative execution a danger B) it is hard to believe that if they researched the topic at AMD, they wouldn't find this vulnerability in Intel processors a long time ago
    - jacksmith21006 9y ago
      They did across priv boundaries which was the point.
    - pja 9y ago
      I note in passing that the AMD processor manual is explicit that all reads are checked against the privilege bit before being issued. It’s this protection that means that AMD processors are not subject to meltdown. All CPU manufacturers appear to have been caught on the hop by Spectre (branch prediction history side channels).
willvarfar 9y ago
If AMD spotted the issue and avoided it deliberately all those years ago, why didn't they tell anyone?
- suryamp 9y ago
  Because they knew it was an obvious security risk?
- lomnakkus 9y ago
  What are you even arguing here? If I observe fact X which is "bleeding obvious", then it's not my responsibility to tell the world about X. Of course this stuff isn't "bleeding obvious", but I'm going to assume that the AMD engineers thought that it was "obvious enough" to not explicitly to tell the world about it. Besides... do you have any idea what kind of NDAs those engineers are going to have to sign?
- m_mueller 9y ago
  There is a difference between following good security practices (gratuitous isolation, defensive design) and having exploits ready to show the world how valuable it is. Noone was claiming AMD knew of such exploits beforehand.
- abhorrence 9y ago
  Perhaps whoever thought about it assumed it was obvious enough that others would have realized it as well. It may simply have never occurred to them that it was worth sharing.

noncoml 9y ago

> I'm disheartened by the number of comments here who are taking the stance that Intel has idiot designers or that management doesn't care about security. I think you are being unfair as the GP didn't call anybody an idiot for not caring about security. It just calls them out for insisting that this is not a flaw or a bug.

derefr 9y ago
I think it makes sense in a really pedantic way: "flaw" and "bug" have always been, in my observed experience of usage, terms used to refer to the consequences of oversights. This wasn't an oversight; this was more like... whatever you call the fact that we're still, today, choosing to employ (and even design new!) hash functions that quantum computers could probably break easily. We're making an intentional design choice, based on the perceived difficulty and current infeasability of a particular known class of attack against that design. That current hashes are vulnerable if-and-when a quantum computer comes along to crack them isn't really a "bug" or a "flaw" in our hashing algorithms; it's a known property of our hashing algorithms. Or, for another analogy: there was a point in history when the peak of warfare was ships shooting guided missiles at other ships, and the targeted ships shooting smaller "countermissiles" that attempted to get in the way of the incoming missiles before they could hit anything important. Every missile had a faint heat signature, making it visible to infrared optics—this was an unavoidable consequence of the fact that missiles need engines to make them move. But for a long time, the idea of a heat-seeking countermissile was just infeasible or un-economical to implement, so little work was done to hide the emissions signatures of missiles. The emissions signature certainly wasn't a "bug"—it wasn't the result of an oversight; and it's a bit strange to call it a "flaw", insofar as there was no such thing as a missile that didn't have said "flaw" while still being a missile. It was a known property of the missile technology of the time. Or, if you want to think of it on a higher level, "missiles" themselves—anything that you might call a missile—had a categorical flaw. In the same way, anything we might call a modern-day CPU is now known to have the categorical flaw of leaking at least some amount of information through speculative execution. You can minimize it (like you can minimize a missile's heat signature), but you can't get rid of it without making something we wouldn't even call a CPU any more (most things without speculative execution are, these days, considered microcontrollers.) In that sense, I can understand Intel's insistence that they didn't make a flawed product: they made a perfectly good instance of a "computer processor"—it's just that "computer processors", as a category of product, have a problem. You wouldn't blame the missile manufacturer for making missiles with visible emissions signatures, before heat-seeking countermissiles were invented. They didn't introduce a flaw. They made their product to order, and the order—the requirements, the demands of the customer—themselves contained the flaw, contained the supposition that it was okay to make a particular trade-off because it wasn't currently exploitable. In the missile manufacturer's case, it was the government that said "sure, heat doesn't matter, just make it go fast"; and when heat-seeking countermissiles were invented, it was the government whose (lack of) intelligence foresight was to blame for not changing their requirements to anticipate that exploit. In Intel's case, some customer could have foreseen the exploit and shifted the market toward demanding non-speculative-execution CPUs. Intel was just making what the customers asked for, and right up until the end, they were asking for the categorically-flawed product.

deleted 9y ago

[deleted]

willtim 9y ago

I disagree. The attacks are clever to focus on Speculative evaluation but are otherwise fairly simple (timing attacks are well known). I'm surprised such attacks have not been discovered earlier, as speculative evaluation seems quite broken. Security is likely not a top priority for Intel and probably not something their verification teams are targeting. There is perhaps a gap in the market for a vendor focusing on secure CPUs.

alphakappa 9y ago
For an architecture that has been around for so long, if the attack was only discovered recently, then is it fair to call it 'simple'? In retrospect, anything can be obvious.
- Nexxxeh 9y ago
  We don't know when it was discovered first though. We only know that it's been disclosed now.
  - halflings 9y ago
    From [1]: > We reported this issue to Intel, AMD and ARM on 2017-06-01. I don't think they have been twidling their thumbs with such a huge discovery without informing constructors. [1] https://googleprojectzero.blogspot.com/2018/01/reading-privileged-memory-with-side.html https://googleprojectzero.blogspot.com/2018/01/reading-privi...
    - bri3d 9y ago
      Right - but as always with a vulnerability, especially one that's borderline-undetectable through any kind of log analysis, the question becomes "were Google really the first to think of this?" and the tinfoil kingdom builds itself from there.
    - mort96 9y ago
      We know (or can guess) approximately when the project zero team discovered the issue, but I think your parent comment meant that we don't know when _someone_ discovered it first. Maybe the project zero team were the very first to discover it, or maybe some state actor discovered it a decade ago and has been using it since then.

anigbrowl 9y ago

AMD isn't vulnerable to Meltdown not because they foresaw this issue, but probably because they simply weren't as aggressive as Intel in allowing speculative execution What do you mean by 'aggressive' here? Cause frankly, I think aggression isn't a good trait to be exploiting in business - it's not the same as competitiveness. Is it 'they would have done this if they could but they didn't try hard enough', or is it 'they could have done this but didn't have the nerve to take the risk'? In the latter case, I'd argue that a lack of willingness to trade off security against performance is a Good Thing in line with engineering ethics. In the former case, it seems like you're assuming business comeptition is always construed as a zero-sum game - is this correct?

JamesBarney 9y ago
They weren't making a trade-off because it was not a known risk. No one had any reason to think that speculative jumps would lead to a large security hole.
- anigbrowl 9y ago
  This seems to be subject to debate...
- cookiecaper 9y ago
  My understanding is that it was a known risk, see the various citations already provided throughout this thread. Meltdown is a bugged design decision because it failed to consider the consequences of asynchronously verifying permission for speculative executions that reach into kernel space, which allows the Spectre attack to affect kernel memory too. That's the limitation of the reach of the "Intel bug" as far as I know, the rest is generally applicable. The Spectre attack is a side effect of performing speculative execution without wiping caches, something that was, until yesterday, an intentional and clearly-chosen industry design direction, standard across almost every commercial CPU produced in the last 20 years, despite the known risk of "theoretical" timing attacks. The only reason for Intel to make the decisions that led them to be vulnerable to Meltdown was to sacrifice correctness/safety for performance, and failing to consider the potential side effects of that sacrifice (cache heat). They obviously made a bad risk tradeoff there (though I don't necessarily fault them). AMD could definitely make the argument that Meltdown was an irresponsible "benchmark cheat" from Intel. EDIT: And let me further clarify, ARM was "cheating" and doing the permission check asynchronously on some models too (i.e., some of their chips are also vulnerable to Spectre in Kernel-space aka Meltdown). It's not solely an Intel issue.

chris_wot 9y ago

The poster you responded to never said that Intel engineers are idiots. Intel made a huge hole for themselves in the way they implemented ME. The reason for the strong reaction over these flaws is not because of the severity of this issue, nor does anyone believe Intel engineers are idiots. They are getting blowback because they implemented a closed solution for a powerful feature - Management Extensions. They lost a lot of trust, which makes it far harder to recover when new issues occur.

tptacek 9y ago

The researchers were surprised that it worked because it shouldn't have worked. I don't think Intel's engineers are incompetent, but be careful about the reasoning you're using.

netcraft 9y ago

meta comment - but when I first saw this comment it was in reply to carwyn's top level comment but now it is a top level comment unto itself? that makes a lot of the replies not make sense now - was this comment moved?

pishpash 9y ago

Did Intel promise in their docs that side channel attacks are not possible? If not, then OS writers are equally to blame for making incorrect assumptions. I don't think this is Intel's fault alone. On a grander note, there are probably hundreds of even more esoteric side channel attacks all across the system since every process changes the system state. This is more like the beginning of a new style of attacks now that one is shown to be practical, rather than any particular entity's fault. Hardware designers will need to consider informational and physical isolation in a more rigorous way, and there may be theoretical limits that bound the performance-security tradeoff when you share resources.

mike_hearn 9y ago
They do not. And more problematically for the "It's all Intel's fault" story, in the SGX documentation they explicitly state that their chips do not protect against side channel attacks and that it's up to the software developer to handle it. As SGX is a part of the CPU effectively that means their official chip docs rule out side channel protection as a feature. I don't know if playing the blame game here is going to be productive. All CPUs are vulnerable to side channel attacks of various kinds and focusing on Meltdown specifically seems like missing the forest for the trees - especially as ARM has the same issue in some of their designs.

rdtsc 9y ago

> AMD isn't vulnerable to Meltdown not because they foresaw this issue, but probably because they simply weren't as aggressive as Intel in allowing speculative execution. You don't see why being "aggressive" with speculatively loading data over a _protection boundary_ could be considered irresponsible? I for one, think AMD has the right to gloat if they want. It's not just AMD, besides the latest version of ARM it seems all the other CPU vendors decided to not be "aggressive" with their users' protected data (sparc, mips, amd, power, s390x). Does it mean all those vendors and architects had PoC for years for this and were sitting on it? No but they could have had a hunch not to go that route. Just like a sane developer might have a hunch over opening a wide API surface to a server that contains sensitive data. It doesn't mean they know there is security vulnerability in one of the API endpoints, it's just sane practice. > If next month a researcher develops Meltdown2 for AMD, are AMDs designers now suddenly idiots for missing an obvious security hole? But who called any developers idiots here? I think you were the only one.

isatty 9y ago
Such bullshit - there are loads of people, maybe not on SO, but on reddit etc that called them "idiot CPU developers", possibly misinterpreting what Linus said.
- amazingman 9y ago
  Why not just chalk this up to Dunning-Kruger and then move on to some other, more interesting/productive use of attention?
- rdtsc 9y ago
  Someone on the internet is mean, I have no doubt. I haven't seen a lot name-calling here. Let's stick to HN and let reddit deal with its own drama.
- deleted 9y ago
  [deleted]
im3w1l 9y ago
Side channels are really hard to protect against. Caches, buffers (maybe you can check when they are full), branch prediction, sound, vibrations, timing, electricity consumption, em waves, temperature. Things leak all over the place.

tanilama 9y ago

Intel grabs tens of billions revenue year after year, people of course expect the best of the best from them. Playing victim here doesn't work when u r an industry leader. U can not have the cake and eat it.

goalieca 9y ago

Well the first problem is obvious with hindsight. Consider all the state changes that occur when an instruction is speculatively executed. Are any of these rolled back? In this case, the cache is not being rolled back. Neither (presumably) is the branch predictor. And then what of the performance counters? (do they count if an instruction is not retired?). I see many potential attack vectors opening up and it's much harder to prove that any of these state changes can't be exploited.

3pt14159 9y ago

The problem is that there are a lot of us trying to get people to take these "completely unlikely" attack vectors seriously. It's like talking to a dog or a wall. Too many humans are hardwired to respond only when confronted with an actual situation. We get frustrated because our "in theory it works..." attacks work in reality eventually and then the rest of the world is all "oh who could have predicted that ____". We did. We, the people you called "paranoid" while we quietly try to fix things. We're the ones trying to make sure that people don't die when cyber vulnerabilities are exploited by shitty actors.

jacques_chester 9y ago
I've encountered this, with great unhappiness. I have a theory that this heavily relates to the feedback loops and signals in play. New features are positively observable and their impact is observable from release onwards. When defending against unknown unknowns, security is unobservable. It's observable only in its absence. All that's left are heuristics and synthetic signals like pentesting. I wrote a multi-thousand word essay on the topic, but for an internal audience. I don't know if I could properly share it.
- erkkie 9y ago
  Please do share if you can, I've been thinking a lot about this topic in context of ops / "janitorial" work in general.
- FullyFunctional 9y ago
  Yes, that's exactly right and why it's hard to sell "security" and how we get to an voluminous x86 ISA. My own speculation is that we got here in this industry though a complete absence of liability. Bugs are not a big deal, they are _expected_ now. The only counter example I know of is Knuth's bug reward system.

dis-sys 9y ago

Latest AMD processors are on par with INTEL in terms of IPC performance, there is no evidence showing AMD's pipeline design is anything less smart than Intel's. AMD processors do not have the issue because they don't speculatively load data across the defined boundary. It is _NOT_ an "in theory" security hole, it is a security hole that managed to lower the computing performance of the entire world due to Intel's market share. Intel designers should of course be blamed for such issues - full price paying customers are now suffering from performance penalises for up to 30% on some workload, when each new generation of Intel processors give you 5-10% performance boost in the last 5-10 years. Sure, the issue is a surprise for everyone, but if they are designing processors to power billions of devices, they are expected and required to be exceptional. Let's make it perfect clear - Intel designers don't have to be smarter, they can give up their market share to AMD. It is a privilege to design chips for the entire world, it is not a right. When things go wrong, they need to admit the mistakes and fix their craps, sadly Intel is putting too much efforts into its PR rubbish ATM.

wilun 9y ago

Meltdown could have been avoided by following what is in CPU design text books about speculative execution. Spectre is clever. Meltdown, as known today, is (mainly) an Intel major fuck-up.