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

  • 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

  • #2
    LOL

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

    Comment


    • #3
      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.

      http://www.dirtcellar.net

      Comment


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

        Comment


        • #5
          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.

          Comment


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

            Comment


            • #7
              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).

              Comment


              • #8
                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

                Comment


                • #9
                  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.

                  http://www.dirtcellar.net

                  Comment


                  • #10
                    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.

                    Comment

                    Working...
                    X