Massive security hole in CPU's incoming?Official Meltdown/Spectre Discussion Thread

[Hitman928]

I really don't think something is a bug if it's working as designed. A bug to me is an unintended flaw that affects performance, not a security "hole" that can be exploited in a product that works as designed.

The way I look at it is this: Bug = design was fine, execution had issues. In this case; execution was fine, design was 'flawed'.

While this is true, I think it is really arguing semantics. Whether it's a bug or a design flaw as you defined makes no difference. You could just as easily argue that a design flaw is just a bug in the architecture. The salient point is the same.

If you really want to go down that route though, a bug implies that this was completely accidental. If you insist on calling it part of the design, you open it up for intel to be scrutinized over intentionally sacrificing security for performance as part of the design when their direct competitor using the same underlying architecture and principles got it right. Neither is good, the second one is probably worse though, imo.

 

[Phynaz]

https://arstechnica.com/gadgets/201...odern-processor-has-unfixable-security-flaws/

ARM has confirmed they may be vulnerable to Meltdown. They are contributing to Linux patches.

 

[Phynaz]

While this is true, I think it is really arguing semantics. Whether it's a bug or a design flaw as you defined makes no difference. You could just as easily argue that a design flaw is just a bug in the architecture. The salient point is the same.

If you really want to go down that route though, a bug implies that this was completely accidental. If you insist on calling it part of the design, you open it up for intel to be scrutinized over intentionally sacrificing security for performance as part of the design when their direct competitor using the same underlying architecture and principles got it right. Neither is good, the second one is probably worse though, imo.

Technically, designs have flaws, implementations have bugs.

 

[moinmoin]

Yes, I agree. The problem for AMD would come though if a similar exploit to Meltdown (same in name or not) were found to be effective against AMD CPUs and the KPTI fix which they insisted they didn't need now becomes a critical fix for AMD as well. That is also the tone of the linux guy who greenlit the adjusted patch to exclude AMD from the potential performance decrease. Basically he puts the liability back on them saying the plan was to implement it for all x86 CPUs but AMD is completely sure they don't need it so. . .

This would be a nightmare scenario for AMD, even worse than what it is for intel right now, IMO. Again, I actually lean to AMD's side that it is the right call, all things considered, I just hope it truly is for their sake. Maybe I'm just being paranoid, but when it comes to this stuff, you kind of have to be.

Exactly, this would be a nightmare scenario for AMD. Which is why I consider the possibility to be very high that AMD has already designed its chips to prevent that particular attack. The patch from the AMD employee requesting to disable KPTI for AMD chips with this succinct explanation shows their confidence.

AMD processors are not subject to the types of attacks that the kernel page table isolation feature protects against. The AMD microarchitecture does not allow memory references, including speculative references, that access higher privileged data when running in a lesser privileged mode when that access would result in a page fault.

https://lkml.org/lkml/2017/12/27/2
The Meltdown paper makes it seem that behavior should be expected, but then doesn't detail how out-of-order execution allows the privilege escalation on Intel chips but doesn't work on AMD chips. Above patch note explains the difference in behavior (and could explain why AMD also considers the possibility of Spectre variant 2 to work on AMD chips to be "near zero" even though variant 1 works in some circumstances).

 

[Markfw]

These are implementations of side-channel attacks. They expose flaws in processor designs, they are not bugs in themselves. Even Android on ARM is getting patched to get the Kernel address space out of user space.

Side channel attacks are nothing new, just see the references in the Meltdown paper. First you need to understand what the issue is. AMD is also affected by Specter, and the authors say AMD may be affected by Meltdown - they don't know.

Noooo, again, read the analysis:
"
AMD processors are not subject to the types of attacks that the kernel
page table isolation feature protects against. The AMD microarchitecture
does not allow memory references, including speculative references, that
access higher privileged data when running in a lesser privileged mode
when that access would result in a page fault.

Disable page table isolation by default on AMD processors by not setting
the X86_BUG_CPU_INSECURE feature, which controls whether X86_FEATURE_PTI
is set."

I can't find the post that references the fact that no processor should be allowed to to this, but Intel does, and they did it to speed up execution, but AMD does not allow it.

 

[richaron]

I really don't think something is a bug if it's working as designed. A bug to me is an unintended flaw that affects performance, not a security "hole" that can be exploited in a product that works as designed.

