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

Trädvy Permalänk
Medlem
Plats
Vid datorn
Registrerad
Apr 2002
Skrivet av Yoshman:

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)

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).

Precis det här är början på slutet för x86, fattar inte varför inte Amd inte satsar på ARM. Intel borde göra det också.

Live for fun, Loyal to none

Trädvy Permalänk
Medlem
Registrerad
Okt 2004
Skrivet av ExcZist:

Oroar mig fortfarande inte för jag spelar knappt längre..Så blir jag hackad så blir jag det och då måste dem ju få tag i min mail och telefon. Men jag spelar högst 4 timmar per dag om jag har ork och lust efter jobbet.
Men om der så illa så borde flera miljoner datorervara hackade och ha detta nu?

😆😆😆. Förlåt. Det är förmodligen jag som skiljer mig från mängden, men
"spelar inte längre......spelar högst 4 timmar per dag...". 😂😂😂

Skickades från m.sweclockers.com

Det är farligt att leva... man kan dö!

Trädvy Permalänk
Medlem
Registrerad
Dec 2014
Skrivet av JooJ:

😆😆😆. Förlåt. Det är förmodligen jag som skiljer mig från mängden, men
"spelar inte längre......spelar högst 4 timmar per dag...". 😂😂😂

Skickades från m.sweclockers.com

Hahaha mjaaa såg det nu när du skrev det... blev fel stavat där xD
Spelar inte mycket längre ska det stå.... Haha XD

Chassi: Corsair Obsidian 800D | MB: Asus P6T SE | CPU: Intel Core i7 920@4.3Ghz | Kylare:Custom WaterCooler| RAM: Blandade Corsair 24GB 800Mhz | GPU:Nvidia Geforce GTX 780 | PSU:Corsair HX1200 | TGB: Logitech G11 | Mus: Logitech MX518 | Ljud:Corsair Void Pro Wireless Surround

Trädvy Permalänk
Medlem
Plats
Stockholm
Registrerad
Mar 2004
Skrivet av Yoshman:

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.

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

Notebook Envy 15" 4K IPS 7500U 16GB DDR4@2133MHz 256GB NVMe USB-C
2018Ed. X470-Pro 2700X DRP4 32GB@3000MHz(LPX) 1080Ti@H2O NZXT H700
2014Ed. Z87-A 4790K NH-D14 16GB@2133MHz/cl11 1070FE 8GB
Portabelt BT ljud: LG G7 ThinQ / Sony WH-H900N h.ear on 2(LDAC)

Trädvy Permalänk
Medlem
Plats
Uppsala
Registrerad
Aug 2015
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

Nej det du tänker på var den där fula fake grejen, det var rebranded spectre som någon Intel shill skrev falskheter om. Det var i stort sett bara dålig rapportering på Meltdown och Spectre som de försökte vrida till att AMD var mer drabbade, vilket inte riktigt stämde.

PC #1 CPU: R5 1600 @3.8 Motherboard: B350-A PRIME GPU: EVGA 1080 Ti
PC #2 CPU: i7 3770K @4.2 Motherboard: P8P67 GPU: AMD R9 290X

Trädvy Permalänk
Medlem
Plats
Uppsala
Registrerad
Aug 2015
Skrivet av filbunke:

Intel försökte även "muta" de som hittade säkerhetshålet med lite extra pengar så att det inte skulle uppfattas lika allvarligt, $40.000 i "bug-bounty" plus $80.000 som gåva istället för en "bug-bounty" på $100.000....

foliehat-much? Om du som företag betalar för att folk hittar säkerhetsnålar så kommer fler folk leta, inte färre, så köper inte det argumentet, särskilt eftersom du kan publicera efter betalning. Däremot kanske de har en embargotid vilket är helt logiskt med tanke på att vara whistleblower för icke-funktionella system innan systemintegratören/skaparen kan täcka igen de hålen är oerhört oprofessionellt och skadligt mot användare.

PC #1 CPU: R5 1600 @3.8 Motherboard: B350-A PRIME GPU: EVGA 1080 Ti
PC #2 CPU: i7 3770K @4.2 Motherboard: P8P67 GPU: AMD R9 290X

