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

Permalänk
Medlem
Skrivet av CubaCola:

Varför är inte AMD påverkad av detta då de också använder Hyperthreading?.
Eller är det bara det att man inte har testat att samma attack även fungerar på AMD?

Inga av intel-datorerna i huset har HT så jag känner mig lugn

Utan att jag satt mig in i detta så ligger tydligen sårbarheten ligger i Intels proprietära SGX
https://www.cyberus-technology.de/posts/2019-05-14-zombieload...

Permalänk
Medlem
Skrivet av filbunke:

Oflyt?

Under tiden som det har funnits ett embargo på att publikt rapportera om dessa säkerhetshål så har minst _åtta_ olika grupper hittat och rapporterat dessa till Intel.

Att tro att AMD:s produkter inte ligger under lupp redan nu... Kan lova att Intel antingen har anställda som nagelfar dessa eller att de betalar utomstående att göra det.

Med Spectre, Meltdwn så hittade man en spricka i ytan som nu visar sig vara ett helt rotsystem med svagheter i arkitekturen, att hitta mer svagheter inom samma familj var inte oväntat eller snarare förvånande om man _inte_ skulle hitta mer.

Bara för att AMD inte är lika drabbad betyder inte att det inte finns potentiell 'spricka' av liknande typ även hos dem som Intel nu slåss med, men är ännu oupptäckt. Med Spectre/Meltdown vet man nu också vad man skall titta efter för den här gången och därmed snabbare ser liknande problem - men det kan finnas svagheter som hittas först med hel annan angreppsmetod och först efteråt kan säga - 'hur faen kunde vi missa detta' men innan det upptäcks så kan man stirra sig blind på det utan att se det.

Permalänk
Medlem
Skrivet av Elgreco1:

Min hjärna ville tro att dem senaste åren hade fått folk att börja patcha upp system som fortfarande låg på Windows 7(detta pga attityden mot Windows 7 i bolag jag varit i kontakt med dem senaste åren), när jag sökte efter information för att bekräfta min övertygelse hittade jag detta.

"Windows 10 held 39.22 percent of desktop OS market share in December 2018, compared to 36.9 percent for Windows 7."

Så, ja, det du säger stämmer helt, man kan säga att det fortfarande finns otroligt många system som tuggar Windows 7.

Tror en del av detta är pga Windows 10 har ändrat så mycket som många företag inte ville ha.
1803 och 1809 var också en mindre katastrof till lansering, med förseningar och återkallningar i flera omgångar. Och 1903... var är den?

Företag mao ville vänta på något "stabilt" att hoppa över, och det verkar som MS lyssnat om man tittar på 1903s nya WU rutiner bla. Detta gör ju att det kan vara kanon tillfälle att när 1903 mognat nu, hoppa över. Men innan dess har det mer verkat som folk som hoppat, varit betatestare för MS. När en basalt enkel sak som Startmenyn, inte fungerar att importera/exportera och styra via GPO, så vill man verkligen inte byta. Och detta fixades 2:a maj btw... varit trasigt sedan 1803.

Så jag förstår fullständigt företag som hellre uppdaterar en RDP version, än spenderar timmar med att få basala enkla saker att fungera korrekt.

Vi här håller på att uppdatera, och har stött på flera olika problem med div mjukvaror och andra system som måste vara kvar. Det tar mao inte bara dagar att fixa, utan månader med halvdana drivare osv som spökar.

Intel/Dell var så snäll att äntligen nu för ca 1 vecka sedan ge oss certifierade Wifi drivare som fungerade bra... för 1803/1809. Precis det man vill vänta ca 1 år på att få, eller hur?

Windows 10an har fördelar, helt klart, men ibland är nackdelarna bara för stora.

Permalänk
Inaktiv

Jag vet ett annat sätt än att stänga av HT för att skydda sig emot hackers på Intel cpuer. Man tar och klockar ner sin nya 9900K till 33MHz som visa 386or gick i. Det som händer då är att ens dator blir så fruktansvärd slö, så även om den står vidöppen så kommer ingen hacker orka jobba med denna dator.

Permalänk
Medlem
Skrivet av Paddanx:

Tror en del av detta är pga Windows 10 har ändrat så mycket som många företag inte ville ha.
1803 och 1809 var också en mindre katastrof till lansering, med förseningar och återkallningar i flera omgångar. Och 1903... var är den?

