4 ms·

As others have already said, if you're a programmer, please just read the original papers: https://meltdownattack.com/meltdown.pdf https://meltdownattack.com/m

As others have already said, if you're a programmer, please just read the original papers: https://meltdownattack.com/meltdown.pdf https://meltdownattack.com/meltdown.pdf (start with this one) https://spectreattack.com/spectre.pdf https://spectreattack.com/spectre.pdf They are extremely well written, clear and to the point. Understanding them will take you less time than trying to get rid of all the tortured analogies and unnecessary simplifications people have been trying to make up over the past week. It's bad enough that we face the daunting task of explaining this stuff to people who don't care about computers, there's no need to perpetuate misunderstanding among those who deal with computers for a living. Just read the real thing. And on the subject of explaining this to others, it might surprise you how far you can get if you try to honestly explain how the attacks work. I refuse to use the silly train station metaphors, so I tried to describe the basic idea of how speculative execution works in out of order CPUs to my parents (who can browse the Internet, with some effort, and were patient enough to listen to me for 10 minutes or so). I don't think I got the notion of return-oriented programming across very well, but the basic idea of Meltdown and side channel timing attacks in general is actually very easy to convey on the basis of a reasonably simplified picture of a CPU - you need the explain the basic role of cache memory, virtual vs physical addressing, the TLB and the basic notion of branch prediction. That's all you need to understand the principle of how the attacks work, if not the details of the implementation.

taeric 9y ago
Don't be too quick to dismiss metaphor based explanations. You'd probably be surprised how many developers need the metaphor. Similarly, many folks explaining this are likely doing so as much to increase their understanding as anything else. If there are problems in their explanation, help make it clearer. None of this is to say that folks should skip the originals. But it is also not helpful to constantly send folks back to them.
- scott_s 9y ago
  The problem is that some of the metaphor based explanations are wrong, and are decreasing understanding. When the originals are clearer than the attempted simplifications, then I do think it's helpful to send people to them.
  - taeric 9y ago
    They are clearer to you. They are obviously not clear to everyone. As evidence I give you people that read the originals and form incorrect metaphors. :) That is, these folks are building these metaphors as their attempt to understand the issues. If they simply silently kept them to themselves, you wouldn't even know they needed them corrected. Be clear on this point, people think in these metaphors whether they are read to them or not. That you did not is a trait of you. Not a universal. So, please correct them. And keep encouraging folks to go to the originals. But expect that not everyone can read them as clearly as you can. And use the evidence of the poor metaphors to confirm that. :)
    - scott_s 9y ago
      That is fair, but what we're left with are many more wrong explanations, and many of these wrong explanations are not more complicated than the correct one. And my complaint is not just the wrong metaphors, but the wrong technical explanations (such as, unfortunately, the submitted one, which I explain in another comment on this thread).
      - taeric 9y ago
        Agreed that that is problematic. I'm asserting that it is just visibly problematic. That is, without people making these posts, it is likely many people were still reaching these viewpoints. Having the update at the post that says to read the original is vital. Getting more of the "peer review" mentality in all posts is also key, provided that people don't treat their posts as immutable and actually correct things that are in need of correcting.
        scott_s 9y ago
        I understand your points, I'm just skeptical it means we end up with less total confusion. Particularly since I don't think most of the confused texts will be corrected, lying in wait to confuse others.
