Ny sårbarhet upptäckt i Intel CPU'er: Zombieload

Ja, det stämmer, fick tag i ett ucode-paket och nu är allt tätat. Får se om jag skall slå på HT igen?

Checking for vulnerabilities on current system
Kernel is Linux 5.1.2-arch1-1-ARCH #1 SMP PREEMPT Wed May 15 00:09:47 UTC 2019 x86_64
CPU is Intel(R) Core(TM) i7-4790K CPU @ 4.00GHz

Hardware check
* Hardware support (CPU microcode) for mitigation techniques
* Indirect Branch Restricted Speculation (IBRS)
* SPEC_CTRL MSR is available: YES
* CPU indicates IBRS capability: YES (SPEC_CTRL feature bit)
* Indirect Branch Prediction Barrier (IBPB)
* PRED_CMD MSR is available: YES
* CPU indicates IBPB capability: YES (SPEC_CTRL feature bit)
* Single Thread Indirect Branch Predictors (STIBP)
* SPEC_CTRL MSR is available: YES
* CPU indicates STIBP capability: YES (Intel STIBP feature bit)
* Speculative Store Bypass Disable (SSBD)
* CPU indicates SSBD capability: YES (Intel SSBD)
* L1 data cache invalidation
* FLUSH_CMD MSR is available: YES
* CPU indicates L1D flush capability: YES (L1D flush feature bit)
* Microarchitecture Data Sampling
* VERW instruction is available: YES (MD_CLEAR feature bit)
* 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 explicitly indicates not being vulnerable to Variant 4 (SSB_NO): NO
* CPU/Hypervisor indicates L1D flushing is not necessary on this system: NO
* Hypervisor indicates host CPU might be vulnerable to RSB underflow (RSBA): NO
* CPU explicitly indicates not being vulnerable to Microarchitectural Data Sampling (MDC_NO): NO
* CPU supports Software Guard Extensions (SGX): NO
* CPU microcode is known to cause stability problems: NO (model 0x3c family 0x6 stepping 0x3 ucode 0x27 cpuid 0x306c3)
* CPU microcode is the latest known available version: YES (latest version is 0x27 dated 2019/02/26 according to builtin MCExtractor DB v110 - 2019/05/11)
* CPU vulnerability to the speculative execution attack variants
* Vulnerable to CVE-2017-5753 (Spectre Variant 1, bounds check bypass): YES
* Vulnerable to CVE-2017-5715 (Spectre Variant 2, branch target injection): YES
* Vulnerable to CVE-2017-5754 (Variant 3, Meltdown, rogue data cache load): YES
* Vulnerable to CVE-2018-3640 (Variant 3a, rogue system register read): YES
* Vulnerable to CVE-2018-3639 (Variant 4, speculative store bypass): YES
* Vulnerable to CVE-2018-3615 (Foreshadow (SGX), L1 terminal fault): NO
* Vulnerable to CVE-2018-3620 (Foreshadow-NG (OS), L1 terminal fault): YES
* Vulnerable to CVE-2018-3646 (Foreshadow-NG (VMM), L1 terminal fault): YES
* Vulnerable to CVE-2018-12126 (Fallout, microarchitectural store buffer data sampling (MSBDS)): YES
* Vulnerable to CVE-2018-12130 (ZombieLoad, microarchitectural fill buffer data sampling (MFBDS)): YES
* Vulnerable to CVE-2018-12127 (RIDL, microarchitectural load port data sampling (MLPDS)): YES
* Vulnerable to CVE-2019-11091 (RIDL, microarchitectural data sampling uncacheable memory (MDSUM)): YES

CVE-2017-5753 aka 'Spectre Variant 1, bounds check bypass'
* Mitigated according to the /sys interface: YES (Mitigation: __user pointer sanitization)
* Kernel has array_index_mask_nospec: YES (1 occurrence(s) found of x86 64 bits array_index_mask_nospec())
* Kernel has the Red Hat/Ubuntu patch: NO
* Kernel has mask_nospec64 (arm64): NO
> STATUS: NOT VULNERABLE (Mitigation: __user pointer sanitization)

