Announcement

Collapse
No announcement yet.

MDS: The Newest Speculative Execution Side-Channel Vulnerability

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

  • #21
    [QUOTE=dungeon;n1098876]
    Code:
    :~$ cat /sys/devices/system/cpu/vulnerabilities/mds
    Not affected
    Is that a thing? Something you have installed?

    Comment


    • #22
      Originally posted by flower View Post
      well we have a new kernel now. does anybody know how to disable the mitigation?
      It looks like they backported
      Code:
      mitigations=
      option to longterm and stable kernel versions.

      https://git.kernel.org/pub/scm/linux...ad9a34329903ff

      Comment


      • #23
        Originally posted by Kimmono View Post
        Originally posted by dungeon View Post
        Code:
        :~$ cat /sys/devices/system/cpu/vulnerabilities/mds
        Not affected
        Is that a thing? Something you have installed?
        If you upgrade to kernel 5.1.2 (or one of the stable series 5.0.16, 4.9.43, etc.) then you will get /sys/devices/system/cpu/vulnerabilities/mds
        And "Not affected" are all CPUs that have NO_MDS flag set according to arch/x86/kernel/cpu/common.c

        Comment


        • #24
          Originally posted by wpupkin View Post

          It looks like they backported
          Code:
          mitigations=
          option to longterm and stable kernel versions.

          https://git.kernel.org/pub/scm/linux...ad9a34329903ff
          sadly this does nothing atm. from your link:
          Currently, these options are placeholders which don't actually do anything. They will be fleshed out in upcoming patches.

          Comment


          • #25
            If this goes on, Michael will need to change his benchmarking suite at some point to include the Commodore 64.

            Comment


            • #26
              I don't understand how can a mitigation be implemented at all. The only option is to disable Hyperthreading.

              Can anybody point me to the full description of this exploit, including ASM and C code snippets. Where is the link to the original article by the people who discovered the bug?

              These CPU manufacturers are really shady. I mean, letting these kind of bugs slip through is utterly irresponsible and shamefull. How could they not see it? It looks like greed to the nth power to me.
              But if I can't trust my CPU, then I have to throw the computer in the garbage. This is completely unacceptable.

              And in the end, we all have to place out trust in our CPUs for everything we do, including online payment and our private data.

              What's the status on RISC V? Still too slow? Perhaps ARM Cortex-A76?
              Last edited by xfcemint; 05-14-2019, 10:45 PM.

              Comment


              • #27
                Here is the original paper...

                https://zombieloadattack.com/zombieload.pdf

                Comment


                • #28
                  Originally posted by flower View Post

                  sadly this does nothing atm. from your link:
                  ...
                  I picked a first patch in series, there are "upcoming patches": https://git.kernel.org/pub/scm/linux...og/?h=v4.19.43
                  But, tbh, not tested this yet.

                  Comment


                  • #29
                    Originally posted by xfcemint View Post
                    I don't understand how can a mitigation be implemented at all. The only option is to disable Hyperthreading.
                    No. Disabling HyperThreading is one mitigation which prevents data leaking from trusted to untrusted processes/VMs. It does however not prevent data leaking from kernel to userspace (cf. https://www.cyberus-technology.de/po...ion-techniques).

                    Originally posted by xfcemint View Post
                    These CPU manufacturers are really shady. I mean, letting these kind of bugs slip through is utterly irresponsible and shamefull. How could they not see it? It looks like greed to the nth power to me.
                    It is actually much worse. Intel knew about this bug for a year (first report in June 2018), but said nothing and continued to sell vulnerable CPUs to unsuspecting customers.
                    During that time, several researchers independently rediscovered these vulnerabilities. Malicious actors could have, too.
                    Originally posted by https://www.mdsattacks.com/
                    Multiple teams and researchers independently discovered, studied, and reported MDS-class vulnerabilities and attacks to Intel. Unfortunately, the different timelines (see below), as well as the fine-grained vulnerability classification and embargo strategy enforced by Intel (which coordinated the disclosure process) made proper coordination across teams impossible. The year-long disclosure process (the longest to date) ultimately resulted in independent finders of even closely related MDS-class vulnerabilities to be completely unaware of one another until a few days before the May 14 disclosure date. We worked with Intel to make sure we'd give proper credit to everyone involved in the disclosure of these vulnerabilities, both in our papers and on this website. This website is our last-minute effort to coordinate the different teams, presenting the two independent papers (and counting?) on RIDL and Fallout.

                    Comment


                    • #30
                      Jesus Christ....

                      The FLOSS community must step up the hardware game badly...

                      We need RiscV fully functional ASAP.
                      ‚Äč

                      Comment

                      Working...
                      X