- keldaris 9y ago
  If I see a programmer saying he/she tried to read the original papers, but couldn't understand this and that, I'll do my best to help them. I don't have a problem with people using metaphors to explain specific points, but I do think people who replace trying to work through the originals with repeating a lazy metaphor or two from the popular press are doing themselves and others a huge disservice. This isn't something unattainably complicated that you need years of education (on top of a typical CS education or its self-taught equivalent) to understand. I think it's worth pointing out to people that they shouldn't be afraid of reading the original material. And frankly, I've found many of the popular metaphors harder to understand than the papers.
  - taeric 9y ago
    As I am trying to say in the sibling post, though. Metaphors aren't necessarily lazy. It is quite literally how many people think through these problems. Easily put, your best to help them may be to get common footing using one of these "lazy metaphors." And again, I'm just cautioning if you are offhandedly dismissing metaphor. Tone can be lost in forums, obviously, so don't think I am "correcting" you. I do not intend it that way.
    - keldaris 9y ago
      As a physicist, I'm quite used to having to resort to metaphors to convey some ideas to a non-technical audience. If a non-physicist asks me to explain AdS/CFT correspondence, I'm not going to be able to explain precisely why the correspondence requires the particular geometry of an anti-de Sitter space to work in a few minutes because the mathematical background required is just too deep. So I don't think metaphor-based explanations are necessarily bad, but I do think they are overused. It's one thing to use a metaphor to convey some essential property of a complex idea to non-experts. It's quite another to see domain experts argue about the (often non-trivial) details of strained metaphors far beyond their area of applicability. Without demeaning the usefulness of metaphors, I'm essentially trying arguing that: 1) domain experts should be far more cognizant of the limitations of the metaphors they employ and 2) domain experts should at the very least try to read the original material before perpetuating solely metaphor-based explanations.
bcantrill 9y ago
Amen -- and thank you. Of these, the Meltdown paper is especially well-written. One of my laments of this whole fracas is that Spectre has drowned out Meltdown to a degree (and not without good reason). But Meltdown is in fact the much more egregious of the two: it represents an indisputable flaw in Intel's architecture; the system software work to workaround it is gnarly (and, depending on implementation choices made, potentially rife with serious performance side-effects); and exploits are readily available. This is not to minimize Spectre which is serious and difficult to mitigate, but rather to counter some of the implicit minimization of Meltdown. Point is: keldaris is exactly right; please do read these papers -- and read them in the order of Meltdown before Spectre. If you completely understand the Meltdown paper, the Spectre paper will be much more accessible.
- keldaris 9y ago
  I agree with the point that it's advisable to start with the Meltdown paper, and have amended my post accordingly. That flaw is much more concise in its essence and much of the context is shared, so it's an easier read.
croddin 9y ago
I have a question: the attacks were apparently found by the authors of these papers and project zero very close to each other. Why is it that a bug that has existed so long was suddenly found by both groups so close to each other? Are there other papers or ideas that this is based on, or was there some other reason they both tried to look for these kinds of bugs?
- aviv 9y ago
  Putting my tinfoil hat for a minute, I suspect that it was well known and in use by various 3-letter agencies for years, and somehow they got wind of a foreign nation either exploiting this as well or about to expose it publicly. Their only move was to let a respectable entity like Google "discover" it.
- als0 9y ago
  It could be the case that one group found out about the other's work and decided to pursue a similar research direction with the hope of being first to publish.
- keldaris 9y ago
  Side channel timing attacks have been an active research topic for many years. I'm not a member of that community and I'm sure there are many people on HN who are far better placed to explain the context than I am, but from what I've seen the momentum around practical side channel exploits has been building up for over a year now, there's been a number of public talks on the subject at conferences and consequently several research groups were motivated to pursue similar lines of research at roughly the same time. It's also a fairly tight knit community and I'm sure they exchange information informally as well. I know you asked for specific citations, but I'd rather let someone who actually works in this area respond. I've read a few of the earlier articles on these subjects, but I'm not qualified to detail the full context surrounding the earlier research.
