Intel x86 considered harmful – survey of attacks against x86 over last 10 years

I really could do without "considered harmful" titles. x86 has been one of the most influential technologies of all time and a clickbait title doesn't do it justice imo.

Should also be noted that the link mentions that the paper contains no new attacks - the title is misleading in this context with the new paper qualifier.

You should write a paper explaining your views. And title it "'Considered Harmful' Considered Harmful".

Neither of these are valid criticisms.

Yours first: it is a new paper. It was just released. It has an "October 2015" dateline. It isn't a variant of any previous paper she's released. It's also a very good paper.

Second: this isn't a blog post. It's not a news site. It's a research paper. She gave it a title that follows a trope in computer science paper titles. It's silly to call it "clickbait".

As someone who's had the misfortune of going toe-to-toe with Rutkowska over details of the X86 architecture, let me gently suggest that whether she knows what she's talking about and what she's trying to say [isn't] really a fight you want to pick.

> And title it "'Considered Harmful' Considered Harmful".

http://meyerweb.com/eric/comment/chech.html

[edit: clarified context]

So were PHP and goto statements.

How influential something is has nothing to do with how good it is.

This isn't an "essay", nor is it "axe grinding". It's one of the best current available surveys on X86 platform security.

Go to SCHOLAR.GOOGLE.COM and search for "* considered harmful". Most of what Meyer has to say about "considered harmful essays" don't apply to these papers.

I was merely referring to the 'And title it "'Considered Harmful' Considered Harmful".' part of the parent post.

goto is just a mnemonic for jmp. It's the primitive from which all higher level control flow is ultimately derived. It isn't harmful, and it's used a lot even in C.

My main problem is with the term x86 because the article conflates form-factor issues (people can spy on you with the microphone in your phone, even the old analog telephone or tablet or game controller, Amazon Echo,...) with x86 issues (some real problems with the architecture in general) and the ME issue which is an intel thing.

You're missing the reference - Dijkstra wrote a famous letter on GOTO in 1968 which was published as "Go To Statement Considered Harmful":

https://www.cs.utexas.edu/users/EWD/ewd02xx/EWD215.PDF

In context, it was a piece advocating against the use of GOTO to the exclusion of all other control structures (e.g, 'for' or 'while' loops, etc).

    > whether she knows what she's talking about and what 
    > she's trying to say is really a fight you want to pick

Did you mean to say: "ISN'T really a fight you want to pick"?

"Considered Harmful" is a signifies that the text will be forceful and opinionated. I have nothing against balance and thoroughness, but many authors confuse those qualities with mealy-mouthedness and passive-aggressiveness. When I see "Considered Harmful" I know that the text will have a conclusion that isn't basically "I see some pro's and con's but I don't know guys, maybe more research is needed?".

Yes, "Considered Harmful" articles may be a little tactless and imbalanced, but they are usually also concise, honest, informative and funny. Those qualities are important to me.

> and the ME issue which is an intel thing.

> But is the situation much different on AMD-based x86 platforms? It doesn’t seem so! The problems related to boot security seem to be similar to those we discussed in this paper. And it seems AMD has an equivalent of Intel ME also, just disguised as Platform Security Processor (PSP)

I appreciate you thinking I'm a buffoon who was born yesterday and hasn't heard of EWD215, but it appears your reading comprehension is, to be charitable, iffy.

wyager's statement, involving PHP (for which there is not a famous "considered harmful" essay to the best of my knowledge, though there is "A Fractal of Bad Design") and goto statements, was a rather clear implication that both constructs are innately harmful in an attempt to counter n0us' assertion that influential/popular technologies imply a high quality. There was nothing said about using goto statements in presence of structured programming, but merely goto as an intrinsic badness. This is a common belief cargo culted by a many naive commentators and XKCD readers who do not realize that all control flow is derived from goto, and moreover that even in some languages with structured control flow it is still useful, e.g. for resource cleanup and breaking out of nested loops.

>Be civil. Don't say things you wouldn't say in a face-to-face conversation. Avoid gratuitous negativity.

