CVE-2018-3665: Lazy State Save/Restore As The Latest CPU Speculative Execution Issue

[lem79]

Itanium was the only implementation of IA-64 anyway wasn't it? So it's essentially saying the same thing. Itanium needed compiler magic that never seemed to happen either.. I guess it got called Itanic for a reason

[brrrrttttt]

Itanium was the only implementation of IA-64 anyway wasn't it? So it's essentially saying the same thing. Itanium needed compiler magic that never seemed to happen either.. I guess it got called Itanic for a reason

Yup. You can either have the complexity at run time in the CPU, or in the compiler. In the CPU is the status quo, so there are no (good) compilers for VLIW. Classic chicken and egg.

[Redfoxmoon]

We should all move back to old mipsel workstations

[GruenSein]

Intel tried to fix the mess in the move to 64-bit with Itanium. AMD went and gave the market an easy way out so we're stuck with x86.

I am not sure if switching away from x86 would've helped with speculative execution exploits. The simple fact that ARM CPUs are also vulnerable should tell you that. Speculative execution has nothing to do with the instruction set but rather if you allow your CPU to work on something just in case even though it might turn out later that it wasn't intended by the code.

[starshipeleven]

x86 is a mistake. Intel is a mistake!

There are more important unfixable architectural issues that would support that. This is quite frankly a minor thing that will be fixed in the following years, you are overreacting.

[brrrrttttt]

I am not sure if switching away from x86 would've helped with speculative execution exploits. The simple fact that ARM CPUs are also vulnerable should tell you that. Speculative execution has nothing to do with the instruction set but rather if you allow your CPU to work on something just in case even though it might turn out later that it wasn't intended by the code.

Instruction scheduling is entirely the responsibility of the compiler in a VLIW architecture, the CPU does no speculation (although the compiler may generate code that speculatively executes before a branch, and the corresponding code to clean up after a miss). That is the core purpose of VLIW. The ARM cores that are susceptible to these attacks are superscalar designs just like x86 (that's why they're susceptible).

[-MacNuke-]

There are more important unfixable architectural issues that would support that.

What are those issues?

[starshipeleven]

What are those issues?

My pet peeve is https://en.wikipedia.org/wiki/RISC-V#Vector_set

Basically all the circus around MMX, SSE, AVX and friends. Each time you increase register size for vector processing you must create new instruction(s) and this means programs need to be ported and recompiled to use them.

With a different design (like RISC-V) you would not need that, the application only needs to specify a minimum, or it can be coded to ask the hardware what size it can deal with and then decide its code path accordingly (this can be done years in advance as the instructions themselves don't change, only the vector sizes, while with x86 you would have to know beforehand what the new instructions will look like).

[-MacNuke-]

Basically all the circus around MMX, SSE, AVX and friends. Each time you increase register size for vector processing you must create new instruction(s) and this means programs need to be ported and recompiled to use them.

Well that is SIMD and I think this has nothing to do with x86 alone. I mean ARM and POWER also have SIMD units and special instructions. Some of those instructions are also helpers like calculating a dot product or neural network stuff. It is much more a design decision than an "issue".

In discussions like this I read "x86 has unfixable issues" all the time but it is hard to find any issues that are not very minor (like the A20 gate) or also present in other architectures ("it's old").

[gamerk2]

I don't think Itanium was ever going to be aimed at the commodity market...

IA64 was going to be x86's replacement. Hell, Intel even gave x86 emulation for legacy systems at ~80% performance, but the intent was everything would shift to IA64 and x86 would simply fade away.

Instead, we get 64-bit extensions to x86, and legacy 32-bit x86 code isn't going away because it's still natively supported.

I continue to hold x86-64 will end up being one of the biggest mistakes in computing history when all is said and done. We had a chance to move away from a rather poorly designed CPU architecture, and we blew it.