Live data from Hacker News

Meltdown, aka “Dear Intel, you suck”

marc.info

161–170 of 176 posts

Re: Meltdown, aka “Dear Intel, you suck”

#161
post #100

Is it the right time to call out the fundamental wrongness of Intel(/Apple/Microsoft/etc) outrage narratives? I mean I get it: large corporations (1) don't necessarily have my interests at heart; (2) are not able to perfectly execute (on extremely large and complicated) products and systems. um. This is as radical as taking a stand that the sun sets in the west. I like HN because of the promise that people think just…

People just don't like paying for intangible things, so the only way to pay for the internet is clickz/eyeballz. And OUTRGE! clickz/eyeballz are the cheapest and easiest.

The irony of course is that this was posted on a mailing list (so clicks are meaningless) by a developer of free software who has to spend his time working around these bugs that Intel caused. He has every right to be outraged and vent all he wants. He is actually doing the hard work while you watch kitten videos and chuckle-memes.

Re: Meltdown, aka “Dear Intel, you suck”

#162
post #141

Earlier quoted context omitted.

Don't mistake this as OpenBSD's concern for all BSD's. This is just OpenBSD rant because they isolated themselves by not respecting embargoes in the past. Some ARM CPU's are also vulnerable by the way.

That's an interesting point RE OpenBSD, especially if FreeBSD and NetBSD were included (which I do not know), I suspect this was just down to plain irresponsible incompetence though. ...I've no idea what your ARM comment has to do with it though. Meltdown is Intel specific. A relevant question however might be who coordinated the work between june 2017 and now for Meltdown mitigations? Project zero at google discover…

Has FreedBSD/NetBSD made a statement. I know DragonFly has a patch on master.

It's an odd world where Linux is in the "big three" and the BSD counterparts are more on the fringe. It's a far cry from the early world of the 2000s.

Re: Meltdown, aka “Dear Intel, you suck”

#163
post #133
post #100

Is it the right time to call out the fundamental wrongness of Intel(/Apple/Microsoft/etc) outrage narratives? I mean I get it: large corporations (1) don't necessarily have my interests at heart; (2) are not able to perfectly execute (on extremely large and complicated) products and systems. um. This is as radical as taking a stand that the sun sets in the west. I like HN because of the promise that people think just…

Is outrage not the way that almost anything moves forward these days? I feel that if not for the internet (the modern version where anyone has the ability to publish something that can be seen by many, regardless of tech knowledge) that we would be utterly powerless. It’s one of the few things that causes large organizations to actually care about anything. It’s almost an obligation these days.

Outrage can move things, but irrational outrage will move things in a mindless direction, which doesn’t help anything.

“Intel sucks” except arm cpus are affected too. “Intel sucks” except there’s a network of entities involved in disclosure. “Intel sucks” except OpenBSD previously opted out of this disclosure mechanism. I don’t see how anything will move in useful direction from this. Perhaps Intel will find a way to write statements with better feelz. That’s nice, but it’s not substantive and doesn’t deal with any of the underlying issues here.

Re: Meltdown, aka “Dear Intel, you suck”

#164
post #63
post #53

Earlier quoted context omitted.

Implementing a cool optimization that happens to break your processor's security features is cheating, yes, even if you did it unintentionally, like accidentally taking a performance-enhancing drug.