CVE-2017-5715 aka 'Spectre Variant 2, branch target injection'
* Mitigated according to the /sys interface: YES (Mitigation: Full generic retpoline, IBPB: conditional, IBRS_FW, RSB filling)
* Mitigation 1
* Kernel is compiled with IBRS support: YES
* IBRS enabled and active: YES (for firmware code only)
* Kernel is compiled with IBPB support: YES
* IBPB enabled and active: YES
* Mitigation 2
* Kernel has branch predictor hardening (arm): NO
* Kernel compiled with retpoline option: YES
* Kernel compiled with a retpoline-aware compiler: YES (kernel reports full retpoline compilation)
> STATUS: NOT VULNERABLE (Full retpoline + IBPB are mitigating the vulnerability)

CVE-2017-5754 aka 'Variant 3, Meltdown, rogue data cache load'
* Mitigated according to the /sys interface: YES (Mitigation: PTI)
* Kernel supports Page Table Isolation (PTI): YES
* PTI enabled and active: YES
* Reduced performance impact of PTI: YES (CPU supports INVPCID, performance impact of PTI will be greatly reduced)
* Running as a Xen PV DomU: NO
> STATUS: NOT VULNERABLE (Mitigation: PTI)

CVE-2018-3640 aka 'Variant 3a, rogue system register read'
* CPU microcode mitigates the vulnerability: YES
> STATUS: NOT VULNERABLE (your CPU microcode mitigates the vulnerability)

CVE-2018-3639 aka 'Variant 4, speculative store bypass'
* Mitigated according to the /sys interface: YES (Mitigation: Speculative Store Bypass disabled via prctl and seccomp)
* Kernel supports disabling speculative store bypass (SSB): YES (found in /proc/self/status)
* SSB mitigation is enabled and active: YES (per-thread through prctl)
* SSB mitigation currently active for selected processes: YES (haveged ModemManager systemd-journald systemd-logind systemd-timesyncd systemd-udevd upowerd)
> STATUS: NOT VULNERABLE (Mitigation: Speculative Store Bypass disabled via prctl and seccomp)

CVE-2018-3615 aka 'Foreshadow (SGX), L1 terminal fault'
* CPU microcode mitigates the vulnerability: N/A
> STATUS: NOT VULNERABLE (your CPU vendor reported your CPU model as not vulnerable)

CVE-2018-3620 aka 'Foreshadow-NG (OS), L1 terminal fault'
* Mitigated according to the /sys interface: YES (Mitigation: PTE Inversion; VMX: conditional cache flushes, SMT disabled)
* Kernel supports PTE inversion: YES (found in kernel image)
* PTE inversion enabled and active: YES
> STATUS: NOT VULNERABLE (Mitigation: PTE Inversion)

CVE-2018-3646 aka 'Foreshadow-NG (VMM), L1 terminal fault'
* Information from the /sys interface: VMX: conditional cache flushes, SMT disabled
* This system is a host running a hypervisor: NO
* Mitigation 1 (KVM)
* EPT is disabled: NO
* Mitigation 2
* L1D flush is supported by kernel: YES (found flush_l1d in /proc/cpuinfo)
* L1D flush enabled: YES (conditional flushes)
* Hardware-backed L1D flush supported: YES (performance impact of the mitigation will be greatly reduced)
* Hyper-Threading (SMT) is enabled: NO
> STATUS: NOT VULNERABLE (this system is not running a hypervisor)

