Uforudsigelighed afslørede Hyperthreading-fejl i Intel-processorer

Hardwarefejl i processoren er ikke det første sted, man leder, når et program ikke gør det, man forventer.

Intel Skylake og Kaby Lake processorer indeholder en noget usædvanlig fejl, som kan udløses, når man afvikler kode med meget korte løkker og bestemte registertyper. Men det var sin sag at finde frem til, at fejlen lå i processoren.

Det var formentligt Xavier Leroy, udvikler på OCaml, som først opdagede fejlen. I et blogindlæg beskriver han, hvordan en virksomhed, som brugte OCaml havde problemer med at køre version 4.03 af programmeringssproget. Når de havde compilet deres kode og afviklede programmet, oplevede de af og til, at det crashede.

Læs også: Intel-processorer ramt af mikrokode-bug: Slå hyper-threading fra

OCaml tilhører ML-familien af programmeringssprog med et stærkt typesystem og garbage collection. Brugeren, som rapporterede fejlen, oplevede kun problemer på Skylake-baserede maskiner og kun med programmer skrevet i OCaml.

OCaml er selv skrevet i C og bruger som regel GCC-compileren, og brugerens mistanke var, at der måtte være en fejl i C-koden bag OCaml.

Problemet var, at fejlen opstod tilfældigt. Det var ikke ved hver afvikling, og det var ikke på præcis samme måde. OCaml og GCC kunne meget vel have genereret kode med en fejl, men i så fald ville det være en deterministisk fejl - altså den samme fejl hver gang.

Ved analyser af 30 crashes fandt Xavier Leroy fejlen 7 forskellige steder, og det var sket både i selve applikationen og i OCamls garbage collection. Fælles for dem var, at en pointer i OCamls heap ikke pegede på det rigtige sted.

Det var sådan set ikke en usædvanlig type fejl, hvis der var en fejl i OCaml, men problemet var, at fejlen ikke var forudsigelig. Derfor satte Xavier Leroy sig for at tage muligheden for en hardwarefejl alvorligt.

Han kørte en række af tests på brugerens Skylake-system og forsøgte blandt andet at køre en række udgaver af programmet parallelt for at se, om der var en sammenhæng mellem belastning eller hukommelsesforbrug. Det ville kunne afsløre, om der eksempelvis blot var tale om en fejl udløst af for høj temperatur på systemet.

Men i stedet for, at fejlene blev mest hyppige ved maksimal belastning, så viste der sig at være et spring mellem 2 og 4 processer. Den pågældende maskine havde en processor med 4 fysiske kerner, og to af dem var i forvejen i brug til andre processer. Den pågældende applikation var enkelttrådet, og styresystemet ville normalt fordele processerne på de fysiske kerner.

Forskellen mellem 2 og 4 processer var, at her slog HyperThreading til. Det er en funktion, som deler den fysiske kerne op i to. Der kunne altså være en sammenhæng mellem de uforudsigelige crashes og HyperThreading.

Nye problemer

Xavier Leroy nåede frem til en simpel løsning: Slå HyperThreading fra. Det forklarede ikke den underliggende fejl, men løste problemet for den pågældende bruger. Det skete i 2016.

Hos Ahref fik en kunde senere i 2016 et tilsvarende problem. OCaml-kode blev compileret med tilfældige fejl, skriver Joris Giovannangeli fra Ahrefs i et blogindlæg.

Det blev særlig problematisk, da koden, som kørte på en klynge af Intel Skylake-processorer, begyndte at generere fejl, som endte med at beskadige data på storagesystemet.

Også her var mistanken først en fejl i softwarestakken, hvor først virtualiseringslaget og derefter OCaml blev undersøgt. Alle fejlene havde at gøre med adresser i hukommelsen, som ikke burde kaldes.

Men mens Xavier Leroy fra OCaml havde affundet sig med, at problemet nok skyldtes den ene Skylake-maskine hos brugeren, der havde henvendt sig, så oplevede Ahref problemerne på alle deres Skylake-baserede maskiner. Det mindskede sandsynligheden for, at det blot havde været en fejl i produktionen af nogle enkelte chips.

Ahref henvendte sig til Intels kundesupport, og i april 2017 frigav Intel en opdateret version af errata til Skylake og Kaby Lake. Linux-distributionen Debian frigav kort efter en opdatering af Debians microcode til Skylake, hvori det blev beskrevet, at der kunne opstå en sjælden fejl.

Fejlen opstår, når GCC-compileren blander to registre, som hver fylder henholdsvis 1 og 4 bytes. GCC kan blande de to for at optimere koden, og hvis det sker i en tilstrækkeligt lille løkke, så kan det udløse hardwarefejlen på Skylake-processorerne.

Men for at nå til den konklusion skulle flere udviklere altså udelukke den mest sandsynlige forklaring: At de selv havde lavet en fejl i deres kode.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Kommentarer (3)
Log ind eller Opret konto for at kommentere
Pressemeddelelser

Welcome to the Cloud Integration Enablement Day (Bring your own laptop)

On this track, we will give you the chance to become a "Cloud First" data integration specialist.
15. nov 10:31

Silicom i Søborg har fået stærk vind i sejlene…

Silicom Denmark arbejder med cutting-edge teknologier og er helt fremme hvad angår FPGA teknologien, som har eksisteret i over 20 år.
22. sep 2017

Conference: How AI and Machine Learning can accelerate your business growth

Can Artificial Intelligence (AI) and Machine Learning bring actual value to your business? Will it supercharge growth? How do other businesses leverage AI and Machine Learning?
13. sep 2017