- tptacek 9y ago
  This happens all the time. In this particular case, speculative execution timing attacks were "in the air" for the last year. A little while ago the C.W. was that Anders Fogh had kicked this off with his blog post from last summer, but Fogh actually posted a chronology taking this work all the way back to December '16: https://cyber.wtf/2018/01/05/behind-the-scene-of-a-bug-collision/ https://cyber.wtf/2018/01/05/behind-the-scene-of-a-bug-colli... Once there's blood in the water, people race to find exploitable flaws (that's the goal of the game), and so it's not surprising that you'd get multiple teams disclosing, especially with something this egregious. Also: there's a Nyquist Frequency thing happening here: remember that we're dealing with months-long embargoes. So there's a lot of time for people to have found these bugs "separately", and all we're really seeing is a colliding disclosure. But having said all that: straight-up collisions happen a lot. We all have favorite stories. My favorite is when Vitaly McLain (then at Matasano, now one of my partners at Latacora) found an nginx bug that was identical to Heartbleed, 2 years before Heartbleed was disclosed. A fantastic bug. We were on a client engagement, so we had to coordinate with the client before reporting it upstream, and in the one hour it took to do that, someone else reported the same bug.
okreallywtf 9y ago
I used to like reading papers but its been quite some time since I gave myself the dedicated time to do this. I only allow myself 5 minutes on any topic before I'm off to something else. Someone posted the links to the papers and after looking at the intro I realized I had everything I needed to understand the meltdown paper (and it seems, spectre) from my grad architecture class (shoutout to tomasulo!). Sitting down in the evening and reading through the meltdown was such a nice change of pace from my normal routine. I took notes and wrote down questions about parts that didn't make sense, and when I got to the end I found it so much more rewarding than reading some pop tech synopsis. I don't mean this in a superior way or that I'm special because I understood the paper, it was more about stretching my CS legs in a way I don't on a daily basis as a developer. I might have less of an understanding about the real world implications until I look at the impacts, but people around me have been talking about it (at work, etc) and I realized they all had a pretty limited understanding of the vulnerability and how it worked (not because they aren't smart, they just didn't have time to read the actual paper and are more focused on how this affects us at work). I want to make this a part of my normal routine, every week or so to pick an interesting, well written paper on a meaningful CS topic and have a leisurely, scholarly read like I used to do in school (well, in school there wasn't too much leisure to it).
bogomipz 9y ago
>" It's bad enough that we face the daunting task of explaining this stuff to people who don't care about computers, there's no need to perpetuate misunderstanding among those who deal with computers for a living. Just read the real thing." How did the author of the blog post perpetuate a misunderstanding? What is wrong with reading multiple sources and discussions on an a subject? Isn't that what we are doing here to some extent? Because a definitive white paper was published this should be our only allowed source of understanding? Its quite possible that someone could read this and then the more lengthy white paper and have them be complimentary. Not every programmer starts with the same level level or hardware and microarchitectural knowledge. >"And on the subject of explaining this to others, it might surprise you how far you can get if you try to honestly explain how the attacks work." Isn't this exactly what the author of this article did? In seeking to understand the problem hey formulated their understanding into a blog post. It seems to me that's exactly what they did and there were no "tortured analogies" in this individuals blog post.
- scott_s 9y ago
  > How did the author of the blog post perpetuate a misunderstanding? By misunderstanding the fundamentals of how Meltdown works - specifically, by confusing out-of-order execution with speculative execution, and then basing their explanation on that misunderstanding. My further explanation elsewhere in this thread: https://news.ycombinator.com/item?id=16133668 https://news.ycombinator.com/item?id=16133668

taeric 9y ago

Don't be too quick to dismiss metaphor based explanations. You'd probably be surprised how many developers need the metaphor. Similarly, many folks explaining this are likely doing so as much to increase their understanding as anything else. If there are problems in their explanation, help make it clearer. None of this is to say that folks should skip the originals. But it is also not helpful to constantly send folks back to them.

scott_s 9y ago
The problem is that some of the metaphor based explanations are wrong, and are decreasing understanding. When the originals are clearer than the attempted simplifications, then I do think it's helpful to send people to them.
- taeric 9y ago
  They are clearer to you. They are obviously not clear to everyone. As evidence I give you people that read the originals and form incorrect metaphors. :) That is, these folks are building these metaphors as their attempt to understand the issues. If they simply silently kept them to themselves, you wouldn't even know they needed them corrected. Be clear on this point, people think in these metaphors whether they are read to them or not. That you did not is a trait of you. Not a universal. So, please correct them. And keep encouraging folks to go to the originals. But expect that not everyone can read them as clearly as you can. And use the evidence of the poor metaphors to confirm that. :)
  - scott_s 9y ago
    That is fair, but what we're left with are many more wrong explanations, and many of these wrong explanations are not more complicated than the correct one. And my complaint is not just the wrong metaphors, but the wrong technical explanations (such as, unfortunately, the submitted one, which I explain in another comment on this thread).
    - taeric 9y ago
      Agreed that that is problematic. I'm asserting that it is just visibly problematic. That is, without people making these posts, it is likely many people were still reaching these viewpoints. Having the update at the post that says to read the original is vital. Getting more of the "peer review" mentality in all posts is also key, provided that people don't treat their posts as immutable and actually correct things that are in need of correcting.
      - scott_s 9y ago
        I understand your points, I'm just skeptical it means we end up with less total confusion. Particularly since I don't think most of the confused texts will be corrected, lying in wait to confuse others.
