AMD varmisti FMA3-bugin Ryzen-prosessoreissa, korjaus luvassa mikrokoodipäivityksellä

[Kaotik]

AMD:n Zen-arkkitehtuuriin perustuvien Ryzen-prosessoreiden julkaisun jälkimainingeissa löydettiin pari viikkoa sitten prosessoreista ensimmäinen merkittävä bugi. Bugin löysi HWBotin keskustelupalstojen käyttäjä Alexander ”Mysticial” Yee.

AMD:n Ryzen-prosessoreista löytynyt bugi koskee niiden tukea FMA3-käskykantalaajennokselle (FMA, Fused Multiply Add). Bugi löytyi Yeen itse kehittämällä avoimen lähdekoodin Flops-testiohjelmalla tai tarkemmin sen Intelin Haswell-prosessoreille käännetyllä Windows-versiolla, mutta se ei rajoitu vain Flops-testiohjelmaan.

Kuka tahansa käyttäjä voi todentaa ongelman Ryzen-kokoonpanolla lataamalla ohjelman lähdekoodin GitHubista ja kääntämällä sen Visual Studiolla x64 Haswell -binääriksi. Järjestelmä kaatuu tyypillisesti Flops-testin Single-Precision - 128-bit FMA3 - Fused Multiply Add -osiossa, vaikka joissain tapauksissa kaatuminen tapahtuu vasta vähän myöhemmin testin aikana. Ryzen-prosessoreiden FMA3-bugi kaataa koko kokoonpanon huolimatta siitä, että ohjelma ajetaan User Mode -tilassa, missä ohjelmien ei pitäisi kaataa virheen sattuessa koko järjestelmää. Bugin olemassaolo ja järjestelmän kaataminen User Mode -tilassa voi luoda tietoturvaongelman etenkin virtuaalikäyttöjärjestelmissä.

AMD on kertonut Digital Trends -sivustolle todentaneensa FMA3-bugin olemassaolon sisäisissä testeissään ja löytänyt syyn miksi se kaataa koko järjestelmän. Vaikka bugi on itse prosessorissa, se voidaan kaikkien onneksi korjata BIOS-päivityksen yhteydessä jaettavalla mikrokoodipäivityksellä. AMD ei ole vielä varmistanut BIOS-päivitysten tarkkaa aikataulua, vaan yhtiö kehottaa käyttäjiä vain seuraamaan emolevyvalmistajien tukisivustoja päivityksen varalta.

Huom! Foorumiviestistä saattaa puuttua kuvagalleria tai upotettu video.

Linkki alkuperäiseen uutiseen (io-tech.fi)

 

[Razarnet]

No onneksi patchaamalla fixattavissa ja varmaan kohta uunista tulee seuraavaa revikkaa zenistä.

 

[Tyamias]

Intel tehnyt tätä kuuluisasta Excel-bugista FPU:n kanssa jo vuosikymmenet. Ei mitään hätää AMD-leirissä. Osta AMD, voi hyvin. #MAGA.

 

[hsalonen]

Intel otti 90-luvulla prosessoreja takaisin, kun niissä oli liukulukuvirhe. Yritin kovasti ostaa sellaista halvalla, kun pelaamiseen ei tarvittu FPU:ta vuonna miekka ja kypärä.

AMD disabloi TLB:n alkuperäisistä Phenomeista, kun siinä oli virhe. Tämä aiheutti 10-20% rangaistuksen prosessorin tehokkuudelle.

Kuinkas paljon tästä joutuu kärsimään? Disabloivatko koko FMA:n? Lisävätkö ongelmakohtaan jotain ylimääräisiä tarkistuksia, jotka sitten vähemmän yllättäen laskevat sen nopeutta? Käytetäänkö edes FMA:ta missään?

 

[tle88]

