Announcement

Collapse
No announcement yet.

Google Engineers Argue For Linux "ASI" To Better Deal With Speculative Execution Attacks

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

  • #21
    Originally posted by NobodyXu View Post
    But there's still Javascript and Wasm that could run on your web browser.
    Except it doesn't have the timing precision required to pull this off.

    Comment


    • #22
      Originally posted by Vorpal View Post
      I would love if it was possible to only apply mitigations to certain processes. I.e. Windows VMs and the browser.
      If Windows supports the mitigations than it should be fine in a VM as long as you keep it on separate cores that your unmitigated OS doesn't touch. Also Qemu/KVM has some mitigation options that are on per default.
      If you run your browser in such a VM (with Linux this time) it should also be fine.

      Comment


      • #23
        Originally posted by V1tol View Post
        You could not make more bold statement lol. Unless you have CPU, firmware, OS and all the software reviewed by your bare eyes.
        and "all the software" includes all the JS and wasm running in a web browser.

        Originally posted by Vorpal View Post
        I suspect (after thinking about it for 10 seconds, so take it with a grain of salt) that meltdown might be possible to mitigate per process in theory. Spectre and retbleed probably not.
        protecting the kernel from spectre/meltdown attacks from user space can't be down per-process, but per-process mitigation is the default for Spectre between userspace processes on Linux. only processes that request mitigations through prctl get mitigations, the rest are left vulnerable.

        ​​​​​​​
        Originally posted by Weasel View Post
        Except it doesn't have the timing precision required to pull this off.
        https://gruss.cc/files/fantastictimers.pdf

        Comment


        • #24
          Originally posted by Weasel View Post
          Except it doesn't have the timing precision required to pull this off.
          I remembered reading that the researcher was able to pull off a timing based attack in javascript...

          Comment


          • #25
            browsers had to impair js timers on purpose as a temporary measure to avoid js exploitation of spectre when it first came up... back then they intended to give js back the ability to use more precise timers, but since the vulnerabilities didn't stop popping up those degraded timers might still be in place...

            ...and then there is dev ingenuity, crafting ways to increase timer precision by joining several methods creatively, etc... so that was explicitly only a stopgap measure to buy OSs time to devise more proper mitigations

            Comment


            • #26
              Doesn't speculative attack require very longtime to acctually extract enformation? Like a few bytes per second and needs quite a lot to decrypt anything meaningful?
              If that's the case maybe periodically restart browser is all we need as desktop users running random js?

              Comment


              • #27
                Originally posted by lilunxm12 View Post
                Doesn't speculative attack require very longtime to acctually extract enformation? Like a few bytes per second and needs quite a lot to decrypt anything meaningful?
                If that's the case maybe periodically restart browser is all we need as desktop users running random js?
                Even temporarily closing the tabs of untrusted websites might work.
                But seriously though, I don't think a lot of people can do that.

                Comment


                • #28
                  Originally posted by NobodyXu View Post

                  Even temporarily closing the tabs of untrusted websites might work.
                  But seriously though, I don't think a lot of people can do that.
                  Or browser vendors could develop a deep refresh feature, restart the page in a new process and close the old one. Then we could use those existing tab refresher extensions.

                  Comment


                  • #29
                    Originally posted by lilunxm12 View Post
                    Doesn't speculative attack require very longtime to acctually extract enformation? Like a few bytes per second and needs quite a lot to decrypt anything meaningful?
                    If that's the case maybe periodically restart browser is all we need as desktop users running random js?
                    most of the things people would want to steal (credentials, encryption keys, etc.) are only a few bytes. restarting your browser more than once per second is probably not something that most people would want to do.

                    Comment


                    • #30
                      Originally posted by lilunxm12 View Post

                      Or browser vendors could develop a deep refresh feature, restart the page in a new process and close the old one. Then we could use those existing tab refresher extensions.
                      Emmm, it's a bad idea to do this without user consent, because this would basically reset any state of the page rendered.
                      If you are doing banking or performing some critical operations that uses Javascript, then refreshing would cause all these pages to be invalidated and potentially requires you to start from scratch to refill information.

                      Providing an API so that some plugins to do it might be OK, but still the performance of this is going to be terrible.

                      Comment

                      Working...
                      X