Sikkerhet eller fart? Den nyeste Linux-kjernen kan føre til dramatisk ytelsessvikt

[Harald Brombach (digi.no)]

Her må dere i Digi lage en oppfølgingssak, det blir ikke en dramatisk ytelsesreduksjon med kernel 4.20 likevel: https://www.phoronix.com/scan.php?page=article&item=linux-420wip-stibp&num=1

Takk. Det kommer en oppfølger løpet av dagen.

[Gjest Slettet+5132]

Spesifikasjonene lister bare opp Ghz og ikke ytelse, meg bekjent.

 

Men intel publiserer samtidig listen over alle instruksjoner og hva disse gjør, det må anses som en del av spesifikasjonen. Mitt spørsmål er om oppførselen er annerledes enn i spesifikasjonen, eller om oppførselen er innenfor spesifikasjonen.

[zeebra]

Dette er forøvrig ikke på langt nær så ille som diesel gate. Intel har såvidt jeg kan se ikke gjort noe for å lyve i en måling, slik som skjedde i dieselgate. De gjorde en ærlig feil.

 

Mulig det var en ærlig feil men teknologien som førte til sårbarhetene ble innført for å fortsette "ytelsesracet", denne gangen med "smarte mikrokodeteknolgier" som fører til at hele prosessen blir utfør på en annen og mer slurvete måte.

 

Man kan vel si at Intel og AMD har et visst ansvar her, og at prosessorteknologi ikke kun bør handle om å øke ytelsen med alle midler man kan finne. Intel har ikke bevisst skapt sikkerhetshull i sin egen teknologi, men uforsettlig har de innført en teknologi som de helt sikkert var klar over kunne skape problemer, uten at det var verken motivet eller hensikten. Motivet og hensikten rettferdiggjør alikevel ikke tiltaket, noe som gjør at jeg mener Intel og AMD har delvis skyld i problemene. Både Specter og Meltdown.

 

Intel som eksempel har optimalisert sine prosessorer for markedsføring, ikke for bruk. Selv 10-15 år gamle prosessorer fungerer helt utmerket til de fleste oppgaver man har bruk for de i, selv idag. Som så har Intel forsømt sine oppgaver og er selv skyld i problemet.

[Hotwire720]

AMD-baserte systemer skal naturlig nok ikke være uberørt av STIBP og ytelsestapet dette medfører.

 

En liten dobelt nektings feil. Jeg ville forventet at det naturlige var at AMD ikke var berørt av en Intel feil. Her står det at de naturligvis er berørt siden ikke uberørt er berørt.

[Emancipate]

Men intel publiserer samtidig listen over alle instruksjoner og hva disse gjør, det må anses som en del av spesifikasjonen. Mitt spørsmål er om oppførselen er annerledes enn i spesifikasjonen, eller om oppførselen er innenfor spesifikasjonen.

Oppførselen er innenfor spesifikasjonen ytelsesmessig, så vidt jeg vet. Selvsagt er det ikke innenfor spesifikasjonen at det er et sikkerhetshull.

[frodenerd]

Jeg vil bare si at Intel sine prosessorer leverer samme ytelse med eller uten denne sikkerhetsmekanismen i Linuxkjernen. Det er nok for Intel helt uvesentlig at du velger å bruke klokkesykluser på sikkerhet. Det blir som om du skulle reklamert for at maskinen blir tregere etter å ha installert antivirus.

 

Lurer forøvrig på om Windowskjernen har samme ytelsestap?

[Harald Brombach (digi.no)]

AMD-baserte systemer skal naturlig nok ikke være uberørt av STIBP og ytelsestapet dette medfører.

 

En liten dobelt nektings feil. Jeg ville forventet at det naturlige var at AMD ikke var berørt av en Intel feil. Her står det at de naturligvis er berørt siden ikke uberørt er berørt.

Du har helt rett. Har rettet nå. AMDs prosessorer er ikke berørt. 

[Sandormen]

...Og de som ikke er spesiellt sikkerhetsinteresert fyller/får så mye søppel på PC’n likevel at det er unødvendig med et sånt botemiddel.

Personene i mente har så rævkjørte pc’er at et sånt ‘botemiddel’ vil sørge for at maskinene som allerede kjører med halv fart, vil bruke lengre tid enn det tar å laste et spill på en C64 fra midten av 80-tallet.

 

På tide Intel redesigner hele prosessorstyret, ved at Microsoft samtidig skroter x86-støtten på sin side.