Nyt pitää tästä aiheesta maallikon kysyä, että kauanko tuollaisen löytyneen bugin korjaus kestää? Milloin alkaa noin suurin piirtein kaupasta saamaan bugittomia uusia versioita, vai täytyykö odottaa ihan sitä Zen2 versiota, johon sitten tietenkin siihenkin solahtaa mukaan jokin uusi bugi?
Prosessoreja on tietty tehty varastoon aivan jumalaton määrä, ja nyt niiden myynti alkaa ikävästi hidastumaan, kun kaikki tietenkin haluavat sellaisen korjatun uudemman version. Hitaana olen tässä tätä ostamisasiaa lehmänä märehtinyt, että ottia tuota josko vaiskaan... hitaus on näissä hommissa mitä ilmeisimminkin hyve. Ainakin omalta kannalta asiaa katsoen. Ja kohta on tulossa skylake X:t ja sen jälkeen taas ihan pian jotain muuta. Sairaalloinen pihiys aiheuttaa ostohalvauksen.

 

[hsalonen]

Nyt pitää tästä aiheesta maallikon kysyä, että kauanko tuollaisen löytyneen bugin korjaus kestää? Milloin alkaa noin suurin piirtein kaupasta saamaan bugittomia uusia versioita, vai täytyykö odottaa ihan sitä Zen2 versiota, johon sitten tietenkin siihenkin solahtaa mukaan jokin uusi bugi?
Prosessoreja on tietty tehty varastoon aivan jumalaton määrä, ja nyt niiden myynti alkaa ikävästi hidastumaan, kun kaikki tietenkin haluavat sellaisen korjatun uudemman version. Hitaana olen tässä tätä ostamisasiaa lehmänä märehtinyt, että ottia tuota josko vaiskaan... hitaus on näissä hommissa mitä ilmeisimminkin hyve. Ainakin omalta kannalta asiaa katsoen. Ja kohta on tulossa skylake X:t ja sen jälkeen taas ihan pian jotain muuta. Sairaalloinen pihiys aiheuttaa ostohalvauksen.

Kaupasta ei saa bugittomia versioita ikinä. Mikro-ohjelmoinnilla muutetaan koneen käynnistyksen yhteydessä prosessorin koodia. Tämä muutos tulee todennäköisesti BIOS-päivityksessä, mutta voi se tulla myös Windows-päivityksenä.
Prosessorin uudelleenohjelmointi käynnistyksessä on ihan yleisesti käytetty taktiikka pienten virheiden korjaukseen. Intelillä on Errata jokaisen prosessorin speksien lopussa ja AMD:llä taitaa olla samoin jossain virhelista, joita tulee näin isoissa prosessoreissa ihan pakostakin.
Koska virhe jää fyysisesti prosessoriin, sen kiertäminen käyttämällä mikro-ohjelmointia voi aiheuttaa nopeusongelmia. Tuskin saavat tarkistuksia samaan kellojaksoon ikinä. Ja pahimmassa tapauksessa poistavat (osan) FMAsta käytöstä. Tuossa ei nyt tarkasti sanottu, mitä AMD aikoo tehdä - vain miten se sen tekee.

 

[Spartacus]

Miten tuo mikrokoodipäivitys käytännössä toimii? Jos se tulee BIOS-päivityksen yhteydessä niin sitten se on ihan järkeenkäypää ja tarvittavat asetukset voidaan aina ladata käynnistyksen yhteydessä. Mutta miten se voi tulla Windows-päivitysten mukana? Vai onko prosessorissa jotain uudelleenkirjoitettavaa muistia juuri tuota varten?
Miten vanhoihin prosessoreihin kyseisiä päivityksiä on tullut? Oliko esim Core2 aikaan käytössä?

 

[hkultala]

Kaupasta ei saa bugittomia versioita ikinä.

Ei välttämättä, ei ole julkistettu missä tuo bugi tarkkaanottaen on.

Se ei välttämättä ole FMA3-käskyn suoritusyksiköissä tms. vaan se voi olla myös prosessorin virransäästölogiikassa tms. joka on ihan softakoodia, jolloin sen korjaaminen on ihan "oikea korjaus" eikä "kierto".

Ja prosessorin johonkin tulevaan versioon laitetaan jo "sisään" uusi mikrokoodi, jolloin sitä ei tarvisi BIOSilta ladata.

