Announcement

Collapse
No announcement yet.

Spectre / Meltdown Code Gets Cleaned Up, Improvements For Linux 4.16

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

  • Spectre / Meltdown Code Gets Cleaned Up, Improvements For Linux 4.16

    Phoronix: Spectre / Meltdown Code Gets Cleaned Up, Improvements For Linux 4.16

    After the page table isolation (K)PTI support was added late in the Linux 4.15 kernel cycle in light of the Meltdown CPU vulnerability, improvements to this code are on the way with Linux 4.16...

    http://www.phoronix.com/scan.php?pag...I-Improvements

  • #2
    What is Family 4 / 5 of the Intel Atom? Given Avoton is relatively new, that probably still has the issue.

    Comment


    • #3
      Does anyone actually have an overview regarding Spectre mitigation techniques? I'm curious about the performance impact of both, retpoline or the microcode based approach, and also how bad the performance impact of the microcode based approach is on different CPUs (given that Ryzen for instance should not need IBRS afaik).

      Also: Any news regarding the microcode update for Ryzen? The last microcode update was Epyc only afaik...

      Comment


      • #4
        Originally posted by ChamPro View Post
        What is Family 4 / 5 of the Intel Atom? Given Avoton is relatively new, that probably still has the issue.
        age does not matter. if it can't do speculative execution, it can't have bugs in speculative execution

        Comment


        • #5
          Originally posted by ChamPro View Post
          What is Family 4 / 5 of the Intel Atom? Given Avoton is relatively new, that probably still has the issue.
          https://en.wikipedia.org/wiki/Intel_Atom
          It probably means Pineview and Cedarview Atoms.

          Cedarview being the total bullshit "we didn't totally suck on CPU but we have PowerVR GPU and since IT is notoriously a bag of dicks we won't even have 64bit GPU drivers for windows, go figure how well the GPU runs in Linux". I remember the flaming Intel got for that screwup.

          Pineview were the first gen of Atoms that were somehow usable (with Linux anyway), at least back then, and also support a 64bit OS even if their memory controller can only use 2GB of ram total.

          But yeah, that's still Atoms from 2010. Modern smartphones run better than that.

          Comment


          • #6
            Originally posted by soulsource View Post
            Does anyone actually have an overview regarding Spectre mitigation techniques? I'm curious about the performance impact of both, retpoline or the microcode based approach, and also how bad the performance impact of the microcode based approach is on different CPUs (given that Ryzen for instance should not need IBRS afaik).

            Also: Any news regarding the microcode update for Ryzen? The last microcode update was Epyc only afaik...
            No microcode has availlable for ryzen and TR now, latest is only for 800F12 (Epyc).
            Flashed my B350 Tomahawk to latest 1.C4 beta bios (AGESA version: Raven PI 1.1.0.1), I saw the same microcode and always Spectre variante 1 vulnerable..
            Code:
            grep microcode /proc/cpuinfo                    
            microcode       : 0x8001129
            
            
            grep . /sys/devices/system/cpu/vulnerabilities/*
            /sys/devices/system/cpu/vulnerabilities/meltdown:Not affected
            /sys/devices/system/cpu/vulnerabilities/spectre_v1:Vulnerable
            /sys/devices/system/cpu/vulnerabilities/spectre_v2:Mitigation: Full AMD retpoline
            
            Spectre and Meltdown mitigation detection tool v0.33+
            
            Checking for vulnerabilities on current system
            Kernel is Linux 4.14.15-vanilla #1 SMP Wed Jan 24 22:00:42 CET 2018 x86_64
            CPU is AMD Ryzen 7 1700X Eight-Core Processor
            
            Hardware check
            * Hardware support (CPU microcode) for mitigation techniques
             * Indirect Branch Restricted Speculation (IBRS)
               * SPEC_CTRL MSR is available:  NO  
               * CPU indicates IBRS capability:  NO  
             * Indirect Branch Prediction Barrier (IBPB)
               * PRED_CMD MSR is available:  NO  
               * CPU indicates IBPB capability:  NO  
             * Single Thread Indirect Branch Predictors (STIBP)
               * SPEC_CTRL MSR is available:  NO  
               * CPU indicates STIBP capability:  NO  
             * Enhanced IBRS (IBRS_ALL)
               * CPU indicates ARCH_CAPABILITIES MSR availability:  NO  
               * ARCH_CAPABILITIES MSR advertises IBRS_ALL capability:  NO  
             * CPU explicitly indicates not being vulnerable to Meltdown (RDCL_NO):  NO  
             * CPU microcode is known to cause stability problems:  NO  
            * CPU vulnerability to the three speculative execution attacks variants
             * Vulnerable to Variant 1:  YES  
             * Vulnerable to Variant 2:  YES  
             * Vulnerable to Variant 3:  NO  
            
            CVE-2017-5753 [bounds check bypass] aka 'Spectre Variant 1'
            * Mitigated according to the /sys interface:  NO  (kernel confirms your system is vulnerable)
            > STATUS:  VULNERABLE  (Vulnerable)
            
            CVE-2017-5715 [branch target injection] aka 'Spectre Variant 2'
            * Mitigated according to the /sys interface:  YES  (kernel confirms that the mitigation is active)
            * Mitigation 1
             * Kernel is compiled with IBRS/IBPB support:  NO  
             * Currently enabled features
               * IBRS enabled for Kernel space:  NO  
               * IBRS enabled for User space:  NO  
               * IBPB enabled:  NO  
            * Mitigation 2
             * Kernel compiled with retpoline option:  YES  
             * Kernel compiled with a retpoline-aware compiler:  YES  (kernel reports full retpoline compilation)
             * Retpoline enabled:  YES  
            > STATUS:  NOT VULNERABLE  (Mitigation: Full AMD retpoline)
            
            CVE-2017-5754 [rogue data cache load] aka 'Meltdown' aka 'Variant 3'
            * Mitigated according to the /sys interface:  YES  (kernel confirms that your CPU is unaffected)
            * Kernel supports Page Table Isolation (PTI):  YES  
            * PTI enabled and active:  NO  
            * Running as a Xen PV DomU:  NO  
            > STATUS:  NOT VULNERABLE  (your CPU vendor reported your CPU model as not vulnerable)
            
            A false sense of security is worse than no security at all, see --disclaimer


            Last edited by scorpio810; 01-29-2018, 01:33 PM.

            Comment


            • #7
              I'm pretty sure there are no Atoms in Family 4 or 5, considering those families are comprised of 486 and original Pentium CPUs. All Atoms are family 6 or newer, however looking at the linked PR the unaffected Atoms have the following codenames: CEDARVIEW, CLOVERVIEW, LINCROFT, PENWELL and PINEVIEW.

              Comment


              • #8
                Originally posted by starshipeleven View Post
                Cedarview being the total bullshit "we didn't totally suck on CPU but we have PowerVR GPU and since IT is notoriously a bag of dicks we won't even have 64bit GPU drivers for windows, go figure how well the GPU runs in Linux". I remember the flaming Intel got for that screwup.

                Pineview were the first gen of Atoms that were somehow usable (with Linux anyway), at least back then, and also support a 64bit OS even if their memory controller can only use 2GB of ram total.
                And Diamondville Atoms (Family 3) being the "Hey, we can make this passively cooled half decent low power 64 bit x86 core. Let us pair it with a shitty power hungry northbridge (945GC), slap a whiny cooler on and call it day" ;-) However, I believe Diamondville was quite popular when paired with the more powerful Nvidia ION chipset.

                I recently changed my home server from an Atom 330 board to a Pentium G4400 and gained a 12 W saving - but apparently also got a Meltdown vulnerability.

                Is Diamondville affected?

                Comment


                • #9
                  Originally posted by ChamPro View Post
                  What is Family 4 / 5 of the Intel Atom? Given Avoton is relatively new, that probably still has the issue.
                  According to the code :

                  static const __initdata struct x86_cpu_id cpu_no_speculation[] = {
                  { X86_VENDOR_INTEL, 6, INTEL_FAM6_ATOM_CEDARVIEW, X86_FEATURE_ANY },
                  { X86_VENDOR_INTEL, 6, INTEL_FAM6_ATOM_CLOVERVIEW, X86_FEATURE_ANY },
                  { X86_VENDOR_INTEL, 6, INTEL_FAM6_ATOM_LINCROFT, X86_FEATURE_ANY },
                  { X86_VENDOR_INTEL, 6, INTEL_FAM6_ATOM_PENWELL, X86_FEATURE_ANY },
                  { X86_VENDOR_INTEL, 6, INTEL_FAM6_ATOM_PINEVIEW, X86_FEATURE_ANY },
                  { X86_VENDOR_CENTAUR, 5 },
                  { X86_VENDOR_INTEL, 5 },
                  { X86_VENDOR_NSC, 5 },
                  { X86_VENDOR_ANY, 4 },
                  {}
                  };

                  Comment


                  • #10
                    Originally posted by Veto View Post
                    And Diamondville Atoms (Family 3) being the "Hey, we can make this passively cooled half decent low power 64 bit x86 core. Let us pair it with a shitty power hungry northbridge (945GC), slap a whiny cooler on and call it day" ;-)
                    Yeah, I was amazed to see that a pretty normal industrial mini-itx board with a 8W Atom 330 processor was somehow burning 25W on idle and 30W on load.

                    Is Diamondville affected?
                    I severely doubt it. If later (better) Atoms still lacked that feature Diamondville could not have it either.

                    But still, the Pentium you got will still outperform the 330 on anything even after the software workarounds (with performance impact) are applied to the kernel, so it's not really worth it to pull up the old board.

                    Anyway, this is the relevant code from the patch:

                    Code:
                    +static const __initdata struct x86_cpu_id cpu_no_speculation[] = {
                    + { X86_VENDOR_INTEL, 6, INTEL_FAM6_ATOM_CEDARVIEW, X86_FEATURE_ANY },
                    + { X86_VENDOR_INTEL, 6, INTEL_FAM6_ATOM_CLOVERVIEW, X86_FEATURE_ANY },
                    + { X86_VENDOR_INTEL, 6, INTEL_FAM6_ATOM_LINCROFT, X86_FEATURE_ANY },
                    + { X86_VENDOR_INTEL, 6, INTEL_FAM6_ATOM_PENWELL, X86_FEATURE_ANY },
                    + { X86_VENDOR_INTEL, 6, INTEL_FAM6_ATOM_PINEVIEW, X86_FEATURE_ANY },
                    + { X86_VENDOR_CENTAUR, 5 },
                    + { X86_VENDOR_INTEL, 5 },
                    + { X86_VENDOR_NSC, 5 },
                    + { X86_VENDOR_ANY, 4 },
                    + {}
                    +};
                    +
                    +static const __initdata struct x86_cpu_id cpu_no_meltdown[] = {
                    + { X86_VENDOR_AMD },
                    + {}
                    +};
                    +
                    +static bool __init cpu_vulnerable_to_meltdown(struct cpuinfo_x86 *c)
                    +{
                    + u64 ia32_cap = 0;
                    +
                    + if (x86_match_cpu(cpu_no_meltdown))
                    + return false;
                    +
                    + if (cpu_has(c, X86_FEATURE_ARCH_CAPABILITIES))
                    + rdmsrl(MSR_IA32_ARCH_CAPABILITIES, ia32_cap);
                    +
                    + /* Rogue Data Cache Load? No! */
                    + if (ia32_cap & ARCH_CAP_RDCL_NO)
                    + return false;
                    +
                    + return true;
                    +}
                    +
                    There is a list of Atom families (and other obscure processors, like for VIA ones) that are whitelisted, "X86_VENDOR_INTEL, 5" should be the Intel Quark family of SoCs (Arduino Galileo and related embedded products), then AMD processors that don't have Meltdown because AMD, and then there is some logic looking for CPU features to determine if the CPU is susceptible to Meltdown.

                    Comment

                    Working...
                    X