The way I look at it is this: Bug = design was fine, execution had issues. In this case; execution was fine, design was 'flawed'.

Yeah... No. Have you done much in the way of programming? You'll notice heaps of bugs which are just syntax or stupid loop conditions; The code may be working as "designed" (i.e. you may be able to compile and run the code) but the program is not working as you "designed"/intended.

In this case intel CPUs have a bug because there's a problem with the implementation of the design. Like one of their design principles was to separate memory systems, and they put lots of time, effort, and transistors into doing just that. Although they missed something so it doesn't work as designed. This means it has a bug.

 

[Elixer]

Just read the source....Non-Intel CPU's have been tested.

https://googleprojectzero.blogspot.com/2018/01/reading-privileged-memory-with-side.html

B] Tested Processors[/B]

• Intel(R) Xeon(R) CPU E5-1650 v3 @ 3.50GHz (called "Intel Haswell Xeon CPU" in the rest of this document)
• AMD FX(tm)-8320 Eight-Core Processor (called "AMD FX CPU" in the rest of this document)
• AMD PRO A8-9600 R7, 10 COMPUTE CORES 4C+6G (called "AMD PRO CPU" in the rest of this document)
• An ARM Cortex A57 core of a Google Nexus 5x phone [6] (called "ARM Cortex A57" in the rest of this document)

So, here, they show bulldozer, not anything Zen based, and not Ryzen Pro, and some ARM units.

The Ryzen Pro one is the one I am most curious about, and in theory would not be affected by these exploits for Spectre.

 

[mattiasnyc]

While this is true, I think it is really arguing semantics. Whether it's a bug or a design flaw as you defined makes no difference. You could just as easily argue that a design flaw is just a bug in the architecture. The salient point is the same.

If you really want to go down that route though, a bug implies that this was completely accidental. If you insist on calling it part of the design, you open it up for intel to be scrutinized over intentionally sacrificing security for performance as part of the design when their direct competitor using the same underlying architecture and principles got it right. Neither is good, the second one is probably worse though, imo.

I think you justify the "exercise in semantics" in that second paragraph. In my opinion.

 

[Phynaz]

Ars is also reporting that people will be able to opt out of the Windows and Linux patches.

 

[Hitman928]

I think you justify the "exercise in semantics" in that second paragraph. In my opinion.

There are certainly times when exercises in semantics are necessary, sure, I just didn't think this was one of them and would only actually hurt his cause (which was the point I was actually trying to make in the second paragraph).

Anyway, really don't care enough to argue it, doesn't matter to me what you call it, the effect is the same. I'm sure someone with a law degree will be happy to argue the semantics for a big payday if there's evidence to do so.

 

[Hitman928]

Ars is also reporting that people will be able to opt out of the Windows and Linux patches.

I don't know about Windows, but even if the patch is downloaded on Linux, there's a kernel boot command option you can use to disable the fix. I don't know if this will be similar in Windows or if you'll have to avoid the patch altogether.

 

[VirtualLarry]

I beg to differ. Intel allows non-privileged cache to access privileged cache ? (or whatever) Linux called them out I think. I may not have my terminology all correct, But following this thread, its obvious Intel did something to optimize that should not be allowed, but AMD enforced the rules.

Think of it this way - Intel took the easy way out in its implementation of CPUs, much like NVidia "cheated" with aniso filtering at times in the past with their drivers. Whereas, AMD, again, gave the user full quality as requested.

 

[Phynaz]

Noooo, again, read the analysis:
"
AMD processors are not subject to the types of attacks that the kernel
page table isolation feature protects against. The AMD microarchitecture
does not allow memory references, including speculative references, that
access higher privileged data when running in a lesser privileged mode
when that access would result in a page fault.

Disable page table isolation by default on AMD processors by not setting
the X86_BUG_CPU_INSECURE feature, which controls whether X86_FEATURE_PTI
is set."

I can't find the post that references the fact that no processor should be allowed to to this, but Intel does, and they did it to speed up execution, but AMD does not allow it.

"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 described in Section 5, neither on ARM nor on AMD. The reasons for this can be manifold. First of all, our implementation might simply be too slow and a more optimized version might succeed. For instance, a more shallow 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, indicating that out-of-order execution generally occurs and instructions past illegal memory accesses are also performed."

Nowhere does that say AMD is not subject to attack. Just the opposite.

 

[Hitman928]

