Announcement

Collapse
No announcement yet.

Spectre Variant One Mitigations Will Be Sent In For Linux 4.16

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

  • Spectre Variant One Mitigations Will Be Sent In For Linux 4.16

    Phoronix: Spectre Variant One Mitigations Will Be Sent In For Linux 4.16

    The Linux 4.16 kernel will feature Spectre Variant One "Bounds Check Bypass" mitigations...

    http://www.phoronix.com/scan.php?pag...One-Linux-4.16

  • #2
    BTW Red Hat has mitigations for all 3 variants since day 1...

    Comment


    • #3
      Originally posted by oibaf View Post
      BTW Red Hat has mitigations for all 3 variants since day 1...
      You mean, with all firmwares also? For old and new CPU, Intel and AMD?

      I think that neither Windows have it for all these yet. For example Intel sent first batch at 15. january there for about 90% of CPUs produced in last 5 years, but they will look into older than 5 years CPUs only in february, etc...

      If Red Hat really have everything on day one, that would be a real news
      Last edited by dungeon; 01-20-2018, 07:01 PM.

      Comment


      • #4
        Originally posted by dungeon View Post

        You mean, with all firmwares also? For old and new CPU, Intel and AMD?

        I think that neither Windows have it for all these yet.
        They also provided firmware, but it was replaced by older version due to possible reboot. This is what I get on a RH6:

        # ./spectre-meltdown--23ef32a.sh

        This script is primarily designed to detect Spectre / Meltdown on supported
        Red Hat Enterprise Linux systems and kernel packages.
        Result may be inaccurate for other RPM based systems.

        Detected CPU vendor: Intel
        Running kernel: 2.6.32-696.18.7.el6.x86_64

        Variant #1 (Spectre): Mitigated
        CVE-2017-5753 - speculative execution bounds-check bypass
        - Kernel with mitigation patches: OK

        Variant #2 (Spectre): Vulnerable
        CVE-2017-5715 - speculative execution branch target injection
        - Kernel with mitigation patches: OK
        - HW support / updated microcode: NO
        - IBRS: Not disabled on kernel commandline
        - IBPB: Not disabled on kernel commandline

        Variant #3 (Meltdown): Mitigated
        CVE-2017-5754 - speculative execution permission faults handling
        - Kernel with mitigation patches: OK
        - PTI: Not disabled on kernel commandline

        Red Hat recommends that you:
        * Ask your HW vendor for CPU microcode update.

        For more information see:
        https://access.redhat.com/security/v...ativeexecution

        Comment


        • #5
          with all this mitigations, monolithic kernels will be that slow, we could be using micro kernels for improved stability and easier development in the first place :-/

          Comment


          • #6
            Originally posted by oibaf View Post

            They also provided firmware, but it was replaced by older version due to possible reboot. This is what I get on a RH6:
            OK that, so there is no microcodes there too yet...

            Firmware Updates

            We have now issued firmware updates for 90 percent of Intel CPUs introduced in the past five years, but we have more work to do. As I noted in my blog post last week, while the firmware updates are effective at mitigating exposure to the security issues, customers have reported more frequent reboots on firmware updated systems.

            As part of this, we have determined that similar behavior occurs on other products in some configurations, including Ivy Bridge-, Sandy Bridge-, Skylake-, and Kaby Lake-based platforms. We have reproduced these issues internally and are making progress toward identifying the root cause. In parallel, we will be providing beta microcode to vendors for validation by next week.
            https://newsroom.intel.com/news/firm...enter-systems/

            Also, since for older CPUs they will look only in february, it is obvious all this is planned and will going to be multi-month process, so there is no really magic "day one - all fixed" there
            Last edited by dungeon; 01-20-2018, 09:30 PM.

            Comment


            • #7
              And as of now, not a single real attack vector has been found in practice. Reminds me of a strange paradox in mathematics where a certain sub-set of algebra was proven to always have more efficient solutions than the larger set for a certain problem, proven by generality, but no one had ever come up with an actual (non-trivial) example.

              Sure, there might be plenty of zero-day attack vectors out there, but I got this feeling this is a case of over-reaction. Not meltdown, but spectre. Spectre seems like this theoretically vulnerable in theory construct, for which no one is ever going to come up with an actual usable attack.

              edit: added (non-trivial)

              Comment


              • #8
                Originally posted by AndyChow View Post
                And as of now, not a single real attack vector has been found in practice. Reminds me of a strange paradox in mathematics where a certain sub-set of algebra was proven to always have more efficient solutions than the larger set for a certain problem, proven by generality, but no one had ever come up with an actual (non-trivial) example.

                Sure, there might be plenty of zero-day attack vectors out there, but I got this feeling this is a case of over-reaction. Not meltdown, but spectre. Spectre seems like this theoretically vulnerable in theory construct, for which no one is ever going to come up with an actual usable attack.

                edit: added (non-trivial)
                SPECTRE was kicked off by a proof of concept attack for native code and javascript. if I recall correctly the explanation on how to exploit it is in the paper.

                Comment


                • #9
                  Originally posted by boxie View Post

                  SPECTRE was kicked off by a proof of concept attack for native code and javascript. if I recall correctly the explanation on how to exploit it is in the paper.
                  Proof of concept != proof of attack. Yeah, it can work in the laboratory, but no one has actually used in in the field. You should re-read my initial comment. Just because something is theoretically vulnerable, does not mean it's practically so. And practically here means "in practice".

                  Comment


                  • #10
                    Originally posted by rene View Post
                    with all this mitigations, monolithic kernels will be that slow, we could be using micro kernels for improved stability and easier development in the first place :-/
                    can you elaborate on that? i fail to see how os design matters here

                    Comment

                    Working...
                    X