Trädvy Permalänk
Medlem
Plats
Norrland
Registrerad
Okt 2008
Skrivet av sKRUVARN:

Ja, hur kan säkerhetsbristen utnyttjas och hur ser själva attacken ut? Känns väldigt relevant info för att kunna göra en bedömning hur allvarligt det är för ens egen sfär.

Imo är detta https://blogs.technet.microsoft.com/msrc/2019/05/14/prevent-a... en större nyhet, och ett säkerhetshål som antagligen kommer drabba betydligt fler.

Skrivet av cheben:

Det är ganska troligt att det kommer vara ett större och mer "uppenbart" problem med de buggarna som hittats i XP etc. I alla fall de närmaste veckorna. Den klassades som "trivial" att utnyttja. Du behöver bara sända lite speciell trafik till en specifik port sen så är du klar. Microsoft tror att deras patch kommer vara rekunstruerad och exploitkod finnas ute inom 24 timmar. Är porten exponerad så kommer du bli "owned" om någon försöker. Exploiten tillåter dig att köra arbiträr kod på måldatorn, som troligtvis sitter i någon form av jätteviktig applikation, såsom sjukhus eller industrikontroll

Intelbuggarna kräver att du kör kod på datorn (webbläsare eller cloud), och är mer lämpade att få ut information, som måste vara i cache för att fungera. Inte precis en liten sårbarhet, men drar man slutsatser från WannaCry (tror det var WannaCry) och de andra intelbuggarna så är det troligt att RDP buggen kommer orsaka större problem för allmänheten. Hade jag värdefull info som någon vill ha tag på så kanske man skall vara mer orolig för intelbuggarna

XP buggarna är lättare att pacha dock, so thats nice!

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.

Trädvy Permalänk
Medlem
Plats
Karlstad
Registrerad
Nov 2010
Skrivet av blue eyed devil:

Precis det här är början på slutet för x86, fattar inte varför inte Amd inte satsar på ARM. Intel borde göra det också.

Folk i allmänhet skiter i säkerhet, det viktiga är antal fps i VGA upplösningar 640*480 och lägre. Detta leder till att sånt här inte får så stor påverkan. Jag ser det lite som kassetavgiften, där nästan alla här på sweclockers forum är upprörda, men folk i allmänhet bryr sig inte det minsta.

För övrigt pågår en förändring i arbetssättet på en dator. För 10år sedan var övergång från x86 mer eller mindre otänkbart, nu idag blir det bara mer om mer serverlösningar där användaren endast har en html5 klient.
Dessa serverlösningar går emot att bli enklare att köra på linux och armprocessorer. Tar folks arbetsdator så går det emot att allt de behöver ha är en riktig snabb webbläsardator och där blir arm bara mer intressant för varje år.
Så jag ser en intressant utvecklingen framför mig.

Trädvy Permalänk
Medlem
Registrerad
Maj 2012

@Paddanx: Förstår det perspektivet också. Naiva och okunniga tankar har jag ibland

På en tidigare anställning fick vår CIO spunk och bestämde sig för att alla klienter skulle upp till Windows 10, pronto, igår.

Förutom lite problem med drivrutiner, kompabilitet med vissa äldre programvaror så fungerade relativt bra. Däremot mängden fanskap till bloatware som dem pumpar på Enterprise versioner är ju löjligt. Man skulle ju tro att det man ser på en Home version är begränsat där men det var samma skit. Och ja, enkla scripts löste detta men i min åsikt är det högst oprofessionellt att Enterprise versioner av OS:et ska installeras direkt efter boot med massa jäkla spelannonser, netflix osv. (högst irrelevant för tråden, i know)

// i7 7700k @4,8Ghz // NZXT Kraken x41 // GTX 1080 Strix // G.Skill 2x8gb @3000 mHz // Gigabyte Z270X Gaming K5 // Samsung 850-Series EVO 500GB // Corsair RM650x // NZXT S340 Elite//

Trädvy Permalänk
Medlem
Plats
Stockholm
Registrerad
Sep 2002
Skrivet av BM-Mods:

Kanske vore något, då lär dom väl kanske lära sig, men gissar på att summan egentligen skulle bli en piss i rymden för dom, men om detta gäller Server CPUer också så kanske företag skulle stämma och då skulle det ju säkerligen ge mycket större effekt.