Företag mao ville vänta på något "stabilt" att hoppa över, och det verkar som MS lyssnat om man tittar på 1903s nya WU rutiner bla. Detta gör ju att det kan vara kanon tillfälle att när 1903 mognat nu, hoppa över. Men innan dess har det mer verkat som folk som hoppat, varit betatestare för MS. När en basalt enkel sak som Startmenyn, inte fungerar att importera/exportera och styra via GPO, så vill man verkligen inte byta. Och detta fixades 2:a maj btw... varit trasigt sedan 1803.

Så jag förstår fullständigt företag som hellre uppdaterar en RDP version, än spenderar timmar med att få basala enkla saker att fungera korrekt.

Vi här håller på att uppdatera, och har stött på flera olika problem med div mjukvaror och andra system som måste vara kvar. Det tar mao inte bara dagar att fixa, utan månader med halvdana drivare osv som spökar.

Intel/Dell var så snäll att äntligen nu för ca 1 vecka sedan ge oss certifierade Wifi drivare som fungerade bra... för 1803/1809. Precis det man vill vänta ca 1 år på att få, eller hur?

Windows 10an har fördelar, helt klart, men ibland är nackdelarna bara för stora.

Låter lika lätt som att få skrivare att fungera, enklare att sätta upp en Linux VM istället för att bråka med windows, var på ett IT ställe där de hade gett upp och satt upp en liten rpi3 burk med cups/samba som nätverksskrivare på det interna nätet.

Visa signatur

"Oh glorious cheeseburger… we bow to thee. The secrets of the universe are between the buns..."
"All my farts come straight from hell, you're already dead if you notice a smell"

Permalänk
Hjälpsam

Kolla Intel är kass på hyperthreading!

Källa Intel.

Visa signatur

AMD Ryzen 7 1700 | Saphire RX 5700 Pulse XT (Silent Mode) | 64 GB Kingston ECC | https://valid.x86.fr/z2ljhr | Stockkylaren | Bitfenix Whisper M 750W.
AMD Ryzen 9 5900X | AMD RX 5700 | 64 GB Micron ECC | https://valid.x86.fr/5krwxf
HTPC | https://valid.x86.fr/uuzli0 |

Permalänk
Medlem

Skönt att se att man inte förlorar just någon prestanda på att stänga av HT längre! :/

Skickades från m.sweclockers.com

Visa signatur

MB: Asus ROG Hero | CPU: i4770@4,6GHz | RAM: 16GB@1600 | GPU: 6970 | STORAGE: 2*120GB SSD | COOLING: Custom, Water

Permalänk

Varför i hela friden skulle nån vilja disabla cache minnet i sin CPU????
Den frågan har jag ställt mig i gamla BIOS ända sedan 90-talet...
Nu vet vi varför, och lägligt nog så saknas funktionen numera i moderna system!!

Visa signatur

Dator: EEE901 N270/ 1GB / 20GB SSD ... Kraftigt nedbantat/tweakat Win7 x86 for speeeEED!
Facebook användare? Hatar tidslinjen? gå med i denna FB-grupp:
Undo Timeline ...med lite tur får h*lvetet ett slut!

Permalänk
Medlem
Visa signatur

|| R9 7950X MSI PRO X670-P WIFI 32GB-6400c30 MSI RTX4080 Ventus 3X OC || i9 12900KF MSI Z690 Tomahawk WIFI DDR4 32GB-3600c16 TUF RTX3080 OC V2 || R7 5800X3D CH VIII Extreme 32GB-3800c18 Gigabyte RTX3080 GAMING OC || R9 5900X(B2) B550-F 32GB-3800c18 EVGA RTX3070 FTW Ultra || R9 3900X X470-Prime Pro 32GB-3200c16 MSI RTX2070 Super || Thinkpad P16s Gen 2 R7 PRO 7840U(Zen4) 32GB-6400 1TB 980Pro 780M

Permalänk
Medlem

Intressant att Intel inte gått ut med pressrelease om detta till sina aktieägare. Det är inte bara för användare Intel mörkar så gott de kan.
https://www.bloomberg.com/quote/INTC:US

Skickades från m.sweclockers.com

Visa signatur

