Announcement

Collapse
No announcement yet.

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

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • coder
    replied
    Originally posted by waxhead View Post
    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.

    Originally posted by waxhead View Post
    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.

    Leave a comment:


  • waxhead
    replied
    Originally posted by coder View Post
    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.

    Leave a comment:


  • numacross
    replied
    Originally posted by coder View Post
    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

    Leave a comment:


  • coder
    replied
    Originally posted by waxhead View Post
    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).

    Leave a comment:


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

    Leave a comment:


  • scratchi
    replied
    Originally posted by onlyLinuxLuvUBack View Post
    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.

    Leave a comment:


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

    Leave a comment:


  • waxhead
    replied
    Originally posted by karolherbst View Post
    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.

    Leave a comment:


  • karolherbst
    replied
    LOL

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

    Leave a comment:


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

    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?pa...-Fighting-Spec
Working...
X