CVE-2018-12126 aka 'Fallout, microarchitectural store buffer data sampling (MSBDS)'
* Mitigated according to the /sys interface: YES (Mitigation: Clear CPU buffers; SMT disabled)
* CPU supports the MD_CLEAR functionality: YES
* Kernel supports using MD_CLEAR mitigation: YES (md_clear found in /proc/cpuinfo)
* Kernel mitigation is enabled and active: YES
* SMT is either mitigated or disabled: YES
> STATUS: NOT VULNERABLE (Mitigation: Clear CPU buffers; SMT disabled)

CVE-2018-12130 aka 'ZombieLoad, microarchitectural fill buffer data sampling (MFBDS)'
* Mitigated according to the /sys interface: YES (Mitigation: Clear CPU buffers; SMT disabled)
* CPU supports the MD_CLEAR functionality: YES
* Kernel supports using MD_CLEAR mitigation: YES (md_clear found in /proc/cpuinfo)
* Kernel mitigation is enabled and active: YES
* SMT is either mitigated or disabled: YES
> STATUS: NOT VULNERABLE (Mitigation: Clear CPU buffers; SMT disabled)

CVE-2018-12127 aka 'RIDL, microarchitectural load port data sampling (MLPDS)'
* Mitigated according to the /sys interface: YES (Mitigation: Clear CPU buffers; SMT disabled)
* CPU supports the MD_CLEAR functionality: YES
* Kernel supports using MD_CLEAR mitigation: YES (md_clear found in /proc/cpuinfo)
* Kernel mitigation is enabled and active: YES
* SMT is either mitigated or disabled: YES
> STATUS: NOT VULNERABLE (Mitigation: Clear CPU buffers; SMT disabled)

CVE-2019-11091 aka 'RIDL, microarchitectural data sampling uncacheable memory (MDSUM)'
* Mitigated according to the /sys interface: YES (Mitigation: Clear CPU buffers; SMT disabled)
* CPU supports the MD_CLEAR functionality: YES
* Kernel supports using MD_CLEAR mitigation: YES (md_clear found in /proc/cpuinfo)
* Kernel mitigation is enabled and active: YES
* SMT is either mitigated or disabled: YES
> STATUS: NOT VULNERABLE (Mitigation: Clear CPU buffers; SMT disabled)

> SUMMARY: CVE-2017-5753:OK CVE-2017-5715:OK CVE-2017-5754:OK CVE-2018-3640:OK CVE-2018-3639:OK CVE-2018-3615:OK CVE-2018-3620:OK CVE-2018-3646:OK CVE-2018-12126:OK CVE-2018-12130:OK CVE-2018-12127:OK CVE-2019-11091:OK

Angående CVE-2019-0708 | Remote Desktop Services Remote Code Execution Vulnerability
"To exploit this vulnerability, an attacker would need to send a specially crafted request to the target systems Remote Desktop Service via RDP."
Och eftersom Microsoft än idag med windows 10 väljer att ha "Tillåt Fjärrhjälpsanslutningar till den här datorn" påslaget som standard, där windows lyssnar till port 3389 låter det lite märkligt att inte win10 är drabbad.

Självklart stänger man ju av detta så fort man installerar windows, och i brandväggen visar det sig som att port 3389 inte är aktiverat för mig men som arstechnica skriver så verkar det som mer än 16 miljoner "endpoints exposed" till internet. Sen nämner de också port 3388 men använder ens windows den porten.
Jag förstår inte riktigt vad(eller vilken då den antagligen är inbakad i flera) denna uppdatering ska fixa mer än stänga av Fjärranslutningar på äldre os än win10, och det kan man ju göra själv. MDS verkar ändå mer allvarligt, på sikt, speciellt om man har en cpu med HT.

Kan ju säga att jag faktiskt känner igen det du säger. Man kanske hoppas blint på att ens kunder inte får reda på detta och bara inväntar en patch.

Windows + DirectX.... där har du varför.
(på gott och ont)

ARM är en hög konkurrent marknad, medans Windows + DirectX låsningen är varför X86 licenserna är så mycket värt.

Öh hänger inte med här, kan någon kort sammanfatta vad som hänt för en noob som mig? Stänga av HT låter ju tråkigt, är väl en rätt så bra funktion som ger en prestanda?

