Intel Continues Working On New ISA Extensions To Help Fight Speculation Vulnerabilities

[phoronix]

Phoronix: Intel Continues Working On New ISA Extensions To Help Fight Speculation Vulnerabilities

In addition to making public new security advisories this Patch Tuesday requiring updated CPU microcode, Intel also issued a press statement about their ongoing fight against speculation vulnerabilities with their processors...

https://www.phoronix.com/scan.php?page=news_item&px=Intel-ISA-Fighting-Spec

[karolherbst]

LOL

next: new Vulnerability found in new ISA Extension to protect against Speculation Vulnerabilities

[waxhead]

LOL

next: new Vulnerability found in new ISA Extension to protect against Speculation Vulnerabilities

Yup! This is like fixing something mechanical by throwing on more and more parts when a redesign of one part would be the correct solution.

[onlyLinuxLuvUBack]

Think of this: Intel could set aside a region of the cpu die and start adding new cores that run templeOS and holyC.

[scratchi]

Think of this: Intel could set aside a region of the cpu die and start adding new cores that run templeOS and holyC.

I just looked into templeOS and it's history...very interesting; sad ending though. Amazing what some people are capable of. Thanks for the post.

[coder]

SERIALIZE strikes me as an uncharacteristically long opcode. I wonder what's the longest, in current x86 assembly.

[coder]

Yup! This is like fixing something mechanical by throwing on more and more parts when a redesign of one part would be the correct solution.

I think you guys are being too harsh.

Even addressing these vulnerabilities through hardware changes is going to have costs in perf/W, if not also absolute performance. Intel is really on the right track with having software make some effort to communicate intent. Because, if the CPU simply makes the assumption that it has to guard against information leakage in every way and place possible, that's going to add significant overhead, regardless of whether it's processing sensitive information or not.

And, if you look at the situation we're in today, some users are disabling all mitigations, just to avoid the performance impact in the cases where they're least needed and most impactful (e.g. videogames).

[numacross]

SERIALIZE strikes me as an uncharacteristically long opcode. I wonder what's the longest, in current x86 assembly.

Including extensions like AVX? Looks like it's VGF2P8AFFINEINVQB

[waxhead]

I think you guys are being too harsh.

Even addressing these vulnerabilities through hardware changes is going to have costs in perf/W, if not also absolute performance. Intel is really on the right track with having software make some effort to communicate intent. Because, if the CPU simply makes the assumption that it has to guard against information leakage in every way and place possible, that's going to add significant overhead, regardless of whether it's processing sensitive information or not.

And, if you look at the situation we're in today, some users are disabling all mitigations, just to avoid the performance impact in the cases where they're least needed and most impactful (e.g. videogames).

Too hash?... maybe, but what karloherbst joked about is maybe not so unlikely. And throwing on extension for everything may be helpful in the short term , but clutters the architecture. They might as well have consdered impementing the RISC-V ISA as an extension. That way one could lat least over time migrate to a clean(er) instruction set.

[coder]

throwing on extension for everything may be helpful in the short term , but clutters the architecture.

You're going to have to get over that. If we want CPU performance to keep scaling, then the abstraction boundary between hardware and software will need to change. There's no way around it, as not to do so just leaves too much performance (or efficiency) on the table.

Looking at it another way, the hardware is just incredibly complex, and we're past the point of putting all the burden on the hardware to hide that complexity. That's arguably a factor, in some of these bugs.

I know it's not a great analogy, but it's a little like Vulkan and GPUs, where OpenGL sort of maintained a conceit of treating the hardware like it's stateful & serial, but Vulkan just blew the lid off and let users twiddle with all the various concurrent pieces, inside.

They might as well have consdered impementing the RISC-V ISA as an extension. That way one could lat least over time migrate to a clean(er) instruction set.

The legacy of x86 doesn't help, but this isn't primarily about ISA. It's about extremely complex micro-architectures and CPU designers wanting to use lots of tricks to squeeze as much performance out, as possible.