Allvarligt säkerhetshål upptäckt i Intels processorer

Skadeglädje är den enda sanna glädjen. Problemet är att de flesta kör med Intel cpuer och dessa prestandaförluster som visades är helt oacceptabla.

Det är bara säg f-ck the security och köra vidare för många. Ofta är maskiner så väl skyddade så att obehöriga ej har tillgång till dem, om ett tag släpper Intel åtgärdade processorer och då får man byta ut dem.

*edit*
Min 7700K säger från och med idag adjö till internet, det var trevligt så länge som det varade. Efter jag har läst på lite, så blev valet enkelt, strunta i uppdateringen och ta bort internetaccessen.
Nu använder jag datorn mest till labb och inte surfdator eller annat.

Senast redigerat 2018-01-03 12:33

Alla fel som intel och nvidia gör glöms bort månaden efter det uppmärksammas. Folk har redan glömt bort det förra ännu större säkerhetshålet som dem har haft i 10+ år.

Skickades från m.sweclockers.com

Eftersom det endast är Intel som berörs så förmodar jag att AMD VD Lisa T. Su sitter med ett stort leende på läpparna just nu. Ska bli intressant att se lite prestanda tester efter patchen är gjord.

Är det värt att göra återköp på min ouppackade 8700k nu? Känns surt, men desto dyrare för de som inte har något val.

Skickades från m.sweclockers.com

Skrivet av the squonk:

Om det stämmer att AMD har tänkt mer på säkerhet i sin grunddesign än Intel så vinner dom mycket goodwill, är prestandaskillnaden marginell vill nog dom flesta köra det säkrare alternativet.

mellan 5-30 %, läste från finska tidningen
https://www.is.fi/digitoday/art-2000005511189.html

Kanske man skulle slå till på en Ryzen 5 1600 till januarilönen, jag kör ganska många vmplayer maskiner och 12 trådar skulle sitta bra.

Skrivet av Crentus:

Är det värt att göra återköp på min ouppackade 8700k nu? Känns surt, men desto dyrare för de som inte har något val.

Beror på vad du ska göra med den.

Spelprestandan lär inte påverkas nämnvärt (om ens alls), så det kommer fortfarande vara den överlägset bästa processorn på marknaden för spel.

Håller du på med VM och dylikt så hade jag sagt "vänta" tills du vet hur mycket prestandan faktiskt kommer att försämras, såvida din öppet-köp tid inte håller på att ta slut dvs.

Undrar hur detta kommer att påverka serverområdet. Känns delvis som en walkover. Vem vill köra på dyra, osäkra och långsamma CPUer när det alternativ?
Intel kunde använt det påstådda klistret de sa EPYC-processorna har att täta en och annan egen läcka

Skrivet av Viochee:

Detta lät inget vidare... För Intel

Verkar även innebära prestandaförluster för AMD på Linux sidan...
Då man hittills behandlat fixen cpu_insecure som "All X86" oavsett tillverkare.
Hoppas man löser detta så snart man rett ut om AMD inte berörs av samma sårbarhet.

Måste kännas skönt att betala det där "lilla" extra ~ 100% för denna feature nu i efterhand!
Nu borde Epyc kunna få en del av kakan efter det här fiaskot som uppenbarligen är över 10 år gammalt.
Sen hoppas nu inte AMD blir påverkade av Intels klanteri och förhoppningsvis haglar stämningarna mot Intel snart!

Borde vara väldigt tråkigt för ex Google,Amazon,Facebook mfl med tusentals Intel cpus att vårda lite extra nu

Senast redigerat 2018-01-03 14:02
Skrivet av anon159643:

Skadeglädje är den enda sanna glädjen. Problemet är att de flesta kör med Intel cpuer och dessa prestandaförluster som visades är helt oacceptabla.

Det är bara säg f-ck the security och köra vidare för många. Ofta är maskiner så väl skyddade så att obehöriga ej har tillgång till dem, om ett tag släpper Intel åtgärdade processorer och då får man byta ut dem.

*edit*
Min 7700K säger från och med idag adjö till internet, det var trevligt så länge som det varade. Efter jag har läst på lite, så blev valet enkelt, strunta i uppdateringen och ta bort internetaccessen.
Nu använder jag datorn mest till labb och inte surfdator eller annat.

Blir att använda min 8600K maskin som htpc nu och spela upp film och ha till musik biblioteket, offline såklart.

Skrivet av ThomasLidstrom:

Undrar hur detta kommer att påverka serverområdet. Känns delvis som en walkover. Vem vill köra på dyra, osäkra och långsamma CPUer när det alternativ?
Intel kunde använt det påstådda klistret de sa EPYC-processorna har att täta en och annan egen läcka

Fasen... Jag hade nästan glömt deras gliringar om "glued together" på Epyc... Det blir nog lite fler Epyc's i serverhallarna framöver då verkar det som.

Däremot tror jag inte AMD's styrelse sitter och hånler eller gnuggar händer nu, det är inte så det går till.

Jobbar själv inom IT och en av våra konkurrenter råkade ut för ett stort dataras för några år sedan. Men man sitter ju och lider med dem, inte hånskrattar. Det är människor bakom det hela, och så är även fallet nu. Det blir många som får jobba extra framöver.