Man skulle kunna tänka sig att många företag skulle stämma. Men har själv jobbat på global företag som aldrig tänkt på att stämma utan bara blundar och väntar på server/OS patchar bara.

[Antec Sonata III - Antec 500w] - [Intel E8500 3,16Ghz] - [Asus P5Q Pro] - [Gainward HD-4850 512MB GS] - [6gb Corsair TWIN2X 6400C4DHX CL4] - [Intel 730 240GB] - [Seagate 3TB ST3000DM001] - [WD Black 1TB WD1001] - [Seagate 500GB ST3500413AS] - [Seagate 320GB ST3320620A] - [Creative Sound Blaster Live 5.1] - [Logitech Z-906] - [Samsung SyncMaster SyncMaster 2232BW]

Trädvy Permalänk
Medlem
Plats
Nora
Registrerad
Jul 2013
Skrivet av AshyStyle:

Man skulle kunna tänka sig att många företag skulle stämma. Men har själv jobbat på global företag som aldrig tänkt på att stämma utan bara blundar och väntar på server/OS patchar bara.

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.

Main
MOBO: MSI B350M MORTAR, CPU: RYZEN 5 1600 @ 3.8GHz, RAM: 4x4GB DDR4 2933MHz, GPU: KFA2 GTX1080 EXOC SNPR, SSD: TOSHIBA TR150 480GB Chassi: NZXT H400i Svart/Rött, PSU: CoolerMaster V750 80+ Gold, Skärm: AOC G2460PF

Trädvy Permalänk
Medlem
Plats
Malmö
Registrerad
Maj 2014
Skrivet av blue eyed devil:

Precis det här är början på slutet för x86, fattar inte varför inte Amd inte satsar på ARM. Intel borde göra det också.

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.

Trädvy Permalänk
Medlem
Registrerad
Okt 2005
Skrivet av Elgreco1:

@Paddanx: Förstår det perspektivet också. Naiva och okunniga tankar har jag ibland

På en tidigare anställning fick vår CIO spunk och bestämde sig för att alla klienter skulle upp till Windows 10, pronto, igår.

Förutom lite problem med drivrutiner, kompabilitet med vissa äldre programvaror så fungerade relativt bra. Däremot mängden fanskap till bloatware som dem pumpar på Enterprise versioner är ju löjligt. Man skulle ju tro att det man ser på en Home version är begränsat där men det var samma skit. Och ja, enkla scripts löste detta men i min åsikt är det högst oprofessionellt att Enterprise versioner av OS:et ska installeras direkt efter boot med massa jäkla spelannonser, netflix osv. (högst irrelevant för tråden, i know)

Stäng av "Microsoft Consumer Experiences" via gpo. Blockar det mesta iaf.

Custom image som man rullar ut via pxe + en bunt win10 specifika gpo:er, wsus för patchning och defer på feature updates så man ligger ca sex månader efter mainstream sen funkar win10 rätt bra i enterprise miljö som klient OS.

Största huvudvärken vi har haft är drivers som gått sönder vid nya feature updates. På sex månader brukar man dock ha tid att hitta lösningar på det mesta. Nu senast hade 1809 sönder vlan-taggning och teaming igen med intel drivers... Och inte för att nämna hur de ändrar funktioner och gpoer för varje update... Man måste lusläsa ändringarna varje gång för att inte något ska sluta fungera. Ett exempel är att de helt plötsligt tog bort möjligheten att stänga av consumer experiences på Pro utgåvan.

Trädvy Permalänk
Medlem
Plats
Stockholm
Registrerad
Sep 2002
Skrivet av BM-Mods:

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.

Det är nästan som att de blundar bara för att läget är för jobbigt helt enkelt och kräver mer jobb än en jobbet under en vanlig arbetsdag. SMH.

[Antec Sonata III - Antec 500w] - [Intel E8500 3,16Ghz] - [Asus P5Q Pro] - [Gainward HD-4850 512MB GS] - [6gb Corsair TWIN2X 6400C4DHX CL4] - [Intel 730 240GB] - [Seagate 3TB ST3000DM001] - [WD Black 1TB WD1001] - [Seagate 500GB ST3500413AS] - [Seagate 320GB ST3320620A] - [Creative Sound Blaster Live 5.1] - [Logitech Z-906] - [Samsung SyncMaster SyncMaster 2232BW]