Sitä tilaa jälkikäteen päivitettävälle mikrokoodille on joka tapauksessa siellä prosessoilla rajallisesti, joten joka tapauksessa halutaan minimoida sen käyttö.

Mikro-ohjelmoinnilla muutetaan koneen käynnistyksen yhteydessä prosessorin koodia. Tämä muutos tulee todennäköisesti BIOS-päivityksessä, mutta voi se tulla myös Windows-päivityksenä.
Prosessorin uudelleenohjelmointi käynnistyksessä on ihan yleisesti käytetty taktiikka pienten virheiden korjaukseen. Intelillä on Errata jokaisen prosessorin speksien lopussa ja AMD:llä taitaa olla samoin jossain virhelista, joita tulee näin isoissa prosessoreissa ihan pakostakin.
Koska virhe jää fyysisesti prosessoriin, sen kiertäminen käyttämällä mikro-ohjelmointia voi aiheuttaa nopeusongelmia. Tuskin saavat tarkistuksia samaan kellojaksoon ikinä. Ja pahimmassa tapauksessa poistavat (osan) FMAsta käytöstä. Tuossa ei nyt tarkasti sanottu, mitä AMD aikoo tehdä - vain miten se sen tekee.

Prosessori voi suorittaa käskyjä kahdella eri tavalla:
1) Käsky dekoodataan suoraan yhdeksi tai muutamaksi prosessorin mikro-operaatioksi, jotka suoritetaan peräkkäin liukuhihnamaisesti prosessorin liukuhihnalla.

2) Käsky suoritetaan mikrokoodilla, mikä tarkoittaa sitä, että prosessori käytännössä vaihtaa toimintamoodia ja alkaa suorittamaan mikrokoodi-ROMissa olevaa ohjelmaa, jossa voi olla esim. monimutkaista kontrollia kuten hyppyjä, ja sitten kun tämä mikrokoodiohjelma valmistuu, palataan takaisin suorittamaan "normaaleja käskyjä" siitä, mihin jäätiin. Käytännössä samaan aikaan ei siis voida kunnolla suorittaa muita käskyjä rinnakkain ja mikrokoodimoodiin siirtyminen hidastaa prosessoria huomattavasti.


Se, mitä voidaan uploadata prosessorille bootin yhteydessä on tyypillisesti
1) uusia paloja mikrokoodia
2) käskykohtaisesti pointteri mikrokoodirutiiniin tai tieto siitä että dekoodataan suoraan eikä suoriteta mikrokoodilla.


Esim. Bulldozerissa oli rikkinäinen kokonaislukujen jakolaskuyksikkö. Tämä huomattiin ennen piirin julkaisua, mutta aikaa sen korjaamiseen ei ollut ilman että piiriä olisi pitänyt myöhästyttää kuukausia, joten se otettiin vaan kokonaan pois päältä ja kokonaislukujen jakolaskut suoritettiin mikrokoodilla(joka saattoi ehkä jopa ehtiä siihen prosessorin mukana tulevaan ROMiin mukaan, en ole varma tästä). Jakolasku on joka tapauksessa hidas operaatio joita ei ole järkevästi optimoidussa koodissa innerloopissa, joten tämän vaikutus ei ollut kovin paha. Piledriveriin mennessä tämä jakolaskuyksikkö oli sitten korjattu, ja siinä se oli päällä.

FMA3-käsky sen sijaan (sille optimoidulla koodilla) on niin yleinen ja suorituskykykriitinen käsky, että sen suorittaminen mikrokoodilla olisi todella paha juttu ja hidastaisi paljon, käytännössä silloin kannattaisi vaan disabloida koko FMA3-tuki ja laittaa CPUID sanomaan, että tätä käskyä ei ole tuettu, jolloin softa valitsisi koodipolun jossa käytettäisiin erillisiä FADD- ja FMUL-käskyjä FMA-käskyn sijaan(erityisesti kun Zenissä rakenne on sellainen, että FMAsta ei hyödytä muutenkaan kovin paljoa, toisin kuin haswellissa ja bulldozer-johdannaisissa, joissa sen käyttö tuplaa teoreettiset flopsit)

