Announcement

Collapse
No announcement yet.

Google Uncovers CPU Bug For Geminilake, Affecting At Least Firefox & Chrome

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

  • #21
    I have one of these CPUs. Like most implementations of Gemini Lake, my CPU is soldered to the motherboard. So begging Intel to replace just ain't gonna happen unless the motherboard manufacturer also gets onboard, which is doubtful.

    Besides, having a CPU bug fixed in software would not be uncommon for this CPU family or any other CPU family that is vulnerable to any number of more widely seen CPU bugs like "spectre" and "meltdown" and so on.

    See the following "lscpu" output:

    Code:
    Linux j5005 5.2.0-3-amd64 #1 SMP Debian 5.2.17-1 (2019-09-26) x86_64
    Last login:
    j5005 ~ # lscpu
    Architecture:                    x86_64
    CPU op-mode(s):                  32-bit, 64-bit
    Byte Order:                      Little Endian
    Address sizes:                   39 bits physical, 48 bits virtual
    CPU(s):                          4
    On-line CPU(s) list:             0-3
    Thread(s) per core:              1
    Core(s) per socket:              4
    Socket(s):                       1
    NUMA node(s):                    1
    Vendor ID:                       GenuineIntel
    CPU family:                      6
    Model:                           122
    Model name:                      Intel(R) Pentium(R) Silver J5005 CPU @ 1.50GHz
    Stepping:                        1
    CPU MHz:                         803.447
    CPU max MHz:                     2800.0000
    CPU min MHz:                     800.0000
    BogoMIPS:                        2995.20
    Virtualization:                  VT-x
    L1d cache:                       96 KiB
    L1i cache:                       128 KiB
    L2 cache:                        4 MiB
    NUMA node0 CPU(s):               0-3
    Vulnerability L1tf:              Not affected
    Vulnerability Mds:               Not affected
    Vulnerability Meltdown:          Mitigation; PTI
    Vulnerability Spec store bypass: Mitigation; Speculative Store Bypass disabled via prctl and seccomp
    Vulnerability Spectre v1:        Mitigation; usercopy/swapgs barriers and __user pointer sanitization
    Vulnerability Spectre v2:        Mitigation; Enhanced IBRS, IBPB conditional, RSB filling
    Flags:                           fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xt
                                     opology nonstop_tsc cpuid aperfmperf tsc_known_freq pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 sdbg cx16 xtpr pdcm sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave rdrand lahf_lm
                                     3dnowprefetch cpuid_fault cat_l2 pti cdp_l2 ssbd ibrs ibpb stibp ibrs_enhanced tpr_shadow vnmi flexpriority ept vpid ept_ad fsgsbase tsc_adjust smep erms mpx rdt_a rdseed smap clflushopt intel_pt sha_ni x
                                     saveopt xsavec xgetbv1 xsaves dtherm ida arat pln pts umip rdpid md_clear arch_capabilities

    Comment


    • #22
      Originally posted by NotMine999 View Post
      I have one of these CPUs. Like most implementations of Gemini Lake, my CPU is soldered to the motherboard. So begging Intel to replace just ain't gonna happen unless the motherboard manufacturer also gets onboard, which is doubtful.

      Besides, having a CPU bug fixed in software would not be uncommon for this CPU family or any other CPU family that is vulnerable to any number of more widely seen CPU bugs like "spectre" and "meltdown" and so on.

      See the following "lscpu" output:

      Code:
      Linux j5005 5.2.0-3-amd64 #1 SMP Debian 5.2.17-1 (2019-09-26) x86_64
      Last login:
      j5005 ~ # lscpu
      Architecture: x86_64
      CPU op-mode(s): 32-bit, 64-bit
      Byte Order: Little Endian
      Address sizes: 39 bits physical, 48 bits virtual
      CPU(s): 4
      On-line CPU(s) list: 0-3
      Thread(s) per core: 1
      Core(s) per socket: 4
      Socket(s): 1
      NUMA node(s): 1
      Vendor ID: GenuineIntel
      CPU family: 6
      Model: 122
      Model name: Intel(R) Pentium(R) Silver J5005 CPU @ 1.50GHz
      Stepping: 1
      CPU MHz: 803.447
      CPU max MHz: 2800.0000
      CPU min MHz: 800.0000
      BogoMIPS: 2995.20
      Virtualization: VT-x
      L1d cache: 96 KiB
      L1i cache: 128 KiB
      L2 cache: 4 MiB
      NUMA node0 CPU(s): 0-3
      Vulnerability L1tf: Not affected
      Vulnerability Mds: Not affected
      Vulnerability Meltdown: Mitigation; PTI
      Vulnerability Spec store bypass: Mitigation; Speculative Store Bypass disabled via prctl and seccomp
      Vulnerability Spectre v1: Mitigation; usercopy/swapgs barriers and __user pointer sanitization
      Vulnerability Spectre v2: Mitigation; Enhanced IBRS, IBPB conditional, RSB filling
      Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xt
      opology nonstop_tsc cpuid aperfmperf tsc_known_freq pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 sdbg cx16 xtpr pdcm sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave rdrand lahf_lm
      3dnowprefetch cpuid_fault cat_l2 pti cdp_l2 ssbd ibrs ibpb stibp ibrs_enhanced tpr_shadow vnmi flexpriority ept vpid ept_ad fsgsbase tsc_adjust smep erms mpx rdt_a rdseed smap clflushopt intel_pt sha_ni x
      saveopt xsavec xgetbv1 xsaves dtherm ida arat pln pts umip rdpid md_clear arch_capabilities
      I use the same command without any information about the vulnerability. Why?

      Comment


      • #23
        Originally posted by Azrael5 View Post

        I use the same command without any information about the vulnerability. Why?
        Do you have outdated software in your system? Time for an upgrade!!!

        Comment


        • #24
          Originally posted by NotMine999 View Post
          I have one of these CPUs. Like most implementations of Gemini Lake, my CPU is soldered to the motherboard. So begging Intel to replace just ain't gonna happen unless the motherboard manufacturer also gets onboard, which is doubtful.

          Besides, having a CPU bug fixed in software would not be uncommon for this CPU family or any other CPU family that is vulnerable to any number of more widely seen CPU bugs like "spectre" and "meltdown" and so on.
          The article implies that Firefox developers found this working on older microcode version so if that is true, I would say it's very likely that this will be fixed by some future microcode update if Intel is willing to fix it. No need to replace processors.
          Last edited by Tomin; 06 October 2019, 04:57 AM.

          Comment


          • #25
            Originally posted by discordian View Post
            Sounds more like it's a hard to reproduce bug that depends (amidst other things) on where the linker places stuff.

            Hard to blame Google if a cpu can be singled out. Especially if at the same time Mozilla did the "don't care/works for me" instead of investigating.
            Mozilla didn't close the bug, the reporter did because the problem went away. And Google only worked around the bug in one specific case with one specific function. Firefox has nothing to fix if the linker no longer places a function on an offset that triggers the issue.

            Comment


            • #26
              Originally posted by milkylainen View Post
              Sounds like a pretty severe and basic bug.
              I'm surprised it hasn't triggered all sorts of havoc all over the place?
              Maybe it isn't a hardware bug after all?
              What's so special about the browsers that they keep (apparently?) triggering the bug?
              Considering this is in V8. I would guess JIT. Writing instructions to a piece of memory and then executing that memory.

              Comment


              • #27
                Originally posted by coder View Post
                Just a wild guess, but browsers are continuously JIT-compiling loads of code - quite likely more than fits in L2 cache (and perhaps invalidating Instruction Cache lines, as they do it). Meanwhile, other code running on the CPU might be less likely to generate cache misses. Just two ways in which browsers might differ from most software.
                l2 misses are affected by memory footprint, not by jit recompiling

                Comment


                • #28
                  Originally posted by DoMiNeLa10 View Post
                  JavaScript is JITed these days, so with it's constant code generation you run a greater risk of creating a stream of instructions that causes this bug to trigger.
                  they had crash in c++ code (v8::internal::LoadIC::UpdateCaches). jitted javascript probably runs in separate process anyway

                  Comment


                  • #29
                    Originally posted by carewolf View Post
                    I would guess JIT
                    you guessed wrong

                    Comment


                    • #30
                      Originally posted by pal666 View Post
                      they had crash in c++ code (v8::internal::LoadIC::UpdateCaches). jitted javascript probably runs in separate process anyway
                      As usual you have no idea what you are talking about. JIT code calls into C++ code all the time, and it does run in a separate process, but only relative to the hosting process, JIT code runs in the same separate process that renders the webpage and generates the JIT code to be run, the process that crashes in this case.
                      Last edited by carewolf; 06 October 2019, 05:37 AM.

                      Comment

                      Working...
                      X