MB: Asus ROG Hero | CPU: i4770@4,6GHz | RAM: 16GB@1600 | GPU: 6970 | STORAGE: 2*120GB SSD | COOLING: Custom, Water

Permalänk
Medlem

Värt att notera är att Googles Chrome OS numera har HT avstängt som default, och ingen uppenbar metod att slå på det.

Visa signatur

|| R9 7950X MSI PRO X670-P WIFI 32GB-6400c30 MSI RTX4080 Ventus 3X OC || i9 12900KF MSI Z690 Tomahawk WIFI DDR4 32GB-3600c16 TUF RTX3080 OC V2 || R7 5800X3D CH VIII Extreme 32GB-3800c18 Gigabyte RTX3080 GAMING OC || R9 5900X(B2) B550-F 32GB-3800c18 EVGA RTX3070 FTW Ultra || R9 3900X X470-Prime Pro 32GB-3200c16 MSI RTX2070 Super || Thinkpad P16s Gen 2 R7 PRO 7840U(Zen4) 32GB-6400 1TB 980Pro 780M

Permalänk
Inaktiv
Skrivet av the squonk:

Värt att notera är att Googles Chrome OS numera har HT avstängt som default, och ingen uppenbar metod att slå på det.

Se när speltillverkare börjar slå av HT ochså då?

Permalänk
Medlem

Slagit av HT på min Linux-server nu, har också senaste kärnan 5.1.2 med mitigations, men det finns fortfarande alla dessa cache exploits. Nu är mitt Z87-moderkort så gammalt så jag har flera inställningar för att stänga av olika delar av cache/prefetch, får se om jag får tid att testa och se hur prestanda dyker.

Visa signatur

|| R9 7950X MSI PRO X670-P WIFI 32GB-6400c30 MSI RTX4080 Ventus 3X OC || i9 12900KF MSI Z690 Tomahawk WIFI DDR4 32GB-3600c16 TUF RTX3080 OC V2 || R7 5800X3D CH VIII Extreme 32GB-3800c18 Gigabyte RTX3080 GAMING OC || R9 5900X(B2) B550-F 32GB-3800c18 EVGA RTX3070 FTW Ultra || R9 3900X X470-Prime Pro 32GB-3200c16 MSI RTX2070 Super || Thinkpad P16s Gen 2 R7 PRO 7840U(Zen4) 32GB-6400 1TB 980Pro 780M

Permalänk
Medlem
Skrivet av kotz:

AMD hade också något strul 2017 tror jag?

Men Intel verkar har grova problem med säkerhetsluckor.. Den ena efter den andra löser av sig med jämna mellanrum

Det är väl så att arkitekturen börjar visa sin ålder.

Ibland kommer man till en punkt där det helt enkelt inte fungerar utan man måste börja om på nytt. Det är också när en lösning kommit till vägs ände och man inte har alternativ som konkurrenter kommer i kapp och åker om. Det har hänt förut och kommer att hända igen.

Permalänk
Medlem

