Live data from Hacker News

Meltdown, aka “Dear Intel, you suck”

marc.info

51–60 of 176 posts

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

#51
post #47

Earlier quoted context omitted.

The OpenBSD developers are mad that Intel didn't inform them, or any of the other BSDs. Only Microsoft and Linux developers where included in the information that was under embargo. I don't think they're upset that Intel made a mistake, not more so that most others anyway.

Don‘t they refuse to honor embargoes? That would be an explanation why they got no information privately.

Here's an LWN article that references Theo's position on embargoes: https://lwn.net/Articles/601958/

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

#52
post #40

I don’t understand the Intel hate. It’s not like their engineers are dumb or lazy. This exploit is very hard to imagine before now. And it’s there because chip makers were trying to wring out more performance. It’s unfortunate if anythig.

Well, there is the ME for one, an omnipotent, mandatory backdoor. Then there are _many_ undocumented opcodes. What does 0f0d00 do? What 0f78c0? What dbe0? I can continue for a very long time. These are just some known unknowns. If you still need more reasons, they are uncooperative when it comes to certain other firmware blobs.

If you are open to arguments, there are many good reasons to take a negative stance towards Intel.

Fun fact: I sent an overview of unknown instructions in compressed text form to a gmail address, and Google rejected it citing potentially malicious content.

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

#53
post #50

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

Is it really cheating? What they are doing is well known and published, with one side effect that didn’t get rolled back (which seems more like a bug). At least that’s what I’ve understood from what I’ve read.

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.

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

#54
post #40

I don’t understand the Intel hate. It’s not like their engineers are dumb or lazy. This exploit is very hard to imagine before now. And it’s there because chip makers were trying to wring out more performance. It’s unfortunate if anythig.

Spectre is somewhat reasonable; at least some variants are forgivable. Meltdown isn't. The risks due specifically to speculation and cache timing attacks (and lots of related stuff) were well known and documented for over a decade. They shouldn't have been speculating across memory protection boundaries, and they should have known that - even if it was unclear exactly how one might exploit such information leakage.

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

#55
post #7

Earlier quoted context omitted.

they previously broke the KRACK embargo (among others): https://lobste.rs/s/dwzplh/krack_attacks_breaking_wpa2#c_pbh... it's no surprise they're not high up on the list of important people to tell

He told them they could go ahead, he then regretted it but that's not OpenBSD's fault. From https://www.krackattacks.com/#openbsd : > As a compromise, I allowed them to silently patch the vulnerability. Receiving permission to patch is the opposite of breaking an embargo.

And it continues:

> As a compromise, I allowed them to silently patch the vulnerability. In hindsight this was a bad decision, since others might rediscover the vulnerability by inspecting their silent patch. To avoid this problem in the future, OpenBSD will now receive vulnerability notifications closer to the end of an embargo.

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

#56
post #53
post #50

Earlier quoted context omitted.

Is it really cheating? What they are doing is well known and published, with one side effect that didn’t get rolled back (which seems more like a bug). At least that’s what I’ve understood from what I’ve read.

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.

Intent matters, at least to me. This does not seem to be a case like VW's diesel-emissions shenanigans.

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

#57
post #24

Meanwhile I have seen nothing from QNX or Integrity...

I wonder to what extent QNX would be affected. It all depends on whether or not they map their micro kernel into the same address space as the application, for a micro kernel there is absolutely no reason to do that, the only things you might want to re-map are the message buffers and that can be done with some page table trickery.

QNX does map it's kernel onto high end of user VM space.

Due to how i386 TLB works (ie. no ASID) doing that is essentially required to get reasonable performance, micro kernel or not.

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

#58
post #40

I don’t understand the Intel hate. It’s not like their engineers are dumb or lazy. This exploit is very hard to imagine before now. And it’s there because chip makers were trying to wring out more performance. It’s unfortunate if anythig.

I thought this exploit was imagined a decade ago? I could swear I have seen links posted here where concerns were raised as speculative execution entered the picture. But I agree that it’s hard to blame them when it took a decade for something to actually materialize.

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

#59
post #28

Earlier quoted context omitted.

Do you have any source on why AMD64 is unaffected? The paper only mentions that they couldn't make their current approach work on AMD, but it doesn't rule out that it could be improved and made work

AMD's microarchitecture does not perform speculative loads that would cause a segfault, according to this AMD engineer: https://lkml.org/lkml/2017/12/27/2

> We also tried to reproduce the Meltdown bug on several ARM and AMD CPUs. However, we did not manage to successfully leak kernel memory with the attack de- scribed in Section 5, neither on ARM nor on AMD. The reasons for this can be manifold. First of all, our im- plementation might simply be too slow and a more opti- mized version might succeed. For instance, a more shal- low out-of-order execution pipeline could tip the race condition towards against the data leakage. Similarly, if the processor lacks certain features, e.g., no re-order buffer, our current implementation might not be able to leak data. However, for both ARM and AMD, the toy example as described in Section 3 works reliably, indi- cating that out-of-order execution generally occurs and instructions past illegal memory accesses are also per- formed.

From the Meltdown paper[0] section 6.4 it would seem that out of order execution referencing illegal memory locations still occurs unless of course I'm misunderstanding something.

0: https://meltdownattack.com/meltdown.pdf

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

#60
post #40

I don’t understand the Intel hate. It’s not like their engineers are dumb or lazy. This exploit is very hard to imagine before now. And it’s there because chip makers were trying to wring out more performance. It’s unfortunate if anythig.

Well they did release their Coffee Lake generation chip after they already new about the exploit.

Now i know it would take a lot for a major company to delay/cancel a release like that, but i think it could be argued that they were dishonest if they knew it would have a performance impact.

Post reply on HN