Se, että AMD on vaan sanonut tuovansa pienen mikrokoodikorjauksen ja puhunut bugin korjaamisesta eikä kiertämisestä eikä pahoitellut mitään eikä puhunut FMA3n poistamisesta käytöstä vihjaisi siihen, että se oikeasti saadaan korjattua ilman että mitään joka nyt ajetaan suoraan tarvisi alkaa ajamaan mikrokoodilla.

 

[hkultala]

Miten tuo mikrokoodipäivitys käytännössä toimii? Jos se tulee BIOS-päivityksen yhteydessä niin sitten se on ihan järkeenkäypää ja tarvittavat asetukset voidaan aina ladata käynnistyksen yhteydessä. Mutta miten se voi tulla Windows-päivitysten mukana? Vai onko prosessorissa jotain uudelleenkirjoitettavaa muistia juuri tuota varten?
Miten vanhoihin prosessoreihin kyseisiä päivityksiä on tullut? Oliko esim Core2 aikaan käytössä?

Aina kun prosessori käynnistyy, siellä on se "vanha buginen" mikrokoodi sisällä hardkoodatussa ROM-muistissa. Mutta siellä on myös pieni SRAM-muisti jonne voidaan ladata lisäpalasia sitä mikrokoodia, ja pointterit että mikä käsky suoritetaan missä osoitteessa olevasta mikrokoodista.

Koneen bootatessa sitten BIOS antaa käskyt että tähän pieneen SRAM-muistiin ladataan korjattu osa mikrokoodia, ja niitä pointtereita päivitetään siten että aiemmin bugisen mikrokoodin tai bugisen rautayksikön sisältänyt käsky suoritetaankin nyt tässä osoitteessa olevasta mikrokoodista eikä sillä ROMissa olevasta mikrokoodista tai suoraan raudalla olevalla yksiköllä. (tai saman voi mahdollisesti tehdä se käyttis käyttistä bootatessa)

Muut käskyt (joiden kohdalla vanhassa ROMilla olevassa mikrokoodilla ei ole bugia) suoritetaan kuitenkin edelleen sen "vanhan" ROMilla olevan mikrokoodin kautta, "korjaus" sisältää vain ne kohdat jotka tarvii korjata.

Viimeistään kun kone sammutetaan, se "korjattu mikrokoodi" ja siihen viittaavat pointterit katoavat sieltä prosessorilta.

 

[Spartacus]

Aika järjetöntä tuossa tapauksessa sisällyttää niitä Windows-päivityksiin, varsinkaan kun päivitys ei ole ns. pysyvä. Mielenkiintoista tietoa.

 

[hsalonen]

@hkultala kirjoittikin jo tyhjentävän esseen asiasta. Toistetaan vielä oma pointtini, kun sitä joutuu tästä keskustelusta rivien välistä hakemaan:

Tämä bugi ei ole este Ryzenin ostamiselle nyt.

Aika järjetöntä tuossa tapauksessa sisällyttää niitä Windows-päivityksiin, varsinkaan kun päivitys ei ole ns. pysyvä. Mielenkiintoista tietoa.

Se voi olla myös BIOS-päivitys. Tämän takia sekä Windows, että BIOS kannattaa pitää ajantasalla.

 

[Ryydike]

Aina kun prosessori käynnistyy, siellä on se "vanha buginen" mikrokoodi sisällä hardkoodatussa ROM-muistissa. Mutta siellä on myös pieni SRAM-muisti jonne voidaan ladata lisäpalasia sitä mikrokoodia, ja pointterit että mikä käsky suoritetaan missä osoitteessa olevasta mikrokoodista.

Koneen bootatessa sitten BIOS antaa käskyt että tähän pieneen SRAM-muistiin ladataan korjattu osa mikrokoodia, ja niitä pointtereita päivitetään siten että aiemmin bugisen mikrokoodin tai bugisen rautayksikön sisältänyt käsky suoritetaankin nyt tässä osoitteessa olevasta mikrokoodista eikä sillä ROMissa olevasta mikrokoodista tai suoraan raudalla olevalla yksiköllä. (tai saman voi mahdollisesti tehdä se käyttis käyttistä bootatessa)