https://news.ycombinator.com/newsguidelines.html

The currently prefered clickbait title on HN would be "x86 is the new goto"

The PSP is still a processor with elevated privileges, but it doesn't seem to have the ability to drive the network interface.

But she's right insofar as that x86 vendors are either in on this (mostly to satisfy the DRM-hungry Hollywood connection - most of these features have "DRM" written all over them, not "user security") or irrelevant (Via still ships its 20 slow x86 CPU samples per year that nobody wants, probably to avoid losing their x86 license).

My statement was neither something I wouldn't say face-to-face, nor gratuitously negative.

The PHP bashing on this site is untenable. PHP has no intrinsic properties which stop a good programmer from writing elegant code for web applications. It's a tired discussion, I know, but the most you can say is that it's frequently abused. The oft cited "Spectacle of bad design" essay has been credibly rebutted point-by-point by other authors.

> [goto] is the primitive from which all higher level control flow is ultimately derived

I'm pretty sure you cannot implement conditional branches using unconditional branches as a building block. Unless you count indirect branches, which goto usually doesn't support.

That largely misses (Dijkstra's, originally) point. How control flow is implemented at a low level (e.g. jmp/lngjmp) is a completely separable from how it should be exposed in a language.

Wearing a c programmers' hat you may say "absolutely", a scheme programmers' hat, perhaps "no way". Horses for courses after all.

That's a more nuanced position than the one that is commonly understood, however. Though, you are always bound to your architectural model, so exploiting it more directly is not innately bad. Layers tend to be leaky.

Wearing a Scheme programmers' hat, call/cc isn't any less of a landmine.

I am genuinely curious: Can you not figure this out by the context alone (hint:misfortune)? Or are you going "big-game hunting on HN" and nitpicking tptacek's comment?

Not that I'd recommend it, but sure you can. Just allow modification of the code to include where you want to jump to. :)

Scarily enough, I think this used to actually be somewhat common place and is why many functions were not reentrant.

Isn't that more aptly stated as "implemented with" not "derived from"?

As far as academic articles go, "* considered harmful" is probably as vague and bombastic (read: clickbaity) as a title gets (perhaps after 'Ron was wrong, Whit is right'). Personally I'd prefer a more descriptive title, like 'A survey of weaknesses and attacks on the x86 platform'. But then again, I'm a boring kind of person.

When some insist to use C++/JavaScript/PHP/MySql/Mongo/etc (tools with bad design/complexity/bug-prone/etc flaws) with the excuse that is possible to use them "well" if only we are more "disciplined" and "pay attention"?

When bad tools are bad, discipline is not the answer. Is fix the tool, or get rid of them.

Why developers understand that if a end-user have a high-error rate in one program is a problem with the program but when that happend with a language/tool for developers... not think the same???

"Good programmer" is almost a keyword in this context as "someone with the experience with for workaround and avoid the pitfalls that a tool is giving to him, plus also do his job" when is better if "someone that can concentrate in do his job".

Of course, workaround the pitfalls of tools is unavoidable in a world where "worse is better" have win. But why persist on this?

Assuming a von Neumann or modified Harvard architecture where execution advances from an incremented program counter, I'd say derived from, though it may be that the former is more appropriate. It is certainly not universal, I do not make that claim.

I could even live with the title if the article discussed a certain _aspect_ of a programming language(like Optional in Java 8, etc) to signal a certain vibe of the argument.

But when used wrt a microprocessor/hardware platform, it feels really, really forced. Not the end of the world, but still...

$BROWSER_NAME is the new IE6.

It comes off as unpalatable, to say the least. You were assuming malice in the other poster and then went on a minor tirade without sufficient prompting.

Yes, while the utterance itself is general in nature, I object to (ab)using it outside of discussing software language features (as it was originally used).

It's hard to take seriously a statement about an article, where even the referenced title is wrong.

It's not nit picking - it shows how one didn't even took them time to read and understand the article; it's "fractal" of bad design, and it's named so for a specific reason.

The program counter doesn't typically appear in the programming languages that have (or don't have) goto. You're talking about implementation, but I think people typically criticize goto in terms of semantics (iirc, I can include Djikstra in that camp, but I never made a super-careful study of that paper).

