Announcement

Collapse
No announcement yet.

Intel Prepares "Enhanced IBRS" As Better Spectre V2 Protection For Future CPUs

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

  • #11
    the fact that intel can't even fix these vulnerabilities ( amd and zen 2 seem to be doing better ) after the fact just makes me more confused over how even high performance ( with branch prediction ) risc v cores are immune to them

    Comment


    • #12
      Originally posted by phoronix View Post
      there has been some speculation that Intel may have this ready within approximately one year
      I see what ya did there Michael.

      Comment


      • #13
        Originally posted by andyprough View Post
        There's medications for irritable bowel syndrome.
        Is there really?

        Comment


        • #14
          Originally posted by GunpowaderGuy View Post
          the fact that intel can't even fix these vulnerabilities ( amd and zen 2 seem to be doing better ) after the fact just makes me more confused over how even high performance ( with branch prediction ) risc v cores are immune to them
          RISC-V is an ISA, RISC-V actual hardware will differ from each other.

          Same as AMD x86 CPUs aren't similar to Intel and aren't 100% affected by everything that affects Intel processors.

          This means that RISC-V per-se isn't immune, but current RISC-V designs are immune due to their actual hardware design. There can be RISC-V designs that are vulnerable, as it depends from the hardware design itself.

          Intel can't fix this easily as they need to change something fundamental in their architecture and that requires time and skill to pull off right. Assuming they want to, as I'm sure they can't provide safety without sacrificing performance, so I think they are settling on a "let the consumer choose" kind of deal where they have mitigations that can be disabled if you don't need security.

          Comment


          • #15
            Originally posted by Mthw View Post

            Is there really?
            Read the latest on serious health-related issues and what you can do about them. Hear success stories from people who were helped by the McDougall Program.

            Comment


            • #16
              Originally posted by starshipeleven View Post
              RISC-V is an ISA, RISC-V actual hardware will differ from each other.

              Same as AMD x86 CPUs aren't similar to Intel and aren't 100% affected by everything that affects Intel processors.

              This means that RISC-V per-se isn't immune, but current RISC-V designs are immune due to their actual hardware design. There can be RISC-V designs that are vulnerable, as it depends from the hardware design itself.

              Intel can't fix this easily as they need to change something fundamental in their architecture and that requires time and skill to pull off right. Assuming they want to, as I'm sure they can't provide safety without sacrificing performance, so I think they are settling on a "let the consumer choose" kind of deal where they have mitigations that can be disabled if you don't need security.
              I'm wondering why can't they just make rdtsc or other high-performance counters very imprecise (at the micro-second level and above) so that such attacks are completely eliminiated? They all rely on timing to extract information to see whether it was in the cache or not.

              I just don't get it why not just make rdtsc with a lot of jitter and other hardware timers and solve it forever.

              Obviously this should be a thing able to be controlled by the kernel, so that apps that rely on precise timing measurements can be given the privilege of "exact" timing results instead of having it with random jitter.


              tl;dr; reduce precision of the timers to micro-second levels by default, and you solve the problem. Make it so that the kernel can control this per process and can give a process exact precision if needed (needless to say you should only use that on processes you trust!)

              Comment


              • #17
                Originally posted by Weasel View Post
                I'm wondering why can't they just make rdtsc or other high-performance counters very imprecise (at the micro-second level and above) so that such attacks are completely eliminiated?
                Because that's the whole point of high-performance counter to be precise. One thing is when Chrome does this trickery on javascript, because javascript can be assumed to not be particularly critical code, another is when an OS is doing this on everything.

                Obviously this should be a thing able to be controlled by the kernel, so that apps that rely on precise timing measurements can be given the privilege of "exact" timing results instead of having it with random jitter.
                Who knows what applications need it? I)'m ready to bet that it would cause a ton of breakage until people figure out this.

                Lol and all the applications that will require this even without any logical reason to... oooh it will be awesome.
                Last edited by starshipeleven; 25 July 2018, 08:34 AM.

                Comment


                • #18
                  Originally posted by starshipeleven View Post
                  Because that's the whole point of high-performance counter to be precise.
                  Yeah, and the whole point of root is to have access to everything on your machine (usually). It doesn't mean it's a good idea to give it to every application.

                  Originally posted by starshipeleven View Post
                  Who knows what applications need it? I)'m ready to bet that it would cause a ton of breakage until people figure out this.
                  You can always just set the capability by default to every application if you don't want to bother with selective whitelisting, you won't be less secure than right now. But proper security practice is to deny by default and only selectively allow, obviously it doesn't mean everyone follows it, nor is it required with my idea.

                  Even if an app relies on timers, it doesn't mean it relies on precision in them, necessarily. The amount of breakage would be pretty low, IMO (except for critical apps but you already give those full access anyway, since they're "critical").

                  Or just set it only for untrusted apps (like those with internet access), others can't really spy on you if they're offline anyway. A lot of possibilities.

                  Comment


                  • #19
                    Originally posted by Weasel View Post
                    Yeah, and the whole point of root is to have access to everything on your machine (usually). It doesn't mean it's a good idea to give it to every application.
                    Not what I meant. I meant that you either provide the instruction or CLEARLY error out and refuse to. If you provide crappy timers to applications requiring them you will only cause breakage that is extremely annoying to debug.

                    You can always just set the capability by default to every application if you don't want to bother with selective whitelisting, you won't be less secure than right now. But proper security practice is to deny by default and only selectively allow, obviously it doesn't mean everyone follows it, nor is it required with my idea.
                    This will only mean that none will give a shit. Leaving the user to choose usually means that default options remain.

                    Even if an app relies on timers, it doesn't mean it relies on precision in them, necessarily.
                    I'm not talking of things the developer knows, but things the developer does not know. Timers are commonly used in many applications, you don't know how smartly or how fucking stupidly.

                    Or just set it only for untrusted apps (like those with internet access), others can't really spy on you if they're offline anyway. A lot of possibilities.
                    Yeah, because the others can't just initiate a network connection because of a code injection or something.

                    Your thinking works only in modern OSes like Android where apps that don't need internet access actually don't have that permission, so even if compromised will NOT be able to access the internet anyway.

                    Comment


                    • #20
                      Originally posted by RealNC View Post
                      Since these are future CPUs, shouldn't they be fixing the problem instead of mitigating it?
                      Itanium was born (and died) too soon.

                      Comment

                      Working...
                      X