Announcement

Collapse
No announcement yet.

Cross-Hyperthread Spectre V2 Mitigation Ready For Linux With STIBP

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

  • Cross-Hyperthread Spectre V2 Mitigation Ready For Linux With STIBP

    Phoronix: Cross-Hyperthread Spectre V2 Mitigation Ready For Linux With STIBP

    On the Spectre front for the recently-started Linux 4.20~5.0 kernel is STIBP support for cross-hyperthread Spectre Variant Two mitigiation...

    http://www.phoronix.com/scan.php?pag...X-HT-STIBP-420

  • #2
    Typo:

    Originally posted by phoronix View Post
    Spectre Variant Two mitigiation.

    Comment


    • #3
      Most common questions?
      - How do I turn off all the mitigation crap that possibly impedes execution speed?
      - Do all these mitigations fall under one "turn off"-flag?

      Comment


      • #4
        Originally posted by milkylainen View Post
        Most common questions?
        - How do I turn off all the mitigation crap that possibly impedes execution speed?
        - Do all these mitigations fall under one "turn off"-flag?
        There is no make_my_kernel_insecure=on flag.

        CVE-2017-5753 aka 'Spectre Variant 1, bounds check bypass' - not possible
        CVE-2017-5715 aka 'Spectre Variant 2, branch target injection' - spectre_v2=off
        CVE-2017-5754 aka 'Variant 3, Meltdown, rogue data cache load' - pti=off
        CVE-2018-3640 aka 'Variant 3a, rogue system register read' - microcode, roll back BIOS/don't install intel_microcode
        CVE-2018-3639 aka 'Variant 4, speculative store bypass' - spec_store_bypass_disable=off
        CVE-2018-3615 aka 'Foreshadow (SGX), L1 terminal fault' - microcode, roll back BIOS/don't install intel_microcode
        CVE-2018-3620 aka 'Foreshadow-NG (OS), L1 terminal fault' - l1tf=off
        CVE-2018-3646 aka 'Foreshadow-NG (VMM), L1 terminal fault' - l1tf=off

        There's also patches to compilers. To be honest disabling anything but perhaps pti if you're very I/O bound is probably not a good idea

        Comment


        • #5
          Originally posted by numacross View Post

          There is no make_my_kernel_insecure=on flag.

          CVE-2017-5753 aka 'Spectre Variant 1, bounds check bypass' - not possible
          CVE-2017-5715 aka 'Spectre Variant 2, branch target injection' - spectre_v2=off
          CVE-2017-5754 aka 'Variant 3, Meltdown, rogue data cache load' - pti=off
          CVE-2018-3640 aka 'Variant 3a, rogue system register read' - microcode, roll back BIOS/don't install intel_microcode
          CVE-2018-3639 aka 'Variant 4, speculative store bypass' - spec_store_bypass_disable=off
          CVE-2018-3615 aka 'Foreshadow (SGX), L1 terminal fault' - microcode, roll back BIOS/don't install intel_microcode
          CVE-2018-3620 aka 'Foreshadow-NG (OS), L1 terminal fault' - l1tf=off
          CVE-2018-3646 aka 'Foreshadow-NG (VMM), L1 terminal fault' - l1tf=off

          There's also patches to compilers. To be honest disabling anything but perhaps pti if you're very I/O bound is probably not a good idea
          Thanks a bunch.
          The machines are on a closed net and used for execution speed. Custom kernels.
          We are deliberately trading security for execution speed in that instance.

          So a big fat knob would have been much nicer. A "Stop fudging exec speed to mitigate broken hardware"-button.
          I am not against security. I'm against fubars that cost me execution speed and is now becoming a mandatory exec path.
          I see these CPU's as broken hardware. I don't want fixes for broken hardware as mandatory code paths that cost exec speed.

          Comment


          • #6
            The link "this cross-hyperthread Spectre V2 mitigation with STIBP" is broken - it's got "h" and "ref" rather than "href".

            Comment

            Working...
            X