Detaljerad info om mina säkerhetshål:

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: 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 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 0x25 cpuid 0x306c3)
* CPU microcode is the latest known available version: NO (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 (chrome 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: NO (Vulnerable: Clear CPU buffers attempted, no microcode; SMT disabled)
* CPU supports the MD_CLEAR functionality: NO
* Kernel supports using MD_CLEAR mitigation: YES (found md_clear implementation evidence in kernel image)
* Kernel mitigation is enabled and active: NO
* SMT is either mitigated or disabled: YES
> STATUS: VULNERABLE (Vulnerable: Clear CPU buffers attempted, no microcode; SMT disabled)

CVE-2018-12130 aka 'ZombieLoad, microarchitectural fill buffer data sampling (MFBDS)'
* Mitigated according to the /sys interface: NO (Vulnerable: Clear CPU buffers attempted, no microcode; SMT disabled)
* CPU supports the MD_CLEAR functionality: NO
* Kernel supports using MD_CLEAR mitigation: YES (found md_clear implementation evidence in kernel image)
* Kernel mitigation is enabled and active: NO
* SMT is either mitigated or disabled: YES
> STATUS: VULNERABLE (Vulnerable: Clear CPU buffers attempted, no microcode; SMT disabled)

CVE-2018-12127 aka 'RIDL, microarchitectural load port data sampling (MLPDS)'
* Mitigated according to the /sys interface: NO (Vulnerable: Clear CPU buffers attempted, no microcode; SMT disabled)
* CPU supports the MD_CLEAR functionality: NO
* Kernel supports using MD_CLEAR mitigation: YES (found md_clear implementation evidence in kernel image)
* Kernel mitigation is enabled and active: NO
* SMT is either mitigated or disabled: YES
> STATUS: VULNERABLE (Vulnerable: Clear CPU buffers attempted, no microcode; SMT disabled)

CVE-2019-11091 aka 'RIDL, microarchitectural data sampling uncacheable memory (MDSUM)'
* Mitigated according to the /sys interface: NO (Vulnerable: Clear CPU buffers attempted, no microcode; SMT disabled)
* CPU supports the MD_CLEAR functionality: NO
* Kernel supports using MD_CLEAR mitigation: YES (found md_clear implementation evidence in kernel image)
* Kernel mitigation is enabled and active: NO
* SMT is either mitigated or disabled: YES
> STATUS: VULNERABLE (Vulnerable: Clear CPU buffers attempted, no microcode; 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:KO CVE-2018-12130:KO CVE-2018-12127:KO CVE-2019-11091:KO

Need more detailed information about mitigation options? Use --explain
A false sense of security is worse than no security at all, see --disclaimer

Visa signatur

|| R9 7950X MSI PRO X670-P WIFI 32GB-6400c30 MSI RTX4080 Ventus 3X OC || i9 12900KF MSI Z690 Tomahawk WIFI DDR4 32GB-3600c16 TUF RTX3080 OC V2 || R7 5800X3D CH VIII Extreme 32GB-3800c18 Gigabyte RTX3080 GAMING OC || R9 5900X(B2) B550-F 32GB-3800c18 EVGA RTX3070 FTW Ultra || R9 3900X X470-Prime Pro 32GB-3200c16 MSI RTX2070 Super || Thinkpad P16s Gen 2 R7 PRO 7840U(Zen4) 32GB-6400 1TB 980Pro 780M

Permalänk
Medlem

Det är tur man har en, till jämförelse sett ryzligt säker processor.

Visa signatur

Mobo: Asus X470 Crosshair VII Hero *** CPU: AMD Ryzen 7 2700X *** RAM: 32Gb G.Skill TridentZ 2933Mhz *** PSU: Seasonic 850W Focus+ Platinum *** GPU: Gigabyte RTX2080 Gaming OC *** SSD: Samsung 860 EVO 2 TB *** Chassi: Fractal Design Define R6 TG Svart *** Tangentbord: Ducky One 3 Daybreak MX Clear *** Mus: Logitech Pro X Superlight *** Skärm: Alienware AW3821DW

Permalänk
Inaktiv
Skrivet av waverider:

Det är tur man har en, till jämförelse sett ryzligt säker processor.

@waverider

De vet inte än om det gäller Ryzen ochså.
Så om jag skulle varit dig så disabla SMT för att va säker innan vi vet.

Permalänk
Medlem
Skrivet av anon298854:

@waverider

De vet inte än om det gäller Ryzen ochså.
Så om jag skulle varit dig så disabla SMT för att va säker innan vi vet.

AMD har officiellt sagt att dom inte är drabbade, står tom på Swecs första sida, är man så paranoid att man disablar ändå ska man nog inte vara ansluten till Internet överhuvudtaget.

Står också på forskarnas(som upptäckte det) sida att det inte gäller AMD och ARM.

Visa signatur

|| R9 7950X MSI PRO X670-P WIFI 32GB-6400c30 MSI RTX4080 Ventus 3X OC || i9 12900KF MSI Z690 Tomahawk WIFI DDR4 32GB-3600c16 TUF RTX3080 OC V2 || R7 5800X3D CH VIII Extreme 32GB-3800c18 Gigabyte RTX3080 GAMING OC || R9 5900X(B2) B550-F 32GB-3800c18 EVGA RTX3070 FTW Ultra || R9 3900X X470-Prime Pro 32GB-3200c16 MSI RTX2070 Super || Thinkpad P16s Gen 2 R7 PRO 7840U(Zen4) 32GB-6400 1TB 980Pro 780M

Permalänk
Inaktiv
Skrivet av the squonk:

AMD har officiellt sagt att dom inte är drabbade, står tom på Swecs första sida, är man så paranoid att man disablar ändå ska man nog inte vara ansluten till Internet överhuvudtaget.

Står också på forskarnas(som upptäckte det) sida att det inte gäller AMD och ARM.

@the squonk

Så har AMD sagt och det står även på första sidan.

"Värt att notera är AMD:s ordval, som är av det försiktiga slaget. Orden "we believe" antyder att företaget inte är tillräckligt säkra på sin sak för att helt friskriva sig från att bristerna kan upptäckas i deras processorer."

Permalänk
Medlem
Skrivet av anon298854:

@waverider

De vet inte än om det gäller Ryzen ochså.
Så om jag skulle varit dig så disabla SMT för att va säker innan vi vet.

Att bevisa att några hål INTE finns är som att bevisa att tomten inte finns. Man får helt enkelt anta att det är på det sättet till någon bevisat motsatsen.

Skickades från m.sweclockers.com

Visa signatur

MB: Asus ROG Hero | CPU: i4770@4,6GHz | RAM: 16GB@1600 | GPU: 6970 | STORAGE: 2*120GB SSD | COOLING: Custom, Water

Permalänk
Medlem
Skrivet av anon298854:

@the squonk

Så har AMD sagt och det står även på första sidan.

"Värt att notera är AMD:s ordval, som är av det försiktiga slaget. Orden "we believe" antyder att företaget inte är tillräckligt säkra på sin sak för att helt friskriva sig från att bristerna kan upptäckas i deras processorer."

Ingen kan någonsin vara helt säker, så VARFÖR skulle dom uttrycka sig annorlunda? Enligt vad vi vet just nu är dom helt enkelt inte drabbade eftersom ingen har upptäckt något, precis som Intel var för två dagar sen. Det är klokt att agera på kända fakta, inte på okända "fakta".

Visa signatur

|| R9 7950X MSI PRO X670-P WIFI 32GB-6400c30 MSI RTX4080 Ventus 3X OC || i9 12900KF MSI Z690 Tomahawk WIFI DDR4 32GB-3600c16 TUF RTX3080 OC V2 || R7 5800X3D CH VIII Extreme 32GB-3800c18 Gigabyte RTX3080 GAMING OC || R9 5900X(B2) B550-F 32GB-3800c18 EVGA RTX3070 FTW Ultra || R9 3900X X470-Prime Pro 32GB-3200c16 MSI RTX2070 Super || Thinkpad P16s Gen 2 R7 PRO 7840U(Zen4) 32GB-6400 1TB 980Pro 780M

Permalänk
Medlem

hur sannolikt är det att man drabbas av detta? Är det dumt att köpa en 9700k nu? Tycker den verkar mycket fetare än amd men det här låter ju inte allt för bra.

Permalänk
Medlem
Skrivet av zinkon:

hur sannolikt är det att man drabbas av detta? Är det dumt att köpa en 9700k nu? Tycker den verkar mycket fetare än amd men det här låter ju inte allt för bra.

Vänta på Zen2 och se vad den går för, den stora frågan är just spelprestandan som jag antar att du menar. Dom bör gå att köpa i Juli eller senast Augusti inför skolstarten som är gigantiskt för shopping i USA.

Om du inte har panik att köpa, då är 9700K just nu bästa processorn för spel. 9900K går ju bort om man ändå måste disabla HT, den blir helt enkelt en 9700K för tusen kronor mer och blir svårsåld.

Hur sannolikt? Svårt att säga, men med tanke på att både Google och Apple väljer att stänga av HT så bedömer dom det antagligen som relativt sannolikt. Apple kommer säkert att jobba ännu hårdare med OSX för ARM nu, och en mer kraftfull laptop variant av A13, typ A14X eller vad den kommer att heta.

Visa signatur

|| R9 7950X MSI PRO X670-P WIFI 32GB-6400c30 MSI RTX4080 Ventus 3X OC || i9 12900KF MSI Z690 Tomahawk WIFI DDR4 32GB-3600c16 TUF RTX3080 OC V2 || R7 5800X3D CH VIII Extreme 32GB-3800c18 Gigabyte RTX3080 GAMING OC || R9 5900X(B2) B550-F 32GB-3800c18 EVGA RTX3070 FTW Ultra || R9 3900X X470-Prime Pro 32GB-3200c16 MSI RTX2070 Super || Thinkpad P16s Gen 2 R7 PRO 7840U(Zen4) 32GB-6400 1TB 980Pro 780M

Permalänk

Kul när man precis köpt en i9900k....

Kommer nog inte stänga av ht i alla fall.

Är det inte bara släppa en update till win 10 för att täppa till detta?

Visa signatur

Live for fun, Loyal to none

Permalänk
Medlem
Skrivet av anon298854:

@the squonk

Så har AMD sagt och det står även på första sidan.

"Värt att notera är AMD:s ordval, som är av det försiktiga slaget. Orden "we believe" antyder att företaget inte är tillräckligt säkra på sin sak för att helt friskriva sig från att bristerna kan upptäckas i deras processorer."

Det är troligtvis juridiska orsaker till att inte uttala sig tvärsäkert.

Permalänk
Inaktiv
Skrivet av the squonk:

Vänta på Zen2 och se vad den går för, den stora frågan är just spelprestandan som jag antar att du menar. Dom bör gå att köpa i Juli eller senast Augusti inför skolstarten som är gigantiskt för shopping i USA.

Om du inte har panik att köpa, då är 9700K just nu bästa processorn för spel. 9900K går ju bort om man ändå måste disabla HT, den blir helt enkelt en 9700K för tusen kronor mer och blir svårsåld.

Hur sannolikt? Svårt att säga, men med tanke på att både Google och Apple väljer att stänga av HT så bedömer dom det antagligen som relativt sannolikt. Apple kommer säkert att jobba ännu hårdare med OSX för ARM nu, och en mer kraftfull laptop variant av A13, typ A14X eller vad den kommer att heta.

Vore riktigt intressant att se om Apple skulle gå över till AMD istället för prestandaprodukterna.

Permalänk
Medlem
Skrivet av anon5930:

Vore riktigt intressant att se om Apple skulle gå över till AMD istället för prestandaprodukterna.

Finns inga sådana rykten vad jag vet, det är en övergång till ARM som alla väntar sig av Apple.

Visa signatur

|| R9 7950X MSI PRO X670-P WIFI 32GB-6400c30 MSI RTX4080 Ventus 3X OC || i9 12900KF MSI Z690 Tomahawk WIFI DDR4 32GB-3600c16 TUF RTX3080 OC V2 || R7 5800X3D CH VIII Extreme 32GB-3800c18 Gigabyte RTX3080 GAMING OC || R9 5900X(B2) B550-F 32GB-3800c18 EVGA RTX3070 FTW Ultra || R9 3900X X470-Prime Pro 32GB-3200c16 MSI RTX2070 Super || Thinkpad P16s Gen 2 R7 PRO 7840U(Zen4) 32GB-6400 1TB 980Pro 780M

Permalänk
Datavetare
Skrivet av the squonk:

Detaljerad info om mina säkerhetshål:

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: 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 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 0x25 cpuid 0x306c3)
* CPU microcode is the latest known available version: NO (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 (chrome 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: NO (Vulnerable: Clear CPU buffers attempted, no microcode; SMT disabled)
* CPU supports the MD_CLEAR functionality: NO
* Kernel supports using MD_CLEAR mitigation: YES (found md_clear implementation evidence in kernel image)
* Kernel mitigation is enabled and active: NO
* SMT is either mitigated or disabled: YES
> STATUS: VULNERABLE (Vulnerable: Clear CPU buffers attempted, no microcode; SMT disabled)

CVE-2018-12130 aka 'ZombieLoad, microarchitectural fill buffer data sampling (MFBDS)'
* Mitigated according to the /sys interface: NO (Vulnerable: Clear CPU buffers attempted, no microcode; SMT disabled)
* CPU supports the MD_CLEAR functionality: NO
* Kernel supports using MD_CLEAR mitigation: YES (found md_clear implementation evidence in kernel image)
* Kernel mitigation is enabled and active: NO
* SMT is either mitigated or disabled: YES
> STATUS: VULNERABLE (Vulnerable: Clear CPU buffers attempted, no microcode; SMT disabled)

CVE-2018-12127 aka 'RIDL, microarchitectural load port data sampling (MLPDS)'
* Mitigated according to the /sys interface: NO (Vulnerable: Clear CPU buffers attempted, no microcode; SMT disabled)
* CPU supports the MD_CLEAR functionality: NO
* Kernel supports using MD_CLEAR mitigation: YES (found md_clear implementation evidence in kernel image)
* Kernel mitigation is enabled and active: NO
* SMT is either mitigated or disabled: YES
> STATUS: VULNERABLE (Vulnerable: Clear CPU buffers attempted, no microcode; SMT disabled)

CVE-2019-11091 aka 'RIDL, microarchitectural data sampling uncacheable memory (MDSUM)'
* Mitigated according to the /sys interface: NO (Vulnerable: Clear CPU buffers attempted, no microcode; SMT disabled)
* CPU supports the MD_CLEAR functionality: NO
* Kernel supports using MD_CLEAR mitigation: YES (found md_clear implementation evidence in kernel image)
* Kernel mitigation is enabled and active: NO
* SMT is either mitigated or disabled: YES
> STATUS: VULNERABLE (Vulnerable: Clear CPU buffers attempted, no microcode; 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:KO CVE-2018-12130:KO CVE-2018-12127:KO CVE-2019-11091:KO

Need more detailed information about mitigation options? Use --explain
A false sense of security is worse than no security at all, see --disclaimer

Nog läge för en uppdatering om du är rädd för MDS

updaterad Ubuntu 18.04 på i7-8559U/i7-5600U
updaterad Ubuntu 18.04 på 2700X (nyheten här är att kärnan vet att MDS inte påverkar denna)
Skrivet av the squonk:

Finns inga sådana rykten vad jag vet, det är en övergång till ARM som alla väntar sig av Apple.

Jag ser MDS som potentiellt något riktigt bra
Det kan skynda på vår resa från x86 träsket mot något som är designat med dagens krav i fokus, inte de som var relevanta på 80- 90-talet...

Att Intel har dessa buggar kommer mycket av att de nästan slagit knut på sig själva för att komma runt en del riktigt idotiska beslut i vilka garantier x86 gör kring minnesoperationer.

Garantier som ARM varit tillräckligt nyktra att inte utfästa. Garantier som nu när formella minneskonsistensmodeller spikats för all de stora programspråket visat sig vara helt onödiga -> ARM slipper spenderar kisel på att fixa något som i praktiken ändå inte har någon relevans. Fast x86 tillverkarkarna kan inte ändra sin specifikation nu, det skulle bryta bakåtkompatibilitet och kommer med 100 % säkerhet leda till att multitrådade program börjar uppföra sig på fel sätt!

Man kan gå bra gepp om varför Zen inte påverkas av MDS när man läser deras dokument kring ämnet. Men deras implementation lämnar också prestanda på bordet, undrar om inte just det är förklaringen till att min i7-8559U är lite mer än dubbelt så snabb som 2700X på att skicka små datapaket mellan VM:ar eller containers? Framförallt givet att MDS fixen sänkte prestanda med ~5 % på Intel-systemet (men det är ju fortfarande ungefär dubbelt så snabbt på just detta fall).

Skriver en x86 address till A följt av B så kräver ISA-specifikationen att en CPU-tråd som ser nya värdet på B måste se nya värdet på A, det även utan explicit synkronisering. Kan verka logisk, nog denna skenbara logik som gjorde att man specade det hela just så en gång i tiden. Men i alla moderna definitioner kommer man ändå ha ett data-race utan explicit synkonisering -> vilken ordning saker blir synliga i det icke-synkroniserade fallet är totalt irrelevant

På ARM är ordning load-load, store-store, load-store och store-load helt odefinierad utan explicit synrkonisering -> behövs inte alls lika mycket kisel för att kunna göra "rollback" på spekulativa minnesoperationer. AMD har i de flesta fall valt att skippa spekulation här, medan Intel valt att uppföra sig som ARM på mikroarkitekturnivå men sedan (försöker) man fixa till x86 ordningen innan den blir synlig på programnivå.

Är nog väldigt stor risk att AMD kommer få utnyttja det som nämns på sista raden

"Another mechanism some AMD processors use to improve performance of a load operation allows loads to bypass older stores that do not yet have an address calculated. The load is allowed to access the cache and provide that data to younger instructions for speculative execution.
...
This behavior can be disabled architecturally on processors that support the speculative store bypass disable feature"

I vissa lägen måste en high-end x86 göra saker som på programnivå inte är korrekt enligt x86-specifikationen, man förlorar helt enkelt för mycket prestanda idag annars då RAM-latens inte alls hängt med övriga delar de senaste 20 åren. Men leter man bara tillräckligt mycket är jag rätt säker på att man kommer behöva utnyttja det plåster man nämner i sista meningen.

Icke-problem för ARM, där är det helt tillåtet att man på programnivå ser en äldre "store" ta effekt efter en yngre "load". Är det ett problem ska programmeraren (i praktiken 2019, kompilatorn) lägga ut erforderliga instruktioner för att ordna operationerna. I det läget upphör spekulation. Är ungefär så man fixar spectre på alla CPUer, lägga ut synkroniserande instruktioner på "bra" ställen, att alla out-of-order CPUer är mottagliga för Spectre beror i praktiken på att den designen har den svagheten.

Och om Intel lyckas patcha sin design utan att helt kapa alla de ställen de idag spekulerar på sätt som inte är "x86 OK" så kommer det ge dem en prestandafördel i saker som är latenskritiska (som t.ex. I/O med hög frekvens).

Visa signatur

Care About Your Craft: Why spend your life developing software unless you care about doing it well? - The Pragmatic Programmer

Permalänk
Medlem
Skrivet av Yoshman:

Nog läge för en uppdatering om du är rädd för MDS

Kommer inga nya bios till det gamla moderkortet, isåfall måste jag göra ett eget bios med Intels nya mikrokod infogad. Kommer inte att hända, jag väntar på Zen 2 så tar jag helt enkelt Intel-burken ur tjänst. 2700X blir Linux-burk och Zen 2 spelburk.

Visa signatur

|| R9 7950X MSI PRO X670-P WIFI 32GB-6400c30 MSI RTX4080 Ventus 3X OC || i9 12900KF MSI Z690 Tomahawk WIFI DDR4 32GB-3600c16 TUF RTX3080 OC V2 || R7 5800X3D CH VIII Extreme 32GB-3800c18 Gigabyte RTX3080 GAMING OC || R9 5900X(B2) B550-F 32GB-3800c18 EVGA RTX3070 FTW Ultra || R9 3900X X470-Prime Pro 32GB-3200c16 MSI RTX2070 Super || Thinkpad P16s Gen 2 R7 PRO 7840U(Zen4) 32GB-6400 1TB 980Pro 780M

Permalänk
Datavetare
Skrivet av the squonk:

Kommer inga nya bios till det gamla moderkortet, isåfall måste jag göra ett eget bios med Intels nya mikrokod infogad. Kommer inte att hända, jag väntar på Zen 2 så tar jag helt enkelt Intel-burken ur tjänst. 2700X blir Linux-burk och Zen 2 spelburk.

Du kör ju Linux, där stöds firmware-patching från kärnan (något jag tror Win10 också fått på sistone?).

Jag har inte uppdaterat BIOS på någon av Intel-system som nu har fixarna för all de fall där den som attackerar och blir attackerad kör på samma CPU-tråd. Det tätar den enda reella hotbild jag ser på en dator där man inte låter okända köra valfritt program på systemet: Java Script i webbläsaren.

Problemen med SMT med patcharna ovan applicerade verkar vara rätt mycket som Spectre variant 2 och Meltdown, då det krävs att det program som attackerar måste finnas på datorn är de icke-problem (JS fungerar bara via Spectre variant 1, så det måste man patcha. JS verkar inte heller fungera som attackvektor m.h.a. MDS+SMT utan är fallet utan SMT man utnyttjar då). Om någon elaking redan tagit sig in på datorn finns det långt enklare sätt än MDS/Spectre/Meltdown för att nå root!!!

Är precis det RedHat säger också, många användingsfall påverkas inte speciellt mycket av dessa. Är primärt öppna molntjänster där inte vet vilka andra som kör på samma maskin där detta är en rejäl huvudvärk.

Visa signatur

Care About Your Craft: Why spend your life developing software unless you care about doing it well? - The Pragmatic Programmer