Trädvy Permalänk
Medlem
Plats
Stockholm
Registrerad
Apr 2005

Ö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?

CHASSI - BeQuiet Dark Base 900 Pro - CPU - Delidded Intel i7 8700K OC 5000Mhz @ 1,375V LLC 6 - MOBO - ASUS Z370 ROG Strix E-Gaming - GPU - ZOTAC 1080 Ti AMP EXTREME Core - RAM - 16GB G.Skill DDR4 3000Mhz - PSU - Seasonic 750W 80+ GOLD - AIO - NZXT Kraken X62 280mm - SSD - 500GB Samsung 970 EVO - MONITOR 25" ASUS ROG Swift PG258Q 240Hz - CHAIR - Maxnomic Chief Pro TBE - MISC - Corsair K70 LUX - Steelseries QcK Heavy - BENQ Zowie EC2-B

Trädvy Permalänk
Hjälpsam
Plats
Karlskoga
Registrerad
Jan 2007
Skrivet av Weestman:

Ö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".

AMD Ryzen 7 1700 | Vega RX 64 | 64 GB Corsair @2933 MT/s | https://valid.x86.fr/fgqnte | Stockkylaren | Bitfenix Whisper M 750W.
AMD FX8350 | Polaris RX 460 4 GB | 32 GB Kingston ECC | https://valid.x86.fr/0q5pkm | Cooler Master V 700W.
HTPC | https://valid.x86.fr/ez1zxw |

Trädvy Permalänk
Medlem
Plats
Nora
Registrerad
Jul 2013
Skrivet av AshyStyle:

Det är nästan som att de blundar bara för att läget är för jobbigt helt enkelt och kräver mer jobb än en jobbet under en vanlig arbetsdag. SMH.

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"

Main
MOBO: MSI B350M MORTAR, CPU: RYZEN 5 1600 @ 3.8GHz, RAM: 4x4GB DDR4 2933MHz, GPU: KFA2 GTX1080 EXOC SNPR, SSD: TOSHIBA TR150 480GB Chassi: NZXT H400i Svart/Rött, PSU: CoolerMaster V750 80+ Gold, Skärm: AOC G2460PF

Trädvy Permalänk
Medlem
Plats
Göteborg
Registrerad
Feb 2016

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

Trädvy Permalänk
Hjälpsam
Plats
Karlskoga
Registrerad
Jan 2007

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...

AMD Ryzen 7 1700 | Vega RX 64 | 64 GB Corsair @2933 MT/s | https://valid.x86.fr/fgqnte | Stockkylaren | Bitfenix Whisper M 750W.
AMD FX8350 | Polaris RX 460 4 GB | 32 GB Kingston ECC | https://valid.x86.fr/0q5pkm | Cooler Master V 700W.
HTPC | https://valid.x86.fr/ez1zxw |

Trädvy Permalänk
Medlem
Plats
Stockholm
Registrerad
Nov 2009
Skrivet av Paddanx:

Priset ska dock inte vara relevant här.

Om du säljer en produkt som du vet inte är säker, eller har defekter, ska du krävas på återkallning av dessa. Problemet ligger i att det "är okej" att släppa vidare produkterna, när man är fullt medvetande om felet.

När en bil får ett säkerhetsfel som hotar säkerheten, måste de återkalla och fixa. Kan de inte göra detta så får de erbjudan en ersättningsprodukt. Och Intel behöver känna svidandet av att de genvägar de tog med tidig HT design, där prestanda var allt och säkerhet var noll, nu får konsekvenser. Alla minsta ska ju samtliga CPUer med HT få återbäring ner till motsvarande icke HT CPU. Så köpte du en 9900k, ska du nu får mellanskillnaden till en 9700k i pengarna tillbaka då du inte kan använda funktionen.

Finns det verkligen en lag som tvingar bilföretag till det? Vilken lag då?
Jag tror de återkallar frivilligt. Intel har faktiskt tidigare gjort utbyten efter att fel blivit kända, men då är det ju ett byte för det lär inte gå att reparera felet som i bilexemplet

Skickades från m.sweclockers.com