keldaris 9y ago
If I see a programmer saying he/she tried to read the original papers, but couldn't understand this and that, I'll do my best to help them. I don't have a problem with people using metaphors to explain specific points, but I do think people who replace trying to work through the originals with repeating a lazy metaphor or two from the popular press are doing themselves and others a huge disservice. This isn't something unattainably complicated that you need years of education (on top of a typical CS education or its self-taught equivalent) to understand. I think it's worth pointing out to people that they shouldn't be afraid of reading the original material. And frankly, I've found many of the popular metaphors harder to understand than the papers.
- taeric 9y ago
  As I am trying to say in the sibling post, though. Metaphors aren't necessarily lazy. It is quite literally how many people think through these problems. Easily put, your best to help them may be to get common footing using one of these "lazy metaphors." And again, I'm just cautioning if you are offhandedly dismissing metaphor. Tone can be lost in forums, obviously, so don't think I am "correcting" you. I do not intend it that way.
  - keldaris 9y ago
    As a physicist, I'm quite used to having to resort to metaphors to convey some ideas to a non-technical audience. If a non-physicist asks me to explain AdS/CFT correspondence, I'm not going to be able to explain precisely why the correspondence requires the particular geometry of an anti-de Sitter space to work in a few minutes because the mathematical background required is just too deep. So I don't think metaphor-based explanations are necessarily bad, but I do think they are overused. It's one thing to use a metaphor to convey some essential property of a complex idea to non-experts. It's quite another to see domain experts argue about the (often non-trivial) details of strained metaphors far beyond their area of applicability. Without demeaning the usefulness of metaphors, I'm essentially trying arguing that: 1) domain experts should be far more cognizant of the limitations of the metaphors they employ and 2) domain experts should at the very least try to read the original material before perpetuating solely metaphor-based explanations.

bcantrill 9y ago

Amen -- and thank you. Of these, the Meltdown paper is especially well-written. One of my laments of this whole fracas is that Spectre has drowned out Meltdown to a degree (and not without good reason). But Meltdown is in fact the much more egregious of the two: it represents an indisputable flaw in Intel's architecture; the system software work to workaround it is gnarly (and, depending on implementation choices made, potentially rife with serious performance side-effects); and exploits are readily available. This is not to minimize Spectre which is serious and difficult to mitigate, but rather to counter some of the implicit minimization of Meltdown. Point is: keldaris is exactly right; please do read these papers -- and read them in the order of Meltdown before Spectre. If you completely understand the Meltdown paper, the Spectre paper will be much more accessible.

keldaris 9y ago
I agree with the point that it's advisable to start with the Meltdown paper, and have amended my post accordingly. That flaw is much more concise in its essence and much of the context is shared, so it's an easier read.

croddin 9y ago

I have a question: the attacks were apparently found by the authors of these papers and project zero very close to each other. Why is it that a bug that has existed so long was suddenly found by both groups so close to each other? Are there other papers or ideas that this is based on, or was there some other reason they both tried to look for these kinds of bugs?