It's a matter of scale. If you're trying to compute absurdly large numbers, you'd be a fool to use addition, even if it is fundamental to some other operation you want to use. Goto is problematic not because it can't be used effectively, but because it won't be. Because it doesn't encapsulate a powerful enough abstraction to make computers smarter or programs easier to write and understand.

If you have to write a goto, you can drop into assembly. Don't add it to your high-level language, because it doesn't add anything there, it just gets in the way.

"It's the primitive from which all higher level control flow is ultimately derived."

There are a billion alternative primitives from which you could derive all the same things. Goto is not special. And it is so primitive, it is not hard to write something else and have a compiler translate it. You shouldn't need goto anymore than you should need access to registers.

Really? I only see one of those, from 5 years ago:

https://hn.algolia.com/?query=%22the%20new%20goto%22&sort=by...

That wasn't what I was criticizing - I was criticizing the title on HN. It previously said (new paper). While that is true, in this context, it is actually a summary of existing information.

I was not criticizing the quality of information in the paper or article. I was criticizing the summary previously displayed on HN before it was changed, which suggests that someone agrees with me.

>PHP has no intrinsic properties which stop a good programmer from writing elegant code for web applications.

Nor does x86 assembly. What is your point?

I'm lost. This is a new paper. What's the argument?

It's a new paper that summarizes - the previous title was "Intel x86 considered harmful (new paper)". It is very easy to draw an inference that a new revelation to consider the Intel x86 is harmful has come from that title - that was my only problem. I enjoyed reading the article.

It was a narrow complaint about the title as submitted to HN - the current title "Intel x86 considered harmful – survey of attacks against x86 over last 10 years" is a lot more insightful as to the nature of the article, and less inflammatory (although I'd guess that it was unintentional).

"Considered harmful" is like a Betteridge-baiting headline. It is important to remember that in the original article, "GO TO considered harmful", Dijkstra a) didn't choose the title; and b) was wrong about GO TO; it is tremendously useful under the right circumstances with no real substitute (except maybe for TCO). Yet how many times is "don't use goto" cited as an iron rule of programming?

So when I see "considered harmful" I've got my eye open for a potential thought-stopper, whether deliberately created or not.

It's called a survey paper. In this case, the survey is particularly valuable, because the stuff in it was scattered across blog posts and conference presentations --- many of them by the author of the survey.

Just not a great critique going on in this subthread.

I think you're completely missing the point...the original title on HN did not have any of that information - it just said "Intel x86 considered harmful (new paper)". No context that it was a survey paper - initial impressions was that it was just another clickbait inflammatory article link.

The moderators rightfully changed it, which makes my criticism addressed & outdated.

Actually, if you start with good measurements, many clear reasons appear that PHP is a terrible language. A nice write-up is here:

http://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/

It's amazing how much has been done in what was essentially a pile of hacks on top of a pre-processor making it pretend to be an application language. That pro's avoid it and its wiser users almost always leave it eventually further corroborates the author that it's fundamentally bad. If anything, it's one option among better ones (Python, Ruby) for non-programmers to get started in web apps. Little reason to use it at this point with all the 3rd party components and communities around better languages.

> Of course, workaround the pitfalls of tools is unavoidable in a world where "worse is better" have win. But why persist on this?

Because the unstated alternative is a false choice. It would be nice if all of the code written in poorly designed languages would disappear and be replaced with code in better designed languages, but that isn't realistic. Migrating a large codebase to a different language is very expensive and introduces fresh bugs, less popular languages aren't supported by all platforms and libraries, and large numbers of people have made significant time investments in learning languages that are popular even if they aren't very good. So the old languages aren't going away.

