Stories
Slash Boxes
Comments

SoylentNews is people

posted by chromas on Monday July 30 2018, @11:08PM   Printer-friendly [Skip to comment(s)]

Threatpost reports:

[A] new Spectre-class exploit, dubbed SpectreRSB, was detailed by researchers from the University of California at Riverside in a research paper [PDF] on Friday. While the flaw still targets the process of speculative execution, unlike other variants, it manipulates a new part of the process called the return stack buffer.

[...] RSB is a common "predictor structure" in CPUs used to predict return addresses during the speculative execution process. It does so by pushing the return address from a call instruction on an internal hardware stack [...]

Since the disclosure of Spectre in January, various variants have consequently been disclosed by researchers – however, these have all targeted the branch predictor unit or cache within the CPU.

[...] Researchers said they have reported SpectreRSB to Intel, AMD and ARM [...]

The Register (CloudFlare-protected) also has an article about SpectreRSB.

"The microarchitecture of Intel, AMD and VIA CPUs" (PDF) by Agner Fog (cited by Wikipedia) has further explanation of what a return stack buffer is:

A Last-In-First-Out buffer, called the return stack buffer, remembers the return address every time a call instruction is executed, and it uses this for predicting where the corresponding return will go. This mechanism makes sure that return instructions are correctly predicted when the same subroutine is called from several different locations. The P1 has no return stack buffer, but uses the same method for returns as for indirect jumps. Later processors have a return stack buffer. [...]


Original Submission

Related Stories

This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
(1)
  • (Score: 4, Interesting) by requerdanos on Tuesday July 31 2018, @12:06AM (4 children)

    by requerdanos (5997) Subscriber Badge on Tuesday July 31 2018, @12:06AM (#714987) Journal

    [The exploit] manipulates a new part of the process called the return stack buffer. [...] RSB is a common "predictor structure" in CPUs used to predict return addresses during the speculative execution process.

    I guess the bottom line questions is, how can an affected CPU protect against the exploit (in microcode, in software, in hardware design improvements) while still taking advantage of the speed improvement that comes from branch prediction?

    Researchers said they have reported SpectreRSB to Intel, AMD and ARM

    That takes care of the microcode and hardware design improvement notice, but what could be done, for example, at the operating system level (patching the OS kernel to cope, for example) or at the software level (writing your better-than-average security application with avoiding this type of exploit in mind)?

    Not that I personally would be likely to fully understand the answers (my programming is mostly in php and freebasic (translates basic to c for gcc)), but I'd like to know them and would like the people who are good programmers to be able to address them.

    • (Score: 3, Informative) by c0lo on Tuesday July 31 2018, @12:19AM (3 children)

      by c0lo (156) Subscriber Badge on Tuesday July 31 2018, @12:19AM (#714993) Journal

      Ever since PEEK/POKE programming on Sinclair Spectrum**, the lesson was clear to me: if your hardware can be accessed, it will.

      ** S80 and it's wonderful set of undocumented instructions.

      --
      https://www.youtube.com/watch?v=aoFiw2jMy-0
      • (Score: 3, Informative) by requerdanos on Tuesday July 31 2018, @01:57AM (1 child)

        by requerdanos (5997) Subscriber Badge on Tuesday July 31 2018, @01:57AM (#715026) Journal

        Ever since PEEK/POKE programming on Sinclair Spectrum

        I seem to recall having done some of the same. Not much of a computer but it worked.

        The memory model was very different though--you got it all. As I understand the newer memory models of the x86 and ARMish processors (which is to say not very well), bits of memory (segments? pages?) theoretically have (read, write, execute?) permissions per-(process? process group?) but as you say, if it can be accessed, it will.

        A process running on the local machine, now that you mention it, already has local access and doesn't have to break in, just sneak into the secret areas.

        Reminds me of the "hacker" long ago who got caught copying data without authorization by frequently asking for a scratch tape to be mounted and then reading its contents before writing to it, picking through other people's tempfiles. (In those days there was not only an access light, but a green "read" light and a red "write" light; I remember hard drives that had these two separate lights.)

        An operator apparently mounting the tapes thought it was odd that it came up green before red a lot, and thought to wonder why. (I maintain that picking through the trash is perfectly valid, if distasteful.)

        Surely we're beyond that now?

        • (Score: 2) by rylyeh on Tuesday July 31 2018, @03:35AM

          by rylyeh (6726) <{kadath} {at} {gmail.com}> on Tuesday July 31 2018, @03:35AM (#715053)

          In order to make the Apple ][ do anything, PEEK and POKE were necessary. When I learned later about 'protected mode' I Laughed! Apparently things are not so different now - Intel!

          --
          "a vast crenulate shell wherein rode the grey and awful form of primal Nodens, Lord of the Great Abyss."
      • (Score: 2) by c0lo on Tuesday July 31 2018, @07:41AM

        by c0lo (156) Subscriber Badge on Tuesday July 31 2018, @07:41AM (#715106) Journal

        (that was Z80, as in Zilog 80)

        --
        https://www.youtube.com/watch?v=aoFiw2jMy-0
(1)