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

[Tomin]

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.

[timofonic]

I use the same command without any information about the vulnerability. Why?

Do you have outdated software in your system? Time for an upgrade!!!

[Azrael5]

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:

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?

[NotMine999]

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:

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

[starshipeleven]

Quite likely. But doesn't Windows come with pretty nice bug reports/automatic telemetry that can be amassed into nice data points?

Only for Microsoft products and services, and maybe partially for Apps from the store (to mimic Google's handling of Android apps).

Which means everything else must use its own telemetry

[Palu Macil]

What's so special about the browsers that they keep (apparently?) triggering the bug?

Browsers are special enough that you can find ARM ("reduced" instruction set, ha) instructions specific to Javascript! FJCVTZS (v8.3-A chips and later) is "Floating-point Javascript Convert to Signed fixed-point, rounding toward Zero". Arguably, the browser is becoming the most important tool after whatever kernel you're using, so it makes sense that one of the richest tech companies on the planet would be able to find a complex bug affecting their own browser.

Typical Mozilla attitude.

Mozilla sucks these days.

Mozilla is striving to be the underdog that stays around and develops a web browser out of spite. They aren't a major corporation that has taking control in their agenda. The fact that they take the right approach and don't clean up the mess others make is right either way. Just report a bug to Intel, and tell the person that reported it to you to resolve the issue with them. Why would they pander to a major corporation that can't even keep up with chips in architecture they own?

Intel is having a he'l of CPU bugs these days. I'm getting nostalgia of the old Pentium days.

f00F, maybe they had bugs back in these days, but a crash is better than breaking memory safety.

What's so special about the browsers that they keep (apparently?) triggering the bug?

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.

Software developers should not fix this issue themselves, neither should compilers or linkers work around it. People should just pressure Intel to roll out a microcode patch ASAP.

[coder]

What's so special about the browsers that they keep (apparently?) triggering the bug?

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.

[F.Ultra]

Typical Mozilla attitude.

Mozilla sucks these days.

Intel is having a he'l of CPU bugs these days. I'm getting nostalgia of the old Pentium days.

Mozilla does not have a microscopic fraction of the resources that Google have. So when faced with an extremely rare non-reproduceable bug there is not much that a smaller player such as Mozilla can do. If they had blamed Intel then everyone would be up in arms about how silly Mozilla is, but when some one as large as Google is doing it then every one is listening.