Fortsätt att köra HT.
Risken är ganska liten.
Tror att det skall räcka med att hålla din programvara uppdaterad, detta kommer att täppas till ganska bra.
Det krävs möjlighet att köra program på din dator för att kunna använda detta, största problemet är för datacentraler, som kör saker upp i "molnet".

Jo exakt.

PÅ mitt förra jobb så meddelade jag dom direkt när Specta och Meltdown kom, men det var bara "Mehh, det där löser dom med patcher"

Inget att oroa sig över med andra ord när man sitter med en 8600k, som inte har hyperthreading ens..

Phoronix har testat i Linux.

Klar påverkan av patchen i prestandatester.
https://phoronix.com/scan.php?page=news_item&px=MDS-Zombieloa...

Men liten påverkan i spel.
https://phoronix.com/scan.php?page=news_item&px=Zombie-Load-G...

Provade med mds-tools på en gammal P4 med HT. Endast L1 Terminal Fault SMT markerat som vulnerable. Dvs samma som på AMD FX-serien. Sen om det stämmer är ju en annan femma.

Jo, har märkt samma sak, på vissa laster blir prestanda på Intel sämre med HT än utan.

Skulle tro du hellre kör DOS då än Windows med avstängd cache.
Hade ett tag på jobbet en utbildningssal med ett antal identiska datorer; P-III 600 MHz.

En av dem var ostabil och eftersom det var Dell så enda optionen som påverkade prestanda i BIOS var att stänga av cache. Prestanda då blev ca 1/100 del av ursprungligt dvs motsvarande runt 6 MHz.

Knappast foliehattigt när det är vad som hände. Vi får vara glada att säkerhetsforskarna tackade nej till den extra bonusen och gjorde det rätta.

Tack, kul att du testade.

Jag tror det är av historiska skäl. En gång i tiden (486, Pentium 1, AMD K5, K6 etc) var L2-cachen extern, så du kunde inte vara säker på att någon annan hade lika mycket eller ens någon alls. Så att som utvecklare kunna testköra programvaran utan cache kunde vara en bra funktion. (Gissningsvis fanns det säkert fall där programvara gick på tok för fort med cache påslagen också).

Hoppar vi fram något i tiden så saknade Celeron L2-cache medan P3 hade den. Så på det sättet kunde man simulera en Celeron på en P3 om man ville (ja man fick ju ändra busshastighet också). Och för oss som klockade AMD K7 Slot A med extern cache, så hade cachen olika dividers att ta hänsyn till. Att slå av L2 kunde därför vara smidigt medan man provklockade och ville se hur högt CPUn gick.

Du verkar inte ha förstått...

Återigen. Intel vill att det skulle uppfattas som att buggen var mindre allvarlig. En bug som man får $40k för är inte lika allvarlig som en man får $100k för. Så $40k för buggen och $80k på något annat sätt, istället då för $100k för buggen.

Vet inte heller varför du drar upp embargotid? Det är mig veterligen inte någon som har krävt att få gå ut med detta tidigare? Men på det ämnet så gissar jag att en lägre klassad bugg har en kortare embargotid, då den, igen, inte är lika allvarlig.

Edit: Om någon så var det Intel som ville ha en kortare embargotid då som en konsekvens av att de ville få buggen klassad som inte lika allvarlig. Intäkterna var väl viktigare...

Jag uppfattar det så, att Intel fick veta detta förra sommaren.

Jayc testar HT av och på, och hur det påverkar spel och program.

https://www.youtube.com/watch?v=a8yXqsfXWcM

Sjukt nog påverkar det på det hela alltet inte så mycket i dessa tester.

Han testar med en 9900K, hur ser det ut för 2-kärniga med HT eller 4-kärniga med HT?

Edit: 8700K ska det vara som cyklonen påpekar i nästa inlägg.