Announcement

Collapse
No announcement yet.

L1TF / Foreshadow Mitigations Land In Linux 4.18 / 4.17 / 4.14 / 4.9 / 4.4 Kernel Update

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

  • L1TF / Foreshadow Mitigations Land In Linux 4.18 / 4.17 / 4.14 / 4.9 / 4.4 Kernel Update

    Phoronix: L1TF / Foreshadow Mitigations Land In Linux 4.18 / 4.17 / 4.14 / 4.9 / 4.4 Kernel Update

    Linux stable maintainer Greg Kroah-Hartman has released new updates across the Linux 4.18, 4.17, 4.14, 4.9, and 4.4 kernel channels to address the recently exposed L1 Terminal Fault "L1TF" / Foreshadow Meltdown-like CPU vulnerability affecting Intel processors...

    http://www.phoronix.com/scan.php?pag...Kernel-Updates

  • #2
    You can add l1tf=off to your kernel boot parameters to disable this.

    And for those who like to live dangerously:

    GRUB_CMDLINE_LINUX_DEFAULT="quiet pti=off spectre_v2=off l1tf=off"

    I believe spectre_v1 is baked in and can't be flipped off. If you disable these, please be responsible. Use Strict Site Isolation in web browsers, don't run random code downloaded from the net, etc. I'm the only one who uses my desktop (that I know of) and it's mostly for development, gaming, and browsing so feel free to assess your own situation.

    ~ ❯ uname -a
    Linux ubuntu 4.18.1-041801+custom-generic #041801+201808151233 SMP PREEMPT Thu Aug 16 08:46:03 PDT 2018 x86_64 x86_64 x86_64 GNU/Linux

    ~ ❯ cat /sys/devices/system/cpu/vulnerabilities/l1tf
    Mitigation: PTE Inversion; VMX: vulnerable, SMT disabled

    Comment


    • #3
      Considering Spectre V4 and now L1TF only have conditional fixes, with permanent fixes being off by default and too performance degrading to always be on... also considering I do run closed source programs like a Slack or two, I'm going to be upgrading to Ryzens sooner rather than later.

      Comment


      • #4
        Fantastic! Soon we're gonna have super secure Intel Core i series CPUs that are approaching Core 2 performance. Yay!

        Comment


        • #5
          Originally posted by perpetually high View Post
          And for those who like to live dangerously:

          GRUB_CMDLINE_LINUX_DEFAULT="quiet pti=off spectre_v2=off l1tf=off"
          Don't forget nospec_store_bypass_disable no_stf_barrier

          Comment


          • #6
            Originally posted by xorbe View Post

            Don't forget nospec_store_bypass_disable no_stf_barrier
            Ah, thank you sir. I just added no_stf_barrier.

            I was looking up the other one, nospec_store_bypass_disable. And from SUSE pages it says:

            The mitigation is by default disabled, and can be enabled by user programs using the prctl() system call, and is default enabled for applications using "seccomp" filtering, like openssh, vsftpd and chromium.
            nospec_store_bypass_disable and spec_store_bypass_disable=off


            The mitigation is disabled.
            spec_store_bypass_disable=on


            So I think the parameter should be spec_store_bypass_disable=on. Confusing with the double negatives.

            My final list of boot parameters looks like this:

            GRUB_CMDLINE_LINUX_DEFAULT="quiet pti=off spectre_v2=off l1tf=off spec_store_bypass_disable=on no_stf_barrier"

            Let me know if that doesn't look correct

            Comment


            • #7
              isn't the default disable = spec_store_bypass_disable=off

              so spec_store_bypass_disable=on actually enables the mitigation

              Comment


              • #8
                Originally posted by eva2000 View Post
                isn't the default disable = spec_store_bypass_disable=off

                so spec_store_bypass_disable=on actually enables the mitigation
                You're right, thanks. Came back to update my post and saw yours instead. Verified it with spectre-meltdown-checker.

                So my grub looks like this:

                GRUB_CMDLINE_LINUX_DEFAULT="quiet pti=off spectre_v2=off l1tf=off nospec_store_bypass_disable no_stf_barrier"

                spectre-meltdown-checker.sh shows (trimmed down):

                CVE-2017-5753 [bounds check bypass] aka 'Spectre Variant 1'
                * Mitigated according to the /sys interface: YES (Mitigation: __user pointer sanitization)
                > STATUS: NOT VULNERABLE (Mitigation: __user pointer sanitization)

                CVE-2017-5715 [branch target injection] aka 'Spectre Variant 2'
                > STATUS: VULNERABLE (IBRS+IBPB or retpoline+IBPB is needed to mitigate the vulnerability)

                CVE-2017-5754 [rogue data cache load] aka 'Meltdown' aka 'Variant 3'
                > STATUS: VULNERABLE (PTI is needed to mitigate the vulnerability)

                CVE-2018-3640 [rogue system register read] aka 'Variant 3a'
                > STATUS: VULNERABLE (an up-to-date CPU microcode is needed to mitigate this vulnerability)

                CVE-2018-3639 [speculative store bypass] aka 'Variant 4'
                > STATUS: VULNERABLE (Your CPU doesn't support SSBD)

                CVE-2018-3615/3620/3646 [L1 terminal fault] aka 'Foreshadow & Foreshadow-NG'
                > STATUS: NOT VULNERABLE (Mitigation: PTE Inversion; VMX: vulnerable, SMT disabled)

                The last one, L1 terminal fault, with l1tf=off will get you VMX: vulernable, if you put l1tf=on, it'll be VMX: Mitigated.

                The first one, not sure how to bypass that, possibly baked in. I'm on Haswell and I reverted my microcode back to 22 as well. (23 was the first one with Spectre mitigations, 25 just came out a few days ago). Probably a bit extreme, but Haswell is a bit old at this point, and any new microcode after Spectre can't possibly be beneficial if I'm disabling all the mitigations lol.

                Comment

                Working...
                X