aviv 9y ago
Putting my tinfoil hat for a minute, I suspect that it was well known and in use by various 3-letter agencies for years, and somehow they got wind of a foreign nation either exploiting this as well or about to expose it publicly. Their only move was to let a respectable entity like Google "discover" it.
als0 9y ago
It could be the case that one group found out about the other's work and decided to pursue a similar research direction with the hope of being first to publish.
keldaris 9y ago
Side channel timing attacks have been an active research topic for many years. I'm not a member of that community and I'm sure there are many people on HN who are far better placed to explain the context than I am, but from what I've seen the momentum around practical side channel exploits has been building up for over a year now, there's been a number of public talks on the subject at conferences and consequently several research groups were motivated to pursue similar lines of research at roughly the same time. It's also a fairly tight knit community and I'm sure they exchange information informally as well. I know you asked for specific citations, but I'd rather let someone who actually works in this area respond. I've read a few of the earlier articles on these subjects, but I'm not qualified to detail the full context surrounding the earlier research.
tptacek 9y ago
This happens all the time. In this particular case, speculative execution timing attacks were "in the air" for the last year. A little while ago the C.W. was that Anders Fogh had kicked this off with his blog post from last summer, but Fogh actually posted a chronology taking this work all the way back to December '16: https://cyber.wtf/2018/01/05/behind-the-scene-of-a-bug-collision/ https://cyber.wtf/2018/01/05/behind-the-scene-of-a-bug-colli... Once there's blood in the water, people race to find exploitable flaws (that's the goal of the game), and so it's not surprising that you'd get multiple teams disclosing, especially with something this egregious. Also: there's a Nyquist Frequency thing happening here: remember that we're dealing with months-long embargoes. So there's a lot of time for people to have found these bugs "separately", and all we're really seeing is a colliding disclosure. But having said all that: straight-up collisions happen a lot. We all have favorite stories. My favorite is when Vitaly McLain (then at Matasano, now one of my partners at Latacora) found an nginx bug that was identical to Heartbleed, 2 years before Heartbleed was disclosed. A fantastic bug. We were on a client engagement, so we had to coordinate with the client before reporting it upstream, and in the one hour it took to do that, someone else reported the same bug.

okreallywtf 9y ago

I used to like reading papers but its been quite some time since I gave myself the dedicated time to do this. I only allow myself 5 minutes on any topic before I'm off to something else. Someone posted the links to the papers and after looking at the intro I realized I had everything I needed to understand the meltdown paper (and it seems, spectre) from my grad architecture class (shoutout to tomasulo!). Sitting down in the evening and reading through the meltdown was such a nice change of pace from my normal routine. I took notes and wrote down questions about parts that didn't make sense, and when I got to the end I found it so much more rewarding than reading some pop tech synopsis. I don't mean this in a superior way or that I'm special because I understood the paper, it was more about stretching my CS legs in a way I don't on a daily basis as a developer. I might have less of an understanding about the real world implications until I look at the impacts, but people around me have been talking about it (at work, etc) and I realized they all had a pretty limited understanding of the vulnerability and how it worked (not because they aren't smart, they just didn't have time to read the actual paper and are more focused on how this affects us at work). I want to make this a part of my normal routine, every week or so to pick an interesting, well written paper on a meaningful CS topic and have a leisurely, scholarly read like I used to do in school (well, in school there wasn't too much leisure to it).

bogomipz 9y ago

>" It's bad enough that we face the daunting task of explaining this stuff to people who don't care about computers, there's no need to perpetuate misunderstanding among those who deal with computers for a living. Just read the real thing." How did the author of the blog post perpetuate a misunderstanding? What is wrong with reading multiple sources and discussions on an a subject? Isn't that what we are doing here to some extent? Because a definitive white paper was published this should be our only allowed source of understanding? Its quite possible that someone could read this and then the more lengthy white paper and have them be complimentary. Not every programmer starts with the same level level or hardware and microarchitectural knowledge. >"And on the subject of explaining this to others, it might surprise you how far you can get if you try to honestly explain how the attacks work." Isn't this exactly what the author of this article did? In seeking to understand the problem hey formulated their understanding into a blog post. It seems to me that's exactly what they did and there were no "tortured analogies" in this individuals blog post.

scott_s 9y ago
> How did the author of the blog post perpetuate a misunderstanding? By misunderstanding the fundamentals of how Meltdown works - specifically, by confusing out-of-order execution with speculative execution, and then basing their explanation on that misunderstanding. My further explanation elsewhere in this thread: https://news.ycombinator.com/item?id=16133668 https://news.ycombinator.com/item?id=16133668