Given that, it's better that we teach people the pitfalls of the things we're stuck with, and improve them with things like std::unique_ptr in C++ or safer SQL APIs that discourage manual parsing of SQL statements, than to pretend that there is no middle ground between continuing the tradition of bad code and the fantasy of rewriting essentially all existing code from scratch overnight.

Yeah, short term is the right thing. But I'm talking about why stay in the same loop DECADES? Because the pile of mud is bigger with each iteration. Eventually, I think, the cost of a clean start will be far less that push ahead.

I don't underestimate the problem (I work in the LESS progressive area of programming: Internal Business apps / apps for non-startups, non-sexy-games-chat-scalable-apps!) so I'm full aware...

But what drive me crazy is that is developers that defend their tools as "them are good! why bother!", not because them use the business/cost defense...

So, yeah... let's not rewrite everything that is working right now. But also, a lot of time we can choose what to use, special for new projects... at least pick well next time...

> Yeah, short term is the right thing. But I'm talking about why stay in the same loop DECADES? Because the pile of mud is bigger with each iteration. Eventually, I think, the cost of a clean start will be far less that push ahead.

The pile of mud has network effects. Even when you're starting from scratch, you're not really starting from scratch. The world is built around the things that are popular. Everything is better supported and better tested for those things. If you create a new language, it not only needs to be better, it needs to be so much better that it can overcome the advantages of incumbency. Which is made even harder when the advantageous characteristics of new languages also get bolted onto existing languages in a way that isn't optimal but is generally good enough that the difference ends up smaller than the incumbency advantage.

Which is why change happens very, very slowly. We're lucky to be essentially past the transition from Fortran and COBOL to C, Java and C++.

The comment being replied to was also rather uncivil by a certain definition, assuming the commenter was unfamiliar with what is by now very cliched literature and explaining it in a somewhat condescending tone, as if to a child, when in truth there was a very substantive point being made.

I meant generic X is the new Y; "goto" was just a nod to Dijkstra's.

In other words, "is the new goto" is the new "considered harmful"?

I don't think it's a nice write up, in fact it arguably miscalculates every point it makes. It's exactly the article I was referring to in my original comment as having been thoroughly refuted, in (correct) anticipation that someone would bring it up, since it seems to be the only go-to source for PHP bashers.

That's a troll comment if I've ever seen one with even less information than what was in the linked article. Your comment actually has no information: a mere dismissal.

On opposite end, my link was at least clear on attributes of a good language. These were specifically mentioned: predictable, consistent, concise, reliable, debuggable. The author gave specific examples showing PHP lacks these traits. An analysis of Python or Ruby show them to embody these traits much more while also possessing the supposed advantages PHP fans tell me including easy learning, many libraries, huge community, tools, etc. So, the evidence indicates PHP is a poorly designed language (or not designed at all) while some competitors are well-designed languages with most of same benefits.

Other authors say about the same about both philosophy and specific details showing why PHP is a pain to work with if you want robust software along with building skills a good developer should have.

https://www.quora.com/Why-is-PHP-hated-by-so-many-developers

http://phpsadness.com/

https://blog.codinghorror.com/php-sucks-but-it-doesnt-matter...

Truth be told, though, the burden of proof is on you PHP supporters to show why PHP is a good language and people should use it. I claim it was a mere pre-processor that had all kinds of programming language features bolted onto it over time to let it handle certain situations. That's not design at all. Python and Ruby are designed languages with consistency, core functionality for many situations, extensions/libraries, and optionally the ability to pre-process web pages. World of difference in both language attributes and quality of what people produce with them. So, not only have you presented no evidence of PHP's alleged good design, I've presented evidence against it and for two competitors have better designs.

Feel free to back up your claims with some actual data rather than dismiss whatever data anyone else brings up. I mean, you want to dismiss the guys ranting feel free. Can even edit all that crap out to leave just the data and arguments. Same for other links. Resulting text still supports our claims against PHP. So, status quo among professionals should be "PHP Is Garbage" that leads to buggy, hard to maintain, insecure, slow software. It will remain until PHP's community proves otherwise and demonstrates their counter-claim in practice with apps possessing the opposite of those negative traits.