Trädvy Permalänk
Medlem
Registrerad
Aug 2015
Skrivet av sniglom:

Undrar om dessa attacker fungerar fint mot HT på gamla P4 också, eller om det bara är modernare implementationer.

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.

Trädvy Permalänk
Medlem
Registrerad
Aug 2015

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

Trädvy Permalänk
Medlem
Registrerad
Aug 2015
Skrivet av lastninja:

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!!
http://www.thg.ru/howto/20010725/images/cpu_1.gif

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.

Trädvy Permalänk
Medlem
Plats
Göteborg
Registrerad
Jul 2001
Skrivet av Bloodstainer:

foliehat-much? Om du som företag betalar för att folk hittar säkerhetsnålar så kommer fler folk leta, inte färre, så köper inte det argumentet, särskilt eftersom du kan publicera efter betalning. Däremot kanske de har en embargotid vilket är helt logiskt med tanke på att vara whistleblower för icke-funktionella system innan systemintegratören/skaparen kan täcka igen de hålen är oerhört oprofessionellt och skadligt mot användare.

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.

Skrivet av SAFA:

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.

Tack, kul att du testade.

Skrivet av lastninja:

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!!
http://www.thg.ru/howto/20010725/images/cpu_1.gif

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.

Ubuntu | 1440p IPS | 7700k | 1080ti | 32GB@3.6GHz | 960 Pro 1TB | Xonar STX

Trädvy Permalänk
Medlem
Plats
Uppsala
Registrerad
Aug 2015
Skrivet av sniglom:

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.

Öh, fast en embargotid är alltid bra för sånt här. Att publicera svagheter tidigt ger bara exploatörer en chans att utnyttja de istället för att tillverkare kan täppa igen hålen.

PC #1 CPU: R5 1600 @3.8 Motherboard: B350-A PRIME GPU: EVGA 1080 Ti
PC #2 CPU: i7 3770K @4.2 Motherboard: P8P67 GPU: AMD R9 290X

Trädvy Permalänk
Medlem
Registrerad
Feb 2005
Skrivet av Bloodstainer:

foliehat-much? Om du som företag betalar för att folk hittar säkerhetsnålar så kommer fler folk leta, inte färre, så köper inte det argumentet, särskilt eftersom du kan publicera efter betalning. Däremot kanske de har en embargotid vilket är helt logiskt med tanke på att vara whistleblower för icke-funktionella system innan systemintegratören/skaparen kan täcka igen de hålen är oerhört oprofessionellt och skadligt mot användare.

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...

Trädvy Permalänk
Hjälpsam
Plats
Karlskoga
Registrerad
Jan 2007
Skrivet av Bloodstainer:

Öh, fast en embargotid är alltid bra för sånt här. Att publicera svagheter tidigt ger bara exploatörer en chans att utnyttja de istället för att tillverkare kan täppa igen hålen.

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

AMD Ryzen 7 1700 | Vega RX 64 | 64 GB Corsair @2933 MT/s | https://valid.x86.fr/fgqnte | Stockkylaren | Bitfenix Whisper M 750W.
AMD FX8350 | Polaris RX 460 4 GB | 32 GB Kingston ECC | https://valid.x86.fr/0q5pkm | Cooler Master V 700W.
HTPC | https://valid.x86.fr/ez1zxw |

Trädvy Permalänk
Medlem
Plats
Uppsala
Registrerad
Aug 2015
Skrivet av filbunke:

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...

Jaha, nej så uppfattade jag det inte. Men jag tror inte att Intel på riktigt är så ointelligenta att de tror att folk inte tar stora säkerhetsrisker på allvar. Sen när började någon kika på just dessa $$-siffror för att avgöra hur illa buggen är? Det är ju självklart att man lyssnar på de som har gjort studien, inte på de som kan komma att förlora på dessa säkerhetsluckor, grundläggande journalistik, om folk struntar i journalistiken och går direkt till den mest obalanserade, biased källan för info så finns det inget någon kan göra åt saken.

PC #1 CPU: R5 1600 @3.8 Motherboard: B350-A PRIME GPU: EVGA 1080 Ti
PC #2 CPU: i7 3770K @4.2 Motherboard: P8P67 GPU: AMD R9 290X