Skrivet av anon200632:

Blir att använda min 8600K maskin som htpc nu och spela upp film och ha till musik biblioteket, offline såklart.

Om du bara använder datorn till sånt så är det ingen fara. Många har dock extrema problem med att cpun är på tok för slö som den redan är. Och det pratas om rejäla prestandaförluster för laster som verkligen behöver ha cpukraft, man har då ett val.
Mitt val blir att behålla prestandan och isolera datorn, såvida inte prestandaförsämringen är överdriven.
Jag har dessutom runt 10st datorer i lägenheten så det är inga problem att isolera någon mer, min AMD burk har av naturliga orsaker ej internet access, men tanken med inteldatorn var just att köra mindre laster som jag snabbt testar på. Där vissa laster kunde behöva internetåtkomst.

*edit*
Mitt sätt med att isolera datorn strunta in uppdateringen gör att jag nu kommer få en cpu som för vissa laster är den snabbaste som finns.

Skrivet av Icte:

Är detta inget Intel själva kan lösa med en mikrokodsuppdatering? Om inte, kommer denna "fix" även påverka prestandan i dessa OS i datorer med AMD-CPU:er under huven?

Det är någorlunda bekräftat att prestandan blir lidande med AMD cpu om man kör Linux.
Dock går det att disable:a patchen vid uppstart i Linux om man vill slippa sämre prestanda.
Hoppas dock att det inte blir ett nödvändigt måste i framtiden.

Skrivet av krigelkorren:

Verkar även innebära prestandaförluster för AMD på Linux sidan...
Då man hittills behandlat fixen cpu_insecure som "All X86" oavsett tillverkare.
Hoppas man löser detta så snart man rett ut om AMD inte berörs av samma sårbarhet.

Fast på Linux gick det att stänga av för både Intel och AMD

Senast redigerat 2018-01-03 13:12
Skrivet av Bloodstainer:

För kunden. Intel har gjort bort sig förut, knappast någonting som biter särskilt hårt tyvärr

Du tror inte Google / Amazon stämmer Intel om deras servrar tappar 30% prestanda?

RedGamingTech's video om de hela https://www.youtube.com/watch?v=9xhNY7v1R80

Skrivet av GoPaw:

Jag får alltid kännslan av att han inte riktigt vet vad han snackar om utan mest läst saker som han återberättar. När han skall dra en "enklare förklaring" så känns det fota väldigt krystat och flera gånger nästan orellaterat till vad nyheten handlar om. Men jag kan självklart ha fel

Smart användning av en grej i Intel-processorer som heter "PCID" borde kunna förhindra en del av prestandaförlusten, men bara i 64-bittars OS. Jag har inte hittat info om att AMD skulle ha stöd för det.
Det har funnits stöd för PCID på Intel sedan Haswell men i Linux-kärnan för x86-64 först sedan i höstas. Jag har ännu inte sett om PCID används på det sättet för att fixa det här problemet däremot ...

Börjar bli dags att sparka ut mitt intel system och köra amd och det här stärker bara den känslan

Tråkigt när det finns folk som gjort inköp på vissa siffror och sedan visar det sig vara något annat

Men verkar som prestandan i spel inte påverkas? https://www.phoronix.com/scan.php?page=news_item&px=x86-PTI-I... Vilket är bra nyheter för dem som bara spelar på sina datorer

Men jag tror att datacenter snubbarna blir pissed nu. Lisa lär iallafall informera dem om någonting som heter Epyc.

Skrivet av Viochee:

Du tror inte Google / Amazon stämmer Intel om deras servrar tappar 30% prestanda?

Det återstår att se, men nu är ju inte alla servrar 100% CPU bundna, och vi vet fortfarande inte riktigt vart den här 30% siffran är plockad från.

Skrivet av Icte:

Är detta inget Intel själva kan lösa med en mikrokodsuppdatering? Om inte, kommer denna "fix" även påverka prestandan i dessa OS i datorer med AMD-CPU:er under huven?

Det kan inte lösas med en mikrokodsuppdateirng utan att man stänger av stora delar av hela OoOE, och det orsakar ännu värre (och mer generella) prestandaförluster

Skrivet av the squonk:

Det ryktas också att den här säkerhetsbristen har varit känd i bortåt 20 år av cpu-designers, men att Intel valde att designa sina processorer på detta sätt för att vinna prestandafördelar och hoppades att ingen skulle upptäcka det. Själva designvalet var tydligen aktuellt redan på VMS-tiden.

Mja. Design-valet är att ha en enda TLB istället för två. TLBn används för att översätta virtuella adresser till fysiska. En del andra arkitekturer, bland annat PPC, använder två TLBer - en som bara används av processer i supervisor-läge (det som heter Ring 0 på x86 - alltså kerneln) och en för övriga. Intel har bara en och låter OSet hålla kolla på vilka delar av den som programmen skall få tillgång till. Det verkar vara en DEL av problemet, men det går att göra en lösning med en TLB säker - AMD har ju gjort det. Det här är en bugg från Intel's sida.

