Meltdown, aka “Dear Intel, you suck” • Hacker News Board

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

#61

Post by xucheng » Sat, Jan 06, 2018, 3:07 PM UTC

sverige wrote: post #17

fny wrote: post #6

Is there not some sort of OS embargo consortium that could be created to resolve this?

The problem with embargoes is that they tend to run so long that users are put at risk unnecessarily. Most of the reasons for extending embargoes way beyond the time needed to prepare and test patches are just bullshit. For example, from the conversation on the KRACK embargo: >Q. What is the rationale on extending the embargo so long? To give vendors a chance to patch? It seems like once people in the know know about…

I think there is another important reason to extend embargoes aside preparing patches. Vulnerabilities like Meltdown and Spectre are in fact a whole new family of attack methods. It would take time to fully evaluate the extent of the problem. I would not be surprised that we learn new variants of Spectre in the coming future.

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

#62

Post by LeoNatan25 » Sat, Jan 06, 2018, 3:08 PM UTC

mnw21cam wrote: post #26

sverige wrote: post #22

Earlier quoted context omitted.

Which widely available and affordable CPUs aren't affected by Spectre?

Most of the ARM CPUs are not affected. For instance, the Raspberry Pi beards are not affected.

AMD CPUs are not affected by Meltdown, but they are affected still by Spectre.

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

#63

Post by emn13 » Sat, Jan 06, 2018, 3:08 PM UTC

lmm wrote: post #53

DougN7 wrote: 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.

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 the JIT and the JIT-tted code are running in the same memory space?). But the intel CPUs are leaking a lot more data than reasonable.

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

#64

Post by shagie » Sat, Jan 06, 2018, 3:09 PM UTC

ksec wrote: post #4

May be time for OpenBSD people ( if they have the resources ) to build a CPU from ground up with RISC-V?

What would that provide? You'd have a processor that exists that would have one (and only one) operating system that can run on it and everyone else (except for some of the 'linux on everything' types) would ignore.

This is the sparc and sun or MIPS and Irix all over again... except this time without any viable business model to keep moving forward and progressing on hardware or software.

So what if they make their processor that is free from all known processor level bugs. Would that mean dropping support for all the other processors? or would they still need to be aware of the processor bugs that exist in other architectures that they'd still be expected to create patches for? Would they have the resources to fix processor bugs in their own design when they are discovered?

My read on this is that it doesn't make any sense for an operating system organization that lacks any financials to try to pursue custom hardware.

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

#65

Post by mintplant » Sat, Jan 06, 2018, 3:09 PM UTC

DougN7 wrote: 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.

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

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

#66

Post by laurencei » Sat, Jan 06, 2018, 3:20 PM UTC

mintplant wrote: post #65

DougN7 wrote: 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.

> 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 if it is "so obvious" - why has it taken ~20 years to discover it (publically)?

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

#67

Post by temprature » Sat, Jan 06, 2018, 3:21 PM UTC

Tomte wrote: post #47

mrweasel wrote: post #43

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.

They don't like embargoes but they don't go out of their way to break them. The only embargo I know of that OpenBSD broke was for OpenSSL, and that was an honest mistake, as explained here: https://www.tedunangst.com/flak/post/regarding-embargoes

There was another "incident" with the KRAK embargo, where OpenBSD got permission to silently patch it early and then the researcher who found it regretted giving them permission.

I think people put these two incidents together, combine it with the developers' attitudes towards embargoes and come out with: OpenBSD doesn't honour embargoes!

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

#68

Post by apcragg » Sat, Jan 06, 2018, 3:22 PM UTC

emn13 wrote: post #54

DougN7 wrote: 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.

If it is so well known why has it taken 20 years to be discovered?

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

#69

Post by _ph_ » Sat, Jan 06, 2018, 3:23 PM UTC

mannykannot wrote: post #56

lmm wrote: 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.

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

The problem still is: one of the units responsible for increasing the processor performance was not working correctly. So the increased performance of the processor was obtained by not working correctly. That qualifies as cheating - if not by intent but then by nature of the design. It remains to be investigated how much of the security implications of their design choices was or could have been known to Intel. The fundamental attack concept was known for many years.

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

#70

Post by emn13 » Sat, Jan 06, 2018, 3:23 PM UTC

xucheng wrote: post #61

sverige wrote: post #17

Earlier quoted context omitted.

The problem with embargoes is that they tend to run so long that users are put at risk unnecessarily. Most of the reasons for extending embargoes way beyond the time needed to prepare and test patches are just bullshit. For example, from the conversation on the KRACK embargo: >Q. What is the rationale on extending the embargo so long? To give vendors a chance to patch? It seems like once people in the know know about…

I think there is another important reason to extend embargoes aside preparing patches. Vulnerabilities like Meltdown and Spectre are in fact a whole new family of attack methods. It would take time to fully evaluate the extent of the problem. I would not be surprised that we learn new variants of Spectre in the coming future.

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 shared caches can inadvertently accelerate such covert channels or enable new covert channels and side channels. We first illustrate the reality and severity of this problem by describing concrete attacks.

So not just were side-channel attacks on CPUs documented; specifically the dangers of speculative execution and caching on intel cpus (there: the Itanium) was documented.

It's inconceivable that this comes as a surprise to Intel. They're playing the public for fools.

Of course some of this is intrinsic: speculative loading, caching, and accurate timers are an intrinsic problem: an JIT running in the same process as the JITted code will not be able to keep secrets from that JITted code while all three are in play. But intel specifically also allowed this across memory protection boundaries, which isn't necessary.