They didn't unintentionally break security features; they knowingly did so - the potential for information disclosure was widely documented. In their defense - the solution isn't trivial in general, and large parts of at least spectre apply in ways a CPU would be hard pressed to prevent (how is a CPU to know that even though memory isn't marked as protected from currently running code in actual fact that's because th…

Your parent was talking about Meltdown; that's the one that breaks security features, specifically: memory safety of a higher privilege level from a lower one.

Re: Meltdown, aka “Dear Intel, you suck”

#165
post #75
post #70

Earlier quoted context omitted.

These classes of attacks are not new. Timing attack in crypto have been widely used for a long time. And even specifically in CPU's there was stuff like http://www.daemonology.net/papers/htt.pdf and http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.190... over ten years ago(!) . To quote that last paper: > We show how processor architecture features such as simultaneous multithreading, control speculation and…

Yes, I am aware of them and agree with you. In fact, cache-miss side channel attacks are known by academics for years as well. However, this is the first time someone combining various of previous techniques (timing, cache-miss, speculative loading etc.) together to make this attack work. Quote from the meltdown paper: > We expect that Meltdown and Spectre open a new field of research to investigate in what extent pe…

> We expect that Meltdown and Spectre open a new field of research to investigate in what extent performance optimizations change the microarchitectural state, how this state can be translated into an architectural state, and how such attacks can be prevented.

Not to be cynical or downplay the research, but that's the kind of thing you (have to?) put into papers to make getting research funding easier in future. Hardly a new field, just very difficult to do research on.

Re: Meltdown, aka “Dear Intel, you suck”

#166
post #95

Earlier quoted context omitted.

You could go with AMD which is seemingly immune to Meltdown, but apparently someone already found a security flaw with their PSP (aka their own Intel ME).

If you need security and it doesn't need to be fast, use a raspberry pi. No ME, no PSP, no meltdown, and no spectre.

The firmware driving the VC4 on an RPi is non-free and closed, and the VC4 runs with greater privilege than the ARM core, with access to all the RAM. This firmware may not have security bugs like the ME and the PSP have had, and it may not contain a backdoor that we know of, but technically there's nothing stopping it from having one without anyone in the public knowing it.

Still, no Meltdown and no Spectre on any RPi

Re: Meltdown, aka “Dear Intel, you suck”

#167
post #96
post #85

Earlier quoted context omitted.

They would have had to delay it for a year or more.

So the decision was, go ahead and release it even though we know it's vulnerable because we'll make more money that way than we would if we took the time to fix it and make it secure? If so, I hope the market punishes that decision mercilessly.

What? No, that's not even remotely how it works. Not releasing Coffee Lake when it was ready would not have sped up the design of a new CPU which fixes Meltdown in any way. The only way that not shipping Coffee Lake would have helped anyone is by indirectly increasing sales of AMD processors.

Re: Meltdown, aka “Dear Intel, you suck”

#168
post #151

Earlier quoted context omitted.

> This exploit is very hard to imagine before now. It's really not. It's the sort of thing you wonder after first learning about out-of-order and speculative execution in a computer architecture class, but your professor assures you that implementors have been very careful to ensure any partial execution is properly flushed and rolled back. Then it turns out that, nope, no one's actually been keeping an eye on this a…

> but your professor assures you that implementors have been very careful to ensure any partial execution is properly flushed and rolled back. And, at the time, your professor was correct, to the extent of what he/she defined as "any partial execution". But his/her definition of "partial execution" only considered state changes to the programmer visible CPU architecture state (i.e., the user level register set and th…

> But his/her definition of "partial execution" only considered state changes to the programmer visible CPU architecture state (i.e., the user level register set and the flags register). Their definition ignored the cache, because at the time the cache was considered simply a transparent optimization system that did not effect the values of contents of the CPU architectural state.

You're putting words in other people's mouths here.

Re: Meltdown, aka “Dear Intel, you suck”

#169
post #116

Earlier quoted context omitted.

The three big BSDs aren't exactly obscure, they might not have the highest server market share compared to windows and linux but they are the next on the list and often a primary choice for a variety of companies critical infrastructure, the most commonly sighted example these days is netflix. I think the outrage is justified.

The language of the post is incredibly incendiary -- they sound no different than some of the extremists / terrorists talking about their enemies. At the end of the day, we are all humans and the chip designers screwed up in a big way. But this issue is so complex and obscure that it's been unknown for 20+ years.

That's not their argument, their issue is intel didn't bother informing them so they had adequate time to work on patches (you know like they did for linux and windows kernel devs).

Re: Meltdown, aka “Dear Intel, you suck”

#170
post #82

Earlier quoted context omitted.

From my perspective: I've been singing Intel's praises for the last decade as they regularly (for my own tests/usage) beat out AMD in performance, clock for clock if not dollar for dollar. With this recent news, I feel like part of the reason that Intel has been doing so well is that they have been _cheating_.

Clock speed has been an awful metric for 2 decades now (except for within a single CPU model series). All processors (including AMD/ARM) since the early 90's have been using instruction pipelining. It's a universal performance improvement, not Intel cheating.

Intel is cheating by validating the protection ring of speculative executions asynchronously, aka Meltdown, which makes this timing attack work in kernel space and requires the PTI mitigation. ARM does this on some cores too. AMD insists that they do not.
Post reply on HN