Hacker News Reader

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.

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.

>" 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.

> 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

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).

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.

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.

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.

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.

I don't really disagree with your two points. It is the rhetoric of "resort to metaphors" that rings a bell to me.

I agree the shared metaphors of notation and common jargon should be preferred as a starting point. I just don't have faith that they are the clear way out of misunderstanding. More, I think it is unrealistic to think this is something that should only be done with "outsiders". Rather, I think we are all using some common language, and shaking up to new language can shake out misunderstandings that were simply not being voiced.

Off topic, but can you recommend any resources for getting into the subject of AdS/CFT correspondence? I’m loosely familiar with it, but I’d love more depth. Thanks for any links or hints!

Since you asked for more depth, I'll focus on the (comparatively easier) task of giving some links to technical literature. First of all, if you already have a traditional QFT background, there's the two extremes of either just taking a simple toy example to play with [1] or a fairly rigorous well written lecture course [2]. For a more general physics/math background I'd recommend a slightly more pedagogical treatment [3], but it's still accurate to the subject matter and therefore contains graduate level mathematics. There's a lot more out there, but these are just some of the descriptions I've personally skimmed and found them to be well written and useful.

On the other end of the scale, there's a huge amount of popular documentaries out there that purport to say something about AdS/CFT. Most of them either contain nonsense or don't say very much at all. I don't really know how useful the popular analogies really are, but in the spirit of making at least one recommendation that doesn't contain any math, Susskind's public lectures are easy to watch (here's one [4]), and Susskind is careful not to talk nonsense.

There isn't really much on AdS/CFT that's in between graduate level mathematics and math-less popular stuff. The reason is that it's a fairly irreducible concept in the sense that you really need to understand what an anti-de Sitter space is and how conformal field theories work to see why there's a mathematical correspondence between them, and this isn't truly analogous to anything simpler. That's why it's very hard to explain beyond the level of vague metaphors without being rigorous about it.

[1] https://arxiv.org/pdf/hep-th/0403110.pdf

[2] https://arxiv.org/pdf/hep-th/0201253.pdf

[3] https://arxiv.org/pdf/1310.4319.pdf

[4] https://www.youtube.com/watch?v=2DIl3Hfh9tY

This is precisely what I was hoping for, and I just cannot thank you enough for taking the time to do this. I really appreciate you giving me a full range of resources too.

Glad I could help! AdS/CFT is a very elegant idea in modern physics, I hope you enjoy studying it.

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.

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. :)

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).

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.

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.

Yeah, a cornerstone of my assertion has to be that references to original works are present and that documents are updated on errors found. Two things that I grant are not always the case.

I don't feel this is much different from any other pedagogical practice, though. How many of us come at "imaginary" numbers with a given metaphor that severely fails us in some understandings?

My primary concern is not actually bad metaphors, but out-and-out wrong explanations (such as this one).

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?

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-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.

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.

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.

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.