Muut käskyt (joiden kohdalla vanhassa ROMilla olevassa mikrokoodilla ei ole bugia) suoritetaan kuitenkin edelleen sen "vanhan" ROMilla olevan mikrokoodin kautta, "korjaus" sisältää vain ne kohdat jotka tarvii korjata.

Viimeistään kun kone sammutetaan, se "korjattu mikrokoodi" ja siihen viittaavat pointterit katoavat sieltä prosessorilta.

Eikös (koneen keskusmuisti) DRAM:ia pysty käyttämään myös mikrokoodin säilytykseen ja ajamiseen?

 

[Billy Z. Jubu-Uhuru]

Aika järjetöntä tuossa tapauksessa sisällyttää niitä Windows-päivityksiin, varsinkaan kun päivitys ei ole ns. pysyvä. Mielenkiintoista tietoa.

Päinvastoin, jos korjattua mikrokoodia ei voisi jakaa Windows-päivityksinä niin tilanne olisi helposti melko katastrofaalinen. Koneita joihin ei biosia tulla koskaan päivittämään joko valmistajan tai käyttäjän toimesta on valtava määrä ja niissäkin bugi prosessorissa voi aiheuttaa melkoisia ongelmia.

 

[tyson]

Eikös (koneen keskusmuisti) DRAM:ia pysty käyttämään myös mikrokoodin säilytykseen ja ajamiseen?

Keskusmuistia? Tuskin, sillä sehän tyhjennetään tietokoneen sammuttamisen yhteydessä.

 

[Spartacus]

Päinvastoin, jos korjattua mikrokoodia ei voisi jakaa Windows-päivityksinä niin tilanne olisi helposti melko katastrofaalinen. Koneita joihin ei biosia tulla koskaan päivittämään joko valmistajan tai käyttäjän toimesta on valtava määrä ja niissäkin bugi prosessorissa voi aiheuttaa melkoisia ongelmia.

Ei tullut tuo näkökulma mieleenkään. Itse kun tulee aina pistettyä heti uudet päivitykset mutta eihän keskivertokäyttäjä edes tiedä mikä on BIOS.

 

[Ryydike]

Keskusmuistia? Tuskin, sillä sehän tyhjennetään tietokoneen sammuttamisen yhteydessä.

Ei se tyhjene jos käytetään virransäästötilaa. Ja prossuhan aina käynnistyessään lataa emon firmiksen omaan muistiinsa tai sitten DRAM:iin.

 

[Tomak89]

Tuli kokeiltua tätä Linuxilla. Mitään virheilmoitusta ei tule järjestelmälle noista, mutta aivan jumalaton lagi FMA3-testien aikana. Jos testi kestäisi yhtään kauemmin, niin varmaan kyykkäis koko järjestelmä.

Spoileri: testout.txt

Running Benchmarks for Intel Haswell...

Single-Precision - 128-bit SSE - Add/Sub:
Dependency Chains = 8
Result = 691.2
FP Ops = 2048000000000
seconds = 5.52568
GFlops = 370.633

Single-Precision - 128-bit SSE - Multiply:
Dependency Chains = 12
Result = 1190.4
FP Ops = 3072000000000
seconds = 5.64635
GFlops = 544.068

Single-Precision - 128-bit SSE - Multiply + Add:
Dependency Chains = 12
Result = 1190.4
FP Ops = 3072000000000
seconds = 4.51819
GFlops = 679.918

Single-Precision - 128-bit FMA3 - Fused Multiply Add:
Dependency Chains = 12
Result = 1190.4
FP Ops = 6144000000000
seconds = 13.7804
GFlops = 445.852

Double-Precision - 128-bit SSE2 - Add/Sub:
Dependency Chains = 8
Result = 345.6
FP Ops = 1024000000000
seconds = 6.60239
GFlops = 155.095

Double-Precision - 128-bit SSE2 - Multiply:
Dependency Chains = 12
Result = 595.2
FP Ops = 1536000000000
seconds = 13.1675
GFlops = 116.651