Skrivet av SeF.Typh00n:

Den är extremt liten (ingen?) chans att det påverkar vanliga användare. Men det är allvarligare för virtuella miljöer hos företag.

Det finns uppenbarligen en exploit som är praktisk att använda mot moln-leverantörer, men jag skulle inte vara så säker på att vi kan blåsa faran över för övriga. Själva grundproblemet, att man kan läcka information från kerneln till icke-privilegierade program, går t.o.m att göra i Javascript.

Skrivet av Pepsin:

Det ryktas om att patchen kommer appliceras även på AMD för säkerhets skull (trots att AMD själva sagt att de inte påverkas av detta säkerhetshål). Surt att man som Ryzen-ägare ska bli lidande av sämre prestanda p.g.a Intel klantat sig.

Sannolikt blir det inte så. MS och diverse Linux-distributörer tävlar med varandra om platser i molnet, och om någon kan leverera en lösning som är 5-30% snabbare på AMD-processorer, så kommer de nog att se till att göra det. Konkurrens är bra.

Skrivet av Ant3:

Men Vilka CPU-er gäller det?

Det finns två olika lösningar som implementerats. En av dem kostar lite mindre prestanda, men bygger på att CPUn har en funktion som heter CPID. Linux implementerar bägge två, vilket betyder att buggen påverkar processorer som inte har CPID. Den sista generationen som saknar CPID är Nehalem (första Core i7), så den sträcker sig MINST så långt bakåt. Med tanke på att OoOE inte ändrats så mycket mellan Nehalem och Conroe innan dess, är sannolikt även Conroe (Core 2) påverkad.

Skrivet av Radolov:

Tråkigt när det finns folk som gjort inköp på vissa siffror och sedan visar det sig vara något annat

Men verkar som prestandan i spel inte påverkas? https://www.phoronix.com/scan.php?page=news_item&px=x86-PTI-I... Vilket är bra nyheter för dem som bara spelar på sina datorer

Men jag tror att datacenter snubbarna blir pissed nu. Lisa lär iallafall informera dem om någonting som heter Epyc.

Ja gamers klarar sig alltid. Men detta drabbar otroligt många som gör något vettigt med sina datorer.

Hur stor påverkan detta har på Epyc, så är har epyc det tufft när det är för ny. Jag tror många avvaktar och kör med det de har tills intel släpper uppdaterade processorer, förhoppningsvis kan de enkelt göra detta så det är bara att plugga in nya.
-Lite svårare än att uppdatera mikrokod, men kostnadsmässigt så blir nya cpuer det billigast för många.
Om nu inte felet är så allvarligt så Intel behöver lång tid på sig.

Jag ser det lite som när biltillverkare återkallar bilar och byter ut felaktiga komponenter.

Kan det bli utbytes program då man köpt en vara som sedan är/har blivit sämre?

Skrivet av Findecanor:

Smart användning av en grej i Intel-processorer som heter "PCID" borde kunna förhindra en del av prestandaförlusten, men bara i 64-bittars OS. Jag har inte hittat info om att AMD skulle ha stöd för det.
Det har funnits stöd för PCID på Intel sedan Haswell men i Linux-kärnan för x86-64 först sedan i höstas. Jag har ännu inte sett om PCID används på det sättet för att fixa det här problemet däremot ...

PCID finns i Westmere. Det finns ett senare tillägg som heter INVPCID som verkar ha kommit i Haswell. Poängen med det första är att man kan dumpa bara delar av TLBn från cache när man gör en context switch, istället för att alltid dumpa allt. Det andra ger lite mer detaljerad kontroll över funktionen, tror inte att de instruktionerna behövs hör.

Den stora frågan nu är ifall Intel kommer göra en återinkallning eller kompensation. Ifall det gör det tror jag att de kommer begränsa den till modernare processorer.

Skrivet av Ozzed:

Fasen... Jag hade nästan glömt deras gliringar om "glued together" på Epyc... Det blir nog lite fler Epyc's i serverhallarna framöver då verkar det som.

Däremot tror jag inte AMD's styrelse sitter och hånler eller gnuggar händer nu, det är inte så det går till.

Jobbar själv inom IT och en av våra konkurrenter råkade ut för ett stort dataras för några år sedan. Men man sitter ju och lider med dem, inte hånskrattar. Det är människor bakom det hela, och så är även fallet nu. Det blir många som får jobba extra framöver.

Om det nu hade funnits några Epyc-servrar att ens köpa...

HPEs affärsfasoner är vedervärdiga (och 385 Gen 10 är svår att få tag på) och Dell har fortfarande inga alternativ. Den enda vettiga tillverkaren som finns kvar är Supermicro och det är svårt att motivera/köpa in.

Jag håller hoppet uppe för att Dell faktiskt släpper en variant någon gång men det är sjukt vad tid det ska ta.

Skrivet av Bloodstainer:

Det återstår att se, men nu är ju inte alla servrar 100% CPU bundna, och vi vet fortfarande inte riktigt vart den här 30% siffran är plockad från.

Jag har sett flera tester, bland annat enkla SQL queries mot Sybase SQL där skillnaden var 17% best case och 24% eller något worst case.