So, here, they show bulldozer, not anything Zen based, and not Ryzen Pro, and some ARM units.

The Ryzen Pro one is the one I am most curious about, and it theory would not be affected by these exploits for Spectre.

After reading the papers and the blog post, there seems to be some contradicting info as to which exploits were tested with which CPUs. I'm guessing that the initial research papers were put together and then maybe some additional testing happened to further explore which CPUs were vulnerable which only made it to the blog post. Not sure.

 

[William Gaatjes]

So, here, they show bulldozer, not anything Zen based, and not Ryzen Pro, and some ARM units.

The Ryzen Pro one is the one I am most curious about, and in theory would not be affected by these exploits for Spectre.

Aha, i was wondering what the amd pro was that they tested.

 

[mattiasnyc]

it doesn't work as designed. This means it has a bug.

As far as I can tell an actual bug means a system outputs an undesired result because of an error. In other words the system produces the problem. It's different from someone from the outside exploiting a weakness in the system. Here we have instead something that isn't a problem unless someone exploits the system. Of course that doesn't exclude the possibility that a bug can be exploited, it just so happens this doesn't appear to be one.

Or as Phynaz wrote: "Technically, designs have flaws, implementations have bugs."

So I just disagree with you, and I think the difference is worth noting.

 

[Phynaz]

IBM Z, POWER 8, POWER 9 reported vulnerable.

 

[richaron]

IBM Z, POWER 8, POWER 9 reported vulnerable.

Reported vulnerable to the least concern Spectre?

I assume intel CPUs are still the only ones with the much worse Meltdown bug.

 

[Phynaz]

Anybody have a Redhat support subscription?

https://access.redhat.com/articles/3307751

Speculative Execution Exploit Performance Impacts - Describing the performance impacts to security patches for CVE-2017-5754 CVE-2017-5753 and CVE-2017-5715

 

[Phynaz]

Reported vulnerable to the least concern Spectre?

I assume intel CPUs are still the only ones with the much worse Meltdown bug.

Again, Meltdown isn't a bug. Meltdown is an explot.

 

[Phynaz]

Reported vulnerable to the least concern Spectre?

I assume intel CPUs are still the only ones with the much worse Meltdown bug.

Redhat:

Red Hat has been made aware of multiple microarchitectural (hardware) implementation issues affecting many modern microprocessors, requiring updates to the Linux kernel, virtualization-related components, and/or in combination with a microcode update. An unprivileged attacker can use these flaws to bypass conventional memory security restrictions in order to gain read access to privileged memory that would otherwise be inaccessible. There are 3 known CVEs related to this issue in combination with Intel, AMD, and ARM architectures. Additional exploits for other architectures are also known to exist. These include IBM System Z, POWER8 (Big Endian and Little Endian), and POWER9 (Little Endian).

 

[richaron]

As far as I can tell an actual bug means a system outputs an undesired result because of an error. In other words the system produces the problem. It's different from someone from the outside exploiting a weakness in the system. Here we have instead something that isn't a problem unless someone exploits the system. Of course that doesn't exclude the possibility that a bug can be exploited, it just so happens this doesn't appear to be one.

Or as Phynaz wrote: "Technically, designs have flaws, implementations have bugs."

So I just disagree with you, and I think the difference is worth noting.

Designs are a philosophy. Implementation is where bugs come in. Previously you seemed to claim it can't be a bug because of manufacturing? Manufacturing is no more "implementation" (of a design concept) than compiling a program is. Both can be perfect and the end products still contain bugs. Since intel designed their CPUs to separate memory systems and they failed to properly implement their designs it's a bug.

Frankly I don't think you understand the concept, and I think others are just here to try control the narrative. Neither of which I can change, all I can do is add my 2c.

 

[richaron]

Again, Meltdown isn't a bug. Meltdown is an explot.

Meltdown exists because of a specific bug in intel CPUs.

So it's perfectly logical to call it the Meltdown bug. I'll just call the bug Meltdown because there's nothing else it can be.

 

[Phynaz]

Meltdown exists because of a specific bug in intel CPUs.

So it's perfectly logical to call it the meltdown bug.

Ok.

 

[richaron]

Is that what the authors call it?

I haven't asked them...

Meltdown exists because this intel CPU bug exists. I'll call the bug Meltdown then also. Makes sense to me, you can call it something else. The purpose of language is to convey an idea and my way works fine.