Double-Precision - 128-bit SSE2 - Multiply + Add:
Dependency Chains = 12
Result = 595.2
FP Ops = 1536000000000
seconds = 6.69556
GFlops = 229.406

Double-Precision - 128-bit FMA3 - Fused Multiply Add:
Dependency Chains = 12
Result = 595.2
FP Ops = 3072000000000
seconds = 13.4436
GFlops = 228.51

Single-Precision - 256-bit AVX - Add/Sub:
Dependency Chains = 8
Result = 1382.4
FP Ops = 4096000000000
seconds = 10.8939
GFlops = 375.992

Single-Precision - 256-bit AVX - Multiply:
Dependency Chains = 12
Result = 2380.8
FP Ops = 6144000000000
seconds = 10.8617
GFlops = 565.66

Single-Precision - 256-bit AVX - Multiply + Add:
Dependency Chains = 12
Result = 2380.8
FP Ops = 6144000000000
seconds = 8.69785
GFlops = 706.381

Single-Precision - 256-bit FMA3 - Fused Multiply Add:
Dependency Chains = 12
Result = 2380.8
FP Ops = 12288000000000
seconds = 26.4529
GFlops = 464.524

Double-Precision - 256-bit AVX - Add/Sub:
Dependency Chains = 8
Result = 691.2
FP Ops = 2048000000000
seconds = 13.035
GFlops = 157.115

Double-Precision - 256-bit AVX - Multiply:
Dependency Chains = 12
Result = 1190.4
FP Ops = 3072000000000
seconds = 26.1092
GFlops = 117.66

Double-Precision - 256-bit AVX - Multiply + Add:
Dependency Chains = 12
Result = 1190.4
FP Ops = 3072000000000
seconds = 13.1163
GFlops = 234.212

Double-Precision - 256-bit FMA3 - Fused Multiply Add:
Dependency Chains = 12
Result = 1190.4
FP Ops = 6144000000000
seconds = 26.5462
GFlops = 231.445

 

[Hannibal]

Miten tuo mikrokoodipäivitys käytännössä toimii? Jos se tulee BIOS-päivityksen yhteydessä niin sitten se on ihan järkeenkäypää ja tarvittavat asetukset voidaan aina ladata käynnistyksen yhteydessä. Mutta miten se voi tulla Windows-päivitysten mukana? Vai onko prosessorissa jotain uudelleenkirjoitettavaa muistia juuri tuota varten?
Miten vanhoihin prosessoreihin kyseisiä päivityksiä on tullut? Oliko esim Core2 aikaan käytössä?

Aina kun prosessori käynnistyy, siellä on se "vanha buginen" mikrokoodi sisällä hardkoodatussa ROM-muistissa. Mutta siellä on myös pieni SRAM-muisti jonne voidaan ladata lisäpalasia sitä mikrokoodia, ja pointterit että mikä käsky suoritetaan missä osoitteessa olevasta mikrokoodista.

Koneen bootatessa sitten BIOS antaa käskyt että tähän pieneen SRAM-muistiin ladataan korjattu osa mikrokoodia, ja niitä pointtereita päivitetään siten että aiemmin bugisen mikrokoodin tai bugisen rautayksikön sisältänyt käsky suoritetaankin nyt tässä osoitteessa olevasta mikrokoodista eikä sillä ROMissa olevasta mikrokoodista tai suoraan raudalla olevalla yksiköllä. (tai saman voi mahdollisesti tehdä se käyttis käyttistä bootatessa)

Muut käskyt (joiden kohdalla vanhassa ROMilla olevassa mikrokoodilla ei ole bugia) suoritetaan kuitenkin edelleen sen "vanhan" ROMilla olevan mikrokoodin kautta, "korjaus" sisältää vain ne kohdat jotka tarvii korjata.

Viimeistään kun kone sammutetaan, se "korjattu mikrokoodi" ja siihen viittaavat pointterit katoavat sieltä prosessorilta.

Thanks! Pajatson tyhjentävä vastaus.

 

[jive]

Äkkiä voisi kuvitella että tämä bugi vaikuttaisi skedulerikäyttäytymiseen jos se efektiivisesti ajaa yhden tai useamman säikeen ikikieriöön lukiten näin osan ytimen suoritusyksiköistä kiinteästi pois vapaasta jaosta. Jos lasi olisi puolitäynnä niin päivitys saattaisi jopa parantaa suorituskykykyä monisäikeisessä sovelluksessa.

 

[jive]

Miten tuo mikrokoodipäivitys käytännössä toimii? Jos se tulee BIOS-päivityksen yhteydessä niin sitten se on ihan järkeenkäypää ja tarvittavat asetukset voidaan aina ladata käynnistyksen yhteydessä. Mutta miten se voi tulla Windows-päivitysten mukana? Vai onko prosessorissa jotain uudelleenkirjoitettavaa muistia juuri tuota varten?
Miten vanhoihin prosessoreihin kyseisiä päivityksiä on tullut? Oliko esim Core2 aikaan käytössä?

Aina kun prosessori käynnistyy, siellä on se "vanha buginen" mikrokoodi sisällä hardkoodatussa ROM-muistissa. Mutta siellä on myös pieni SRAM-muisti jonne voidaan ladata lisäpalasia sitä mikrokoodia, ja pointterit että mikä käsky suoritetaan missä osoitteessa olevasta mikrokoodista.

Koneen bootatessa sitten BIOS antaa käskyt että tähän pieneen SRAM-muistiin ladataan korjattu osa mikrokoodia, ja niitä pointtereita päivitetään siten että aiemmin bugisen mikrokoodin tai bugisen rautayksikön sisältänyt käsky suoritetaankin nyt tässä osoitteessa olevasta mikrokoodista eikä sillä ROMissa olevasta mikrokoodista tai suoraan raudalla olevalla yksiköllä. (tai saman voi mahdollisesti tehdä se käyttis käyttistä bootatessa)

Muut käskyt (joiden kohdalla vanhassa ROMilla olevassa mikrokoodilla ei ole bugia) suoritetaan kuitenkin edelleen sen "vanhan" ROMilla olevan mikrokoodin kautta, "korjaus" sisältää vain ne kohdat jotka tarvii korjata.

Viimeistään kun kone sammutetaan, se "korjattu mikrokoodi" ja siihen viittaavat pointterit katoavat sieltä prosessorilta.

mikrokoodipatch olisi oma ykköstarget, jos pitäisi tehdä haavoittuvuus jonnekin, sanotaanko vaikka TRNG yksiköihin...

 

[jive]

Aika järjetöntä tuossa tapauksessa sisällyttää niitä Windows-päivityksiin, varsinkaan kun päivitys ei ole ns. pysyvä. Mielenkiintoista tietoa.

Päinvastoin, jos korjattua mikrokoodia ei voisi jakaa Windows-päivityksinä niin tilanne olisi helposti melko katastrofaalinen. Koneita joihin ei biosia tulla koskaan päivittämään joko valmistajan tai käyttäjän toimesta on valtava määrä ja niissäkin bugi prosessorissa voi aiheuttaa melkoisia ongelmia.

ja kun joku miettii, mitä se ettei vanhemmat prosessorit ole enää tuettuna uudemmilla käyttöjärjestelmillä tarkoittaa, niin esimerkiksi tätä.

 

[Nerkoon]

Gigabyten väitetään jo saaneen kasaan pari korjattua biosia joilla FMA3 kaatumista ei enää esiinny:


Tuosta voisi päätellä, että fiksin sisältävä AGESA on jo emovalmistajilla ja kohta muiltakin niistä alkaa tulla korjauksen sisältäviä versioita ulos.

 

[jsa]

Eiköhän noita mikrokoodi exploitteja ole jo...

 

[prc]

Eikös (koneen keskusmuisti) DRAM:ia pysty käyttämään myös mikrokoodin säilytykseen ja ajamiseen?

No mielummin ei.

Jos ajatellaan että se mikrokoodille varattu SRAM on prosessorin kannalta "lähellä" niin välimuisti on jo kaukana, keskusmuisti on tällöin mallia kuussa. Olisi varsin hidasta suorittaa mitään prosessorin ohjauskoodia rammista, jos ja kun se vahingossa pääsisi lipsahtamaan välimuistista pois.

 

[SloBo]

Nyt pitää tästä aiheesta maallikon kysyä, että kauanko tuollaisen löytyneen bugin korjaus kestää? Milloin alkaa noin suurin piirtein kaupasta saamaan bugittomia uusia versioita, vai täytyykö odottaa ihan sitä Zen2 versiota, johon sitten tietenkin siihenkin solahtaa mukaan jokin uusi bugi?
Prosessoreja on tietty tehty varastoon aivan jumalaton määrä, ja nyt niiden myynti alkaa ikävästi hidastumaan, kun kaikki tietenkin haluavat sellaisen korjatun uudemman version. Hitaana olen tässä tätä ostamisasiaa lehmänä märehtinyt, että ottia tuota josko vaiskaan... hitaus on näissä hommissa mitä ilmeisimminkin hyve. Ainakin omalta kannalta asiaa katsoen. Ja kohta on tulossa skylake X:t ja sen jälkeen taas ihan pian jotain muuta. Sairaalloinen pihiys aiheuttaa ostohalvauksen.

Kaupasta ei saa bugittomia versioita ikinä. Mikro-ohjelmoinnilla muutetaan koneen käynnistyksen yhteydessä prosessorin koodia. Tämä muutos tulee todennäköisesti BIOS-päivityksessä, mutta voi se tulla myös Windows-päivityksenä.
Prosessorin uudelleenohjelmointi käynnistyksessä on ihan yleisesti käytetty taktiikka pienten virheiden korjaukseen. Intelillä on Errata jokaisen prosessorin speksien lopussa ja AMD:llä taitaa olla samoin jossain virhelista, joita tulee näin isoissa prosessoreissa ihan pakostakin.
Koska virhe jää fyysisesti prosessoriin, sen kiertäminen käyttämällä mikro-ohjelmointia voi aiheuttaa nopeusongelmia. Tuskin saavat tarkistuksia samaan kellojaksoon ikinä. Ja pahimmassa tapauksessa poistavat (osan) FMAsta käytöstä. Tuossa ei nyt tarkasti sanottu, mitä AMD aikoo tehdä - vain miten se sen tekee.

Niin siis kysymys oli, että milloin AMD mahdollisesti saa korjatun version raudasta pihalle, ja sehän riippuu AMD:sta itsestään. Voisin kuvitella, että tämä on kakkosversiossa viimeistään korjattu, mutta mistäs sen tietää.

 

[Tomak89]

Niin siis kysymys oli, että milloin AMD mahdollisesti saa korjatun version raudasta pihalle, ja sehän riippuu AMD:sta itsestään. Voisin kuvitella, että tämä on kakkosversiossa viimeistään korjattu, mutta mistäs sen tietää.

Following community confirmations of the bug, HWBOT's chief operating officer Pieter-Jan Plaisier posted that he had received confirmation that the crash was the result of a flaw in AMD's Ryzen microcode - meaning it affects all currently-available Ryzen chips, and likely also the company's upcoming Naples server parts which share the same Zen microarchitecture. Thankfully, a fix is on the way: 'Was told this issue will be fixed in a new AGESA [AMD Generic Encapsulated Software Architecture microcode] code,' Plaisier claimed. 'In other words: it was an AMD [CPU] issue, not C6H [chipset] issue.'

The bug, according to the HWBot thread, is tied to AGESA — the AMD Generic Encapsulated Software Architecture, which handles the bootstrap protocol and initializes system devices.

Eli virhe nimenomaan mikrokoodissa eikä raudassa. Zen2:ssa tuo on varmasti sitten ladattu prosessorille alunperin, jolloin sitä ei tarvitse erikseen järjestelmän käynnistyksen yhteydessä päivittää. Kyseisen "ongelman" ainoa vaara onkin kenties jonkinlainen tietoturva uhka. Ilman juuri kyseisen spesifin testin tekemistä ongelma tuskin olisi tullut selville. Toki hyvä että löytyi.