Hacker News Reader

Comment by ryanlol | Hacker News Reader

>Between Intel's numerous CPU bugs that they refused to refund customers for

How do you propose this could work?

Are side channel vulnerabilities in CPUs really bugs?

I mean, this one, yea. Speculative execution should not have side effects when wrong because it is Intel silently, sneakily breaking the model of how the CPU works (at least, if you only include the cache in how the PC works and not branch prediction).

I would have expected, if I thought to ask, that items were not added to the cache or were removed from the cache if the branch was not retired.

Removing items afterwords probably wouldn't work as you might be able stuff (instead of flush) the cache and figure out which line was emptied.

Intel isn't being sneaky, speculative reading was a standard and accepted feature for out of order processors for over 20 years (remember it affects ARM,AMD,Apple,IBM etc as well). Speculative reading privileged memory while unprivileged was a big mistake though.

Intel's greatest PR success in this mess has been to conflate Meltdown with Spectre. Only Intel is affected by Meltdown because of their design, and it is a more easily exploited bug.

Meltdown is not only Intel. Some ARM and Apple designed ARM processors are affected by Meltdown as well. https://en.wikipedia.org/wiki/Meltdown_(security_vulnerabili...

There are no products on the market shipping with the one ARM-designed processor affected by Meltdown.

I think that's mainly out of luck. If the exploit had been discovered two years later, the story would likely be different. Apple has been much more ambitious with their ARM processor designs and has shipping iOS and AppleTV products affected by Meltdown.

Shipping or not, it illustrates, that Intel was not unique.

Now can you argue that the given faulty design was not directly influenced by Intel conscious and deliberate bad decisions ?

I'm not sure what kind of answer you are expecting. All I am saying is that Intel is not uniquely in the wrong here. There is a whole industry of bad decisions. Whether the decisions were conscious, or only obvious in hindsight I can't say.

What’s your source for the Apple claim, as your link doesn’t support it.

"Apple has already released mitigations in iOS 11.2, macOS 10.13.2, and tvOS 11.2 to help defend against Meltdown. To help defend against Spectre, Apple has released mitigations in iOS 11.2.2, the macOS High Sierra 10.13.2 Supplemental Update, and Safari 11.0.2 for macOS Sierra and OS X El Capitan. Apple Watch is not affected by either Meltdown or Spectre." https://support.apple.com/en-us/HT208394

Meltdown is a Variant of Spectre this isn't how Intel classifies it, this is how Google Project Zero, and heck even Intel's competitor AMD classifies it.

https://www.amd.com/en/corporate/speculative-execution

https://googleprojectzero.blogspot.co.uk/2018/01/reading-pri...

It's also not the scariest variant, it's easily fixed (performance degradation aside), doesn't require a microcode update to be fixed hence is 100% software mitigated, doesn't allow you to cross between guest and host memory address spaces and isn't remotely exploitable.

On the other hand variant 1 and 2 are much scarier because they are the complete opposite of Meltdown.

Meltdown is not a variant of Spectre. Spectre itself has two variants.

And Meltdown was the easiest to exploit. Spectre is "bad" because it affects everyone, but it's less exploitable than Intel's Meltdown.

Meltdown is very much a variant of this, 3 variant exist 3.1 if you consider Meltdown on ARM.

Meltdown is the easiest to exploit and the easiest to fix it’s also the least scary one as far as compromises go.

Meltdown is a specific type of Spectre exploit.

While it's more easily exploited, it's also patchable with minimal performance impact, unlike Spectre in general.

Potentially minimal is probably more accurate. It's workload dependent. In some cases, such as frequent interrupts or system calls on older CPUs without the PCID and INVPCIB features to mitigate the cost, it can be be very expensive.

No, it's not. Please read the website of the attacks created by those who discovered and named them: https://meltdownattack.com and https://spectreattack.com

I don't mean they're literally being sneaky. The point was, from an OS or userland perspective, it should be invisible. Besides performance, it should have no effect because it is literally breaking the CPU model by executing code it shouldn't. It fixes it by not retiring the results, but the bug is in leaving an effect that can be found.

If you had said CPU designers were being sneaky it would be more obvious that you weren't being literal. By saying "Intel silently, sneakily...", it's more personal and seems as if you are being literal. It wasn't really silent either, it was well enough documented that they did speculative execution. Many many very technical and educated people from across the industry knew about this and didn't think it was an issue. They were wrong.

Let's not throw the baby out with the bathwater here. I don't think the problem is that speculative execution is not as invisible as it was once believed. The problem is more of awareness and documentation. If there was an option to disable speculative execution and awareness of the associated security issues from the beginning, I don't think anyone would have a problem with using it for a performance boost where it was safe to do so. The problem is there was an industry wide assumption that it wasn't a problem that turned out to be wrong.

They promise modern process isolation and fail to deliver it. Their fixes reduce performance significantly. IANAL, but that sounds like a defective product.

>They promise modern process isolation and fail to deliver it.

Modern process isolation is not flawless, therefore it is not modern process isolation.

> They promise modern process isolation and fail to deliver it.

Before one makes such a statement, one has to define "modern process isolation" in a very formal way, so that not anybody (neither Intel nor the customer) can redefine the meaning as they desire. I am not aware that Intel gave such a formal definition that they claim to obey to (but perhaps fail). So any operating system can only rely on very weak guarantees for the processor to provide "isolation" (using quotes since I have not defined the term "isolation" formally). Thus the OS has to implement stronger isolation primitives that it desires by itself (by using the weak primitives that the processor provides).

Reply on news.ycombinator.com