AMD-SB-7005 “Return Address Security Bulletin” outlines this new speculative side channel attack affecting recent EPYC and Ryzen processors.

AMD has received an external report titled ‘INCEPTION’, describing a new speculative side channel attack. AMD believes ‘Inception’ is only potentially exploitable locally, such as via downloaded malware, and recommends customers employ security best practices, including running up-to-date software and malware detection tools. AMD is not aware of any exploit of ‘Inception’ outside the research environment, at this time.

  • yum13241@lemm.ee
    link
    fedilink
    arrow-up
    1
    ·
    edit-2
    1 year ago

    Maybe CPU manufactures shouldn’t add hacks to their CPUs for more performance, and therefore more $$$'s. If they were held liable this’d never happen.

    Do you know why Zen 2 and Zen 1 don’t have this issue? Because they didn’t come up with the hack they used to increase performance (and therefore $$$'s) back then because they knew it’d leak like crazy. This time it didn’t seem like they cared.

  • interolivary@beehaw.org
    link
    fedilink
    English
    arrow-up
    0
    ·
    edit-2
    1 year ago

    Oh hey, a non-Intel speculative execution vulnerability.

    I’ve been wondering whether speculative execution as it’s currently done is just fundamentally broken and guaranteed to leak information one way or another, but I really don’t know enough about CPU design to even make a guess

    • PenguinTD@lemmy.ca
      link
      fedilink
      English
      arrow-up
      0
      ·
      1 year ago

      It was done to do the both side of if/else while waiting for the check to finish, then it jumps to the correct branch result execution point to keep going, whatever that was “wrong” is wasted and should be flushed. Don’t know if this fits the modern definition but that’s why they do this type of thing.

      Actual design or implementation is more complex than I described as there are a couple ways to tackle this branching delay issue.

      • KRAW@linux.community
        link
        fedilink
        English
        arrow-up
        0
        ·
        edit-2
        1 year ago

        Does it execute both, or does it execute the branch that is more likely to be valid? Branch prediction seems like it’d be way more performant than executing both branches until the result of the branch condition is available. If you think about it, what you’re proposing will cause the CPU to always execute instructions that are not meant to be executed when confronted with a branch whereas branch prediction will only execute these “useless” instructions in the unlikely scenario where the prediction is incorrect.

        • Sloogs@lemmy.dbzer0.com
          link
          fedilink
          English
          arrow-up
          1
          ·
          edit-2
          1 year ago

          It will prefetch the instructions and put into the pipeline the branch it thinks is mostly likely. It may do ahead-of-time speculative execution on certain instructions but not always. If it missed the correct branch it will flush the pipeline and start the pipeline over again from the correct branch. Afaik it doesn’t execute or prefetch both branches. The other guy is saying it does but that doesn’t really gel with my own recollection or the Wikipedia article he cited. You can see some further discussion that suggests only one branch gets prefetched here here and here. Reasons cited for only predicting one branch are: 1) Two pipelines with all the associated circuitry to look ahead, decode, and speculatively execute is incredibly expensive in terms of both processing requirements and die real estate. 2) Caching both would thrash your caches with new data constantly. 3) Modern branch prediction is already so accurate, there’s really no need for two pipelines anyways.