Announcement

Collapse
No announcement yet.

Security Researchers Detail New "BlindSide" Speculative Execution Attack

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

  • #31
    Originally posted by bison View Post

    I wonder how many more years it will be until the realization comes: "We need to give up on speculation."
    I wonder how many more years before the CPU manufacturers realize that they can offer a user-controlled option to disable speculation (a so-called "chicken bit") and carve out a niche marked there of customers who value additional security.

    Or, more precisely, the option "do not speculate outside of registers and ALU". Like, don't speculate on L1, on memory in general, on jump target addresses, or anything external to the main execution unit.

    I mean, the hardware doesn't need to change much at all, it's mostly a microcode update. And, of course, a lot of testing is required there on the side of the manufacturer.

    I think they are just dumb.

    Comment


    • #32
      Originally posted by xfcemint View Post
      Also, speculation is safe if done just on registers and a few buffers close to the ALU. The problem with current CPUs is that manufacturers are relentlessly and dangerously speculating on every shit they can think of to get out that last 1% performance. Than the CPU looks good on benchmarks when it is released.
      One of the variants of Spectre is called Rogue System Register Read so I wouldn't be so sure registers are safe. On top of that the Cortex-A57 at least is vulnerable to Spectre-3a as well which is basically "meltdown but for registers".

      Comment


      • #33
        Originally posted by Amaranth View Post

        One of the variants of Spectre is called Rogue System Register Read so I wouldn't be so sure registers are safe. On top of that the Cortex-A57 at least is vulnerable to Spectre-3a as well which is basically "meltdown but for registers".
        Well, yes and no.

        The problem with meltdown is that a CPU has an "unroll" functionality that is unsafe with regards to Spectre. So, basic problem is not that a CPU is speculating on registers, but a dangerous additional functionality that it supports (btw. that same idiotic "unroll" had a myriad of bugs previously and Intel couldn't fix it for four generations of their CPU cores).

        Same with Rogue System Register Read. The result is that you can read a privileged register contents, but the basic problem is not that you are speculating on contents of registers, but an improper and dangerous handling of some buffers (Intel again). I might be mistaken here, the issue is complex, and I'm not a security expert or a CPU designer, I'm just a programmer.

        I can agree with you that completely disabling speculative execution is an even safer option than what I originally said. Therefore, why wouldn't there be another chicken bit for such an option? Of course, completely disabling SE brings a 5-30% performance penalty, depending on application. Partially disabling SE would have a definitively and measurably smaller impact.

        And, of couse, hyperthreading is also a security nightmare that should have a disable option.

        Comment


        • #34
          Originally posted by xfcemint View Post
          I wonder how many more years before the CPU manufacturers realize that they can offer a user-controlled option to disable speculation (a so-called "chicken bit") and carve out a niche marked there of customers who value additional security.
          Don't we already have something like that with chips that employ ARM's big.LITTLE architecture?
          Last edited by ed31337; 11 September 2020, 08:21 PM.

          Comment


          • #35
            Originally posted by Amaranth View Post

            One of the variants of Spectre is called Rogue System Register Read so I wouldn't be so sure registers are safe. On top of that the Cortex-A57 at least is vulnerable to Spectre-3a as well which is basically "meltdown but for registers".
            Let me post a more concise answer:

            If SE outside of CPU registers was disabled, would it still be possible to successfully execute the atacks based on vulnerabilities you are mentioning?

            Meldown is dependent on reading from cache, so I reckon it is not possible to do meldown. Of couse, for a true answer, a deep analysis would de required.

            Comment


            • #36
              Originally posted by ed31337 View Post

              Don't we already have something like that with chips that employ ARM's big.LITTLE architecture?
              Yes, we do, but a penalty is huge: currently, LITTLE cores are almost 3 times slower than BIG cores. Just disabling SE has a much, much smaller impact.

              Comment


              • #37
                Originally posted by CochainComplex View Post
                so where are the non speculative CPU's? is it still possible or will this push us back to pre-P4 era (performancewise)?
                In-order designs with today's performance won't be possible unless we break the memory wall.

                On the other hand, with the performance impact of mitigating those flaws we'd be better off with an overclocked 486 + modern extensions.

                Comment


                • #38
                  Originally posted by elatllat View Post
                  So The Odroid C4 running RedoxOS would be the most secure, performant option. Amazon/Apple/Microsoft all have custom ARM chips and more money than everyone else, it would be nice if they stepped in and fixed this mess. (Intel and AMD can't be botherd apparently)
                  That would be a very secure combo in theory.

                  Comment


                  • #39
                    does it work on android too? i don't mind waiting a few minutes to get root access

                    Comment


                    • #40
                      Looks like using full ASLR mitigates quite well (but not fully) the issue. Debian has switched to it, just like many common distros. PIE executables are now the norm, not the exception.

                      Comment

                      Working...
                      X