AMD:n prosessoreista löytyi uusi sivukanavahaavoittuvuus

[Kaotik]

Kaotik kirjoitti uutisen/artikkelin:
Intelin prosessorit ovat saaneet viime vuosina ryöpytystä tietoturvaongelmistaan, mutta tällä kertaa on AMD:n vuoro. Grazin teknillisen yliopiston tutkijat ovat onnistuneet takaisinmallintamaan AMD:n L1D-välimuistin ennustajayksikön ja hyödyntämään sen kautta saatua tietoja muiden haavoittuvuuksien kanssa.

”Take A Way”:ksi ristitty hyökkäys sisältää todellisuudessa kaksi erillistä hyökkäystä, Collide+Proben ja Load+Reloadin. Haavoittuvuus koskee kaikkia AMD:n Bulldozer- ja Zen-johdannaisia arkkitehtuureita. Haavoittuvuudet on testattu toimiviksi myös laboratorion ulkopuolelle Epyc-pilvipalvelimissa hyödyntämällä JavaScriptiä Chrome- ja Firefox-selaimilla.

Tutkijoiden mukaan takaisinmallintamalla L1D-välimuistin ennustajan (L1D cache way predictor). Saatujen tietojen perusteella toteutettu Collide+Probe-hyökkäys mahdollistaa muistihakujen tarkkailun ilman, että hyökkääjän tarvitsisi tietää tarkkailtavaa muistiosoitetta, kun kaksi prosessia käyttää samaa ydintä. Load+Reload puolestaan mahdollistaa ennustajan hyödyntämisen paljastamaan, onko samaa ydintä käyttävä prosessi käyttänyt tiettyjä muistiosoitteita.

Kehittäjien mukaan Take A Way vuotaa kutienkin vain pieniä määriä metadataa, eikä siten ole verrattavissa esimerkiksi Spectre- ja Meltdown-hyökkäyksiin. AMD puolestaan on kommentoinut Tom’s Hardwarelle, että se ei varsinaisesti laskisi näitä uusiksi hyökkäyksiksi, mutta ei kiellä haavoittuvuuden olemassaoloa. Yhtiö ei ole kertonut vielä, miten se tulee korjaamaan asian, mutta tutkijoiden mukaan erilaisia korjaustapoja olisi sekä rauta- että ohjelmistopohjaisesti olemassa useita.

Netissä nousi myös pienoinen kohu, kun tutkijoiden huomattiin saavan osan rahoituksestaan Inteliltä. Samat tutkijat ovat kuitenkin julkaisseet myös useita Inteliä koskevia haavoittuvuuksia, eikä mikään tapauksessa anna syytä epäillä rahoituksen vaikuttaneen tutkimukseen tai että Intel olisi kehottanut tutkimaan asiaa.

Lähde: Tom's Hardware

Linkki alkuperäiseen juttuun

 

[mango]

Tässä vielä AMD:n vastaus:

We are aware of a new white paper that claims potential security exploits in AMD CPUs, whereby a malicious actor could manipulate a cache-related feature to potentially transmit user data in an unintended way. The researchers then pair this data path with known and mitigated software or speculative execution side channel vulnerabilities. AMD believes these are not new speculation-based attacks.

Lähde: https://www.amd.com/en/corporate/product-security

 

[VmH]

Tuli tuosta i7 3770k -suorittimesta vaihdettua pois juurikin tuon Intelin Spectre -haavoittuvuuden tuoman (windows 10 päivityksen) suorituskyvyn heikkenemisen takia. Päädyin lopulta AMD:n r9 3900x:n jo senkin takia, että niissä ei ole aiemmin paljastunut (tietääkseni) tätä ennen mitään isompia tietoturva bugeja. Liekö syynä ollut sitten käyttäjien vähyys ? Onneksi tämä AMD:n haavoittuvuus ei ole läheskään yhtä iso ongelma kuin Spectre aikoinaan.

 

[Lepakomäyrä]

Tuli tuosta i7 3770k -suorittimesta vaihdettua pois juurikin tuon Intelin Spectre -haavoittuvuuden tuoman (windows 10 päivityksen) suorituskyvyn heikkenemisen takia. Päädyin lopulta AMD:n r9 3900x:n jo senkin takia, että niissä ei ole aiemmin paljastunut (tietääkseni) tätä ennen mitään isompia tietoturva bugeja. Liekö syynä ollut sitten käyttäjien vähyys ? Onneksi tämä AMD:n haavoittuvuus ei ole läheskään yhtä iso ongelma kuin Spectre aikoinaan.

Missäs tälläisen suorituskyvyn heikkenemisen sitten huomasit?

Tuon prossun suorituskyky kun ei 4/8 vuoksikaan ole aina välttämättä riittävä joten ytimien ja yleisen suorituskyvyn puute softissa/peleissä selittyy muulla kuin Spectrellä ja on siis täysin normaalia kyseiselle prossulle.

Eikä nämä haavoittuvuudet jää vielä tähän Amd prossujen osalta, lisää tulee löytymään.

 

[VmH]

Missäs tälläisen suorituskyvyn heikkenemisen sitten huomasit?

Tuon prossun suorituskyky kun ei 4/8 vuoksikaan ole aina välttämättä riittävä joten ytimien ja yleisen suorituskyvyn puute softissa/peleissä selittyy muulla kuin Spectrellä ja on siis täysin normaalia kyseiselle prossulle.

Eikä nämä haavoittuvuudet jää vielä tähän Amd prossujen osalta, lisää tulee löytymään.

Alt+tab sovelluksen pyöriessä taustalla aiheutti huomattavasti isomman tehohävikin, kuin aiemmin. Jos vähänkin oli chromea tai discordia käytössä samaan aikaan, niin discordin toiminta heikkeni selvästi. Intel myös myönsi että vanhemman arkkitehtuurin prosessoreihin tehohävikki tuli vaikuttamaan eniten. Näistä löytyi myös paljon testejä spectre päivityksen ennen/jälkeen.

Nykyään voi huoletta unohtaa vaikka chromen 16 linkillä auki taustalle pyörimään eikä vaikuta esim. Discordin tai pelien toimintaan millään lailla.

Ja kyllä 4/8 prossun pitäisi toimia ihan hyvin win 10:llä. Omassa läppärissä muistaakseni joku i5-7xxxh prossu, jolla ei ollut läheskään samanlaisia hidastuksia/ongelmia discordin käytössä vaikka chrome oli taustalla auki sovellusta käyettäessä. Päättelin tästä että Spectre päivityksen myötä oli siis aika päivittää kone.

 

[Masturbo]

^ Vastaavia subjektiivisia tehohäviöitä on tullut myös havaittua, mutta on vaikea sanoa mistä ne johtuvat. Normi Skylake-läppärit vaikuttavat merkittävästi tahmeammilta, samaan aikaan kun esimerkiksi vanha Sandyläppäri pyörittää uusintakin Windows-versiota edelleen yhtä välittömästi, kuin aina ennenkin. Tiedä sitten miksi ne ovat nähtävissä normaalissa käytössä, tuoko esim. F-securen ohjelmisto ne paremmin esille tai jotain. Sen sijaan raskaiden suoritusten suhteen, suoristuskyvyssä ei voi sanoa olevan mitään eroa entiseen, sama FPS-tulee pihalle edelleen.

 

[hsalonen]

Edelleen, haavoittuvuuksia on kaikilla ja ne paikataan. Sitten ei enää vuoda. Aiheeton paniikki tästä on turhaa.

Se, mitä pitää tarkkailla on, kuinka paljon nämä paikat vaikuttavat prosessorin nopeuteen. Ihan hatusta heitettynä mutuvakiolla Intelin koostetut tietoturvapaikat ovat hidastaneet prosessoreita yhteensä 10-15%. Se on hirveän paljon. Phoronixilla oli tästä testi pari haavoittuvuutta sitten.

Nytkin kiinnostaa vaan se, että otetaanko L1 cache prediction pois päältä, tehdäänkö jotain pieniä mitigointeja vai annetaanko asian olla? Ts. paljon prosessorini kärsii tästä paikasta?

 

[Jamboa]

Alt+tab sovelluksen pyöriessä taustalla aiheutti huomattavasti isomman tehohävikin, kuin aiemmin. Jos vähänkin oli chromea tai discordia käytössä samaan aikaan, niin discordin toiminta heikkeni selvästi. Intel myös myönsi että vanhemman arkkitehtuurin prosessoreihin tehohävikki tuli vaikuttamaan eniten. Näistä löytyi myös paljon testejä spectre päivityksen ennen/jälkeen.

Nykyään voi huoletta unohtaa vaikka chromen 16 linkillä auki taustalle pyörimään eikä vaikuta esim. Discordin tai pelien toimintaan millään lailla.

Ja kyllä 4/8 prossun pitäisi toimia ihan hyvin win 10:llä. Omassa läppärissä muistaakseni joku i5-7xxxh prossu, jolla ei ollut läheskään samanlaisia hidastuksia/ongelmia discordin käytössä vaikka chrome oli taustalla auki sovellusta käyettäessä. Päättelin tästä että Spectre päivityksen myötä oli siis aika päivittää kone.

Ettei vaan olisi alkanut olemaan Windows solmussa? Nimittäin itselläni ei ollut edes 2600k:lla mitään tuollaisia ongelmia. Kyllä Ryzen toi sitli kivasti lisää tehoja pelailuun ja ennen kaikkea jäi vielä reserviin. Pääsasia tietysti että olet päivitykseen tyytyväinen -eteenpäinhän tuo kehitys on mennyt kuitenkin (vähintään tietoturvan näkökulmasta)

 

[hkultala]

Edelleen, haavoittuvuuksia on kaikilla ja ne paikataan. Sitten ei enää vuoda. Aiheeton paniikki tästä on turhaa.

Se, mitä pitää tarkkailla on, kuinka paljon nämä paikat vaikuttavat prosessorin nopeuteen. Ihan hatusta heitettynä mutuvakiolla Intelin koostetut tietoturvapaikat ovat hidastaneet prosessoreita yhteensä 10-15%. Se on hirveän paljon. Phoronixilla oli tästä testi pari haavoittuvuutta sitten.

Nytkin kiinnostaa vaan se, että otetaanko L1 cache prediction pois päältä, tehdäänkö jotain pieniä mitigointeja vai annetaanko asian olla? Ts. paljon prosessorini kärsii tästä paikasta?

Intelin paikkaukset ovat hidastaneet niitä kotikäyttäjälle selvästi vähemmän, muutaman prosentin luokkaa, mikä on melko merkityksetön, mutta palvelinkäytössä (jossa tehdään paljon IOta) vaikutus on selvästi enemmän, jopa kymmeniä prosentteja.

Ratkaisevaa on prosessorin käyttötarkoitus. Kotikäyttäjälle nämä on edelleen melko merkityksettömiä, mutta datakeskuksissa on tarvittu paljon lisätehoa korvaamaan näitä.

 

[kahvis]

Intelin paikkaukset ovat hidastaneet niitä kotikäyttäjälle selvästi vähemmän, muutaman prosentin luokkaa, mikä on melko merkityksetön, mutta palvelinkäytössä (jossa tehdään paljon IOta) vaikutus on selvästi enemmän, jopa kymmeniä prosentteja.

Ratkaisevaa on prosessorin käyttötarkoitus. Kotikäyttäjälle nämä on edelleen melko merkityksettömiä, mutta datakeskuksissa on tarvittu paljon lisätehoa korvaamaan näitä.

Offtopic, mutta tästä tuli kieltämättä mieleen kuinka paljon pienet muutokset vaikuttaa isossa skaalassa...

The Linux Kernel Seeing Backport Progress Finally For The "$1.5 Million Dollar Bug"

 

[Sami Riitaoja]

Nytkin kiinnostaa vaan se, että otetaanko L1 cache prediction pois päältä, tehdäänkö jotain pieniä mitigointeja vai annetaanko asian olla? Ts. paljon prosessorini kärsii tästä paikasta?

Tuskin tehdään yhtään mitään, varsinaisia haavoittuvuuksiahan ei löydetty.

Ja kyse ei varsinaisesti ole way-predictorista joka olisi kytkettävissä pois päältä vaan L1-cache on tagattu vain tuolla microtagilla. Way predictor on aikaisemmin ollut vihje jonka mukaan cachesta on tarkastettu vihjeen osoittama linja ensin ja loput jos ei tullut osumaa. Microtagilla AMD:n tapauksessa cache-setistä tarvitsee tutkia maksimissaan vain 8 bittiä jokaisesta setin 8:sta linjasta joten kaikki linjat tutkitaan kerralla ja hudin tulessa siirrytään L2:een. Eli jos jotain kytkettäisiin pois niin se olisi koko L1-cache.

Mitä tuossa nyt on "haavoittuvuuksia" löydetty niin tietämällä tuon microtagin hash-algoritmi on helppo tehdä koodinpätkä jolla saadaan osittaisia muistiosoitteita(vähiten merkitsevät 28 bittiä) dekoodattua kernelistä. Toki hash-algoritmin tietäminen mahdollistaa haavoittuvuuksien etsimisen prosessorista, ja em. artikkelin kirjoittanut ryhmä oli niitä etsinytkin mutta ainakaan vielä mitään ei ollut löydetty eli AMD:n varautuminen sivukanavahyökkäyksiin käsittää muutakin kuin tuon yksinkertaisen microtagin hashauksen.

 

[jyppi]

Ja samaan aikaan Inteleistä löytynyt hieman vakavampi ongelma, jota ei voida korjata.

5 years of Intel CPUs and chipsets have a concerning flaw that’s unfixable

Converged Security and Management Engine flaw may jeopardize Intel's root of trust.

arstechnica.com

 

[Kaotik]

Ja samaan aikaan Inteleistä löytynyt hieman vakavampi ongelma, jota ei voida korjata.

5 years of Intel CPUs and chipsets have a concerning flaw that’s unfixable

Converged Security and Management Engine flaw may jeopardize Intel's root of trust.

arstechnica.com

Sille on ihan oma uutisensa ja ketjunsa: Intelin piirien tietoturvasta vastuussa olevasta CSME:stä löytyi ongelma jota ei voida korjata - io-tech.fi / Intelin piirien tietoturvasta vastuussa olevasta CSME:stä löytyi ongelma jota ei voida korjata

 

[Japi001]

Onneksi ei tullut hommattua AMD prossua

 

[hkultala]

Tuskin tehdään yhtään mitään, varsinaisia haavoittuvuuksiahan ei löydetty.

Ja kyse ei varsinaisesti ole way-predictorista joka olisi kytkettävissä pois päältä vaan L1-cache on tagattu vain tuolla microtagilla.

Olet näköjään edelleenkin pihalla siitä, miten välimuistin kirjanpito toimii.

Ja näistä Zenin microtageista:

https://developer.amd.com/wordpress/media/2013/12/55723_SOG_Fam_17h_Processors_3.00.pdf

The L1 data cache tags contain a linear-address-based microtag (utag) that tags each cacheline with the linear address that was used to access the cacheline initially. Loads use this utag to determine which way of the cache to read using their linear address, which is available before the load's physical address has been determined via the TLB.

Edelleenkin; se, että välimuisti tagattaisiin millään muulla kuin täysikokoisella tagillä johtaisi siihen, että ei tiedettäisi, mitä dataa siellä välimuistissa on, ja luettaisiin sieltä väärän osoitteen dataa. Siellä on pakko olla jossain ihan täysimittainen tag jotta tiedetään varmuudella, että data jota välimuistista ladataan on varmasti se oikea data.

Yritin tätä selittää sinulle jo joskus kauan sitten, mutta ei tunnu uppoavan sitten millään.

Tuon microtagin merkitys on nimenomaan toimia way predictionina; Ensin ladataan kaikkein kahdeksan wayn microtagit oikeasta indeksistä (indeksi on osoitebitit 6-11, eli ollaan neljän kilotavun sisällä, eli siihen riittää virtuaaliosoite) , ja niiden perusteella tarkastetaan osuma (verrataan microtagia hashiin koko virtuaaliosoitteesta).

Mikäli löytyy osuma jostain waystä, valitaan se way, ladataan rinnakkain siitä waystä data sekä että varsinainen tagi. Ja siinä vaiheessa kun nämä on saatu ladattua, on myös virtuaaliosoitteen muunnos fyysiseksi osoitteeksi valmis, ja voidaan tehtä tarkastus täyteen fyysisillä osoitteilla toimivaan tagiin.

Way predictor on aikaisemmin ollut vihje jonka mukaan cachesta on tarkastettu vihjeen osoittama linja ensin ja loput jos ei tullut osumaa. Microtagilla AMD:n tapauksessa cache-setistä tarvitsee tutkia maksimissaan vain 8 bittiä jokaisesta setin 8:sta linjasta joten kaikki linjat tutkitaan kerralla ja hudin tulessa siirrytään L2:een.

Tässä nyt menee välillä jotain oikein, tosin syy on ymmärretty väärin.

Zenin L1:n rakenne tosiaankin on sellainen, että mikäli siinä way prediction sanoo, että dataa ei löydy, niin sitten mennään kerralla L2een asti, ja ladataan data sieltä, eikä koskaan yritetä ladata sitä muista L1-wayistä. Ja syy tähän on se, että tilanteet joissa se data löytyisi jostain muusta L1-waystä ovat äärimmäisen harvinaisia, johtuen mm. seuraavasta rajoitteesta:

It is also possible for two different linear addresses that are NOT aliased to the same physical address to conflict in the utag, if they have the same linear hash. At a given L1 DC index (11:6), only one cacheline with a given linear hash is accessible at any time; any cachelines with matching linear hashes are marked invalid in the utag and are not accessible

Eli siis, meillä on neljä mahdollista skenaariota:

1) Halutun osoitteen data on L1-välimuistissa siinä wayssä mikä ennustettiin. Kaikki hyvin ja nopeaa. Hyvin yleinen tilanne.

2) Halutun osoitteen dataa ei ole ollenkaan L1-välimuistissa ja way prediction sanoo että sitä ei siellä ole. Tällöin pitää ladata se L2-välimuistista (seuraavaksi yleisin tilanne). Kaikki hyvin mutta tulee se ~8 kellojakson hidastus kun data ladataan L2-välimuistista (tai vielä pidempi, jos sitä ei ole sielläkään). Seuraavaksi yleisin tilanne.

3) Halutun osoitteen dataa ei ole ollenkaan L1-välimuistissa, mutta way prediction ennustaa väärin, ja sanoo että se löytyy waystä, jossa tosiasiassa on jotain muuta(false positive). Tämä tilanne huomataan siinä vaiheessa, kun ne oikeat täysikokoiset TAGit tarkastetaan, ja ne ei matchääkään sen fyysisen osoitteen kanssa, minkä osoitteenmuunnos virtuaalisesta fyysiseksi antoi antoi, ja tässä vaiheessa käynnistetään L2-access datan hakemiseksi sieltä. Jos niitä täysikokoisia TAGejä ei olisi ja tarkastettaisi, tässä tapauksessa ladattaisiin kiltisti mitään tajuamatta väärä data

4) Softassa on mappaus samalle samaan fyysiseen osoitteeseen useammalla eri virtuaaliosoitteella, mikä mahdollistaa eri hashin samaan fyysiseen osoitteeseen. Tällöin way prediction voi antaa false negativen; Sanoa että dataa ei löydy L1-välimuistista, vaikka se tosiasiassa on siellä Tällöin se ladataan L2-välimuistista, mikä on teoriassa epäoptimaalista.

Tämä tilanne on kuitenkin hyvin harvinainen; Usealla virtuaaliosoitteella on tyypillisesti mappays samaan fyysiseen osoitteeseen lähinnä vain kun kyse on jostain nollasivuista (käyttiksen optimointi muistinkulutuksen vähentämiseksi). Ja koska tämä tilanne on hyvin harvinainen, tuo "aina kun way prediction sanoo että data ei löydy L1stä, mennään suoraan L2een" on järkevä rajoite; Se, että ruvettaisiin välissä katsomaan niitä muita L1-waytä olisi ihan turhaa haaskausta niissä yleisissä tilanteissa tämän hyvin harvinaisen tilanteen nopeuttamiseksi.

Eli jos jotain kytkettäisiin pois niin se olisi koko L1-cache.

Mutta tässä olet todennäköisesti oikeassa, että tuota way predictionia ei todennäköisesti saa kytkettyä pois päältä, koska se on niin oleellisessa roolissa siinä, että yritetäänkö mitään edes ladata L1-välimuistista; Mitään accesseja ei Zenissä tosiaankaan tehdä L1-cacheen muuta kuin sellaiseen wayhin joka on saanut way prediction hitin.

 

[Sami Riitaoja]

Olet näköjään edelleenkin pihalla siitä, miten välimuistin kirjanpito toimii.

Ja näistä Zenin microtageista:

https://developer.amd.com/wordpress/media/2013/12/55723_SOG_Fam_17h_Processors_3.00.pdf

Edelleenkin; se, että välimuisti tagattaisiin millään muulla kuin täysikokoisella tagillä johtaisi siihen, että ei tiedettäisi, mitä dataa siellä välimuistissa on, ja luettaisiin sieltä väärän osoitteen dataa. Siellä on pakko olla jossain ihan täysimittainen tag jotta tiedetään varmuudella, että data jota välimuistista ladataan on varmasti se oikea data.

Yritin tätä selittää sinulle jo joskus kauan sitten, mutta ei tunnu uppoavan sitten millään.

OOO-prossussa se välimuistin tägi ei ole ensimmäinen arvaus joka suorituksessa tehdää, varmaan 90% todennäköisyydellä käsky joka sitä dataa lukee ei tässä vaiheessa tiedetä oikeaksi. Kuitenkin haluat olla 100% varma tägin oikeellisuudesta tasan heti tässä vaiheessa.

Juu, kyllä se välimuistin osuman oikeellisuuskin tarvitsee tarkistaa, mutta sen viimeinen tarkistusvaihe on kun siihen liittyvä data on siirtymässä store-queuesta välimuistiin. Siihen asti kaikki on peruttavissa. Näin tiedämme esimerkiksi Intelin prosessoreiden toimivan, Intel ei tätä tietysti ole kertonut mutta store-queuesta pääsee bugin takia microtagattu eri osoiteavaruudesta peräisin oleva data karkaamaan kun prosessori vaihtaa store-queuen moodia kahdesta threadista yhteen ja yhdistää puskurin. Ja aikaa store-queuen ronkkimiseen saadaan kun mukaan ujutetaan käsky jonka fyysisen osoitteen määrittäminen kestää kauan jonka ajan puskurin tarkistukset on jumissa.

Tuon microtagin merkitys on nimenomaan toimia way predictionina; Ensin ladataan kaikkein kahdeksan wayn microtagit oikeasta indeksistä (indeksi on osoitebitit 6-11, eli ollaan neljän kilotavun sisällä, eli siihen riittää virtuaaliosoite) , ja niiden perusteella tarkastetaan osuma (verrataan microtagia hashiin koko virtuaaliosoitteesta).

Mikäli löytyy osuma jostain waystä, valitaan se way, ladataan rinnakkain siitä waystä data sekä että varsinainen tagi. Ja siinä vaiheessa kun nämä on saatu ladattua, on myös virtuaaliosoitteen muunnos fyysiseksi osoitteeksi valmis, ja voidaan tehtä tarkastus täyteen fyysisillä osoitteilla toimivaan tagiin.

Mikrotaggays on kuitenkin jo aika vanha asia, jos jaksaisit asiaa tutkia löytäisit paljon vaihtoehtoja asian toteuttamiseksi.

...

4) Softassa on mappaus samalle samaan fyysiseen osoitteeseen useammalla eri virtuaaliosoitteella, mikä mahdollistaa eri hashin samaan fyysiseen osoitteeseen. Tällöin way prediction voi antaa false negativen; Sanoa että dataa ei löydy L1-välimuistista, vaikka se tosiasiassa on siellä Tällöin se ladataan L2-välimuistista, mikä on teoriassa epäoptimaalista.

Tämänkin AMD on dokumentoinut. L1:stä tulee huti koska L1:n tageissa tulee huti. L2:sta tulee osuma mutta koska data on jo L1:ssä dataa ei lueta L2:sta vaan L2 korjaa L1:n tagin oikeaksi ja data luetaan L1:stä. Osuman nopeus on vastaava kuin L2:n osumalla.

Tämä tilanne on kuitenkin hyvin harvinainen; Usealla virtuaaliosoitteella on tyypillisesti mappays samaan fyysiseen osoitteeseen lähinnä vain kun kyse on jostain nollasivuista (käyttiksen optimointi muistinkulutuksen vähentämiseksi). Ja koska tämä tilanne on hyvin harvinainen, tuo "aina kun way prediction sanoo että data ei löydy L1stä, mennään suoraan L2een" on järkevä rajoite; Se, että ruvettaisiin välissä katsomaan niitä muita L1-waytä olisi ihan turhaa haaskausta niissä yleisissä tilanteissa tämän hyvin harvinaisen tilanteen nopeuttamiseksi.

Et ole ymmärtänyt koko täggäystä. Eli kaikki L1-wayt tarkastetaan, L1:ssä ei vain ole muuta kuin se microtag. L2 on inklusiivinen joten L2:ssa on myös L1:n data josta L2 voi löytää L1:ssäkin sijaitsevan datan vaikka microtag ei sitä löytäisi. Ja data on L1:n microtagin osuessa jo luettu ja käytössä L2:n tarkastaessa fyysisiä tageja.

Ja microtagi on vain 14 bittinen, huti voi tulla myös syystä että toinen osoite varaa tägin itselleen. Tähänhän tämä haavoittuvuus perustuu. L1:n suhde tägin 32KB//1MB osoiteavaruuteen yhdessä 256MB suoran aliasoinnin estävän häshäyksen kanssa pitää kuitenkin huolen että tägin osumatarkkuus on aikalailla 100%, nopeuteen tägihudeilla ei ole mitään merkitystä. Sivukanavahyökkäyksiin kyllä mutta niihinkin voi varautua muillakin keinoilla kuin pitäytymällä kaikkialla täydessä osoiteavaruudessa.

 

[hkultala]

L2 on inklusiivinen joten L2:ssa on myös L1:n data josta L2 voi löytää L1:ssäkin sijaitsevan datan vaikka microtag ei sitä löytäisi. Ja data on L1:n microtagin osue ssa jo luettu ja käytössä L2:n tarkastaessa fyysisiä tageja.

Skenaario: L2-Välimuistiin on talletettu kaksi välimuistilinjaa, joiden fyysiset osoitteet ovat vaikka 0 ja 65536.

Molemmat osoitteet osuvat välimuisteissa indeksiin 0, mutta ne on L2-välimuistissa tallennettu eri way:hin.

Oletetaan että meiltä löytyy sellaiset virtuaalimuistimappaykset, että meillä on kaksi eri virtuaaliosoitetta, ja toinen niistä on mapatty fyysiseen osoitteeseen 0 ja toinen fyysiseen osoitteeseen 65536, ja nämä molemmat virtuaaliosoitteet tuottavat saman hajautusarvon microtagille.

Jompi kumpi näistä on ladattu myös L1-välimuistiin.

Sinulla ei ole mitään keinoa tietää, kumman osoitteen data L1-välimuistissa on. Kun sinun L2-tagisi antavat sille kaksi eri vaihtoehtoa, joko osoite 0 tai osoite 65536.

=> L2-tagit eivät toimi L1-välimuistille, jokainen välimuisti tarvii ihan omat (täydet) taginsa.

 

[Sami Riitaoja]

No jos vaikka laitan L2:een bitin osoittamaan mikä linja on tällä hetkellä ladattuna L1:een.

Aivan hirmuinen ongelma siis ratkaista insinöörille. Sama bitti kertoo sille L2:lle että data on jo L1:ssä eikä sitä tarvitse uudestaan sinne ladata.

Microtageissä on paljon muutakin ratkaistavaa, nekun siis ovat virtuaalisia eivät lineraarisia ne on pidettävä prosessikohtaisina, todennäköisesti jopa threadikohtaisina ja tuhottava näiden vaihdoissa. Näitähän tässä on testattu ja AMD saanut toistaiseksi puhtaat paperit.

 

[hkultala]

No jos vaikka laitan L2:een bitin osoittamaan mikä linja on tällä hetkellä ladattuna L1:een.

... ja sitten aina kun jotain ladataan L1-välimuistista, pitäisi käydä kelaamassa kaikkien L2-wayiden tagit läpi että jostain niistä löytyy sekä oikea tagi että vielä sen lisäksi "tämä löytyy L1-välimuistista" bitti ennen kuin latausta saa retirettää.

Välttääksesi lataamasta n. 32 bitin verran L1-tagia tasan yhdestä waystä haluat ladata n. 8 * 28 = yhteensä n. 224 bitin verran tagia (yhteensä kaikista kahdeksasta L2-waystä, koska data voi olla duplikoitu mihin tahansa niistä), jotka vielä on selvästi kauempana siltä ytimeltä. ja välittää se sitten liukuhihnalla retireä odottamassa olevalle käskylle. Aika moninkertainen virrankulutus.

Jopa on "loistava" vaihtokauppa.

Aivan hirmuinen ongelma siis ratkaista insinöörille.

AMDn insinöörit eivät ole näin typeriä.

Microtageissä on paljon muutakin ratkaistavaa, nekun siis ovat virtuaalisia eivät lineraarisia ne on pidettävä prosessikohtaisina, todennäköisesti jopa threadikohtaisina ja tuhottava näiden vaihdoissa. Näitähän tässä on testattu ja AMD saanut toistaiseksi puhtaat paperit.

Välimuistin invalidointi context switchin yhteydessä olisi myös melkoisen typerää, jos toisessa säikeessä viivytään vain hyvin vähän aikaa.

Vielä typerämpää se olisi vaihtaessa saman softan kahden eri säikeen välillä.

Kuten jo äsken sanoin, AMDn insinöörit eivät ole typeriä.

Väärän prosessin microtag johtaa vaan siihen, että way prediction ennustaa väärin kun sitä yritetään käyttää Ja tällöin L2-välimuistista (tai kauempaa) ladataan samaan wayhin oikea data ja vanhan prosessin data ja väärä microtag lentää L1stä mäkeen.

 

[Sami Riitaoja]

... ja sitten aina kun jotain ladataan L1-välimuistista, pitäisi käydä kelaamassa kaikkien L2-wayiden tagit läpi että jostain niistä löytyy sekä oikea tagi että vielä sen lisäksi "tämä löytyy L1-välimuistista" bitti ennen kuin latausta saa retirettää.

Välttääksesi lataamasta n. 32 bitin verran L1-tagia tasan yhdestä waystä haluat ladata n. 8 * 28 = yhteensä n. 224 bitin verran tagia (yhteensä kaikista kahdeksasta L2-waystä, koska data voi olla duplikoitu mihin tahansa niistä), jotka vielä on selvästi kauempana siltä ytimeltä. ja välittää se sitten liukuhihnalla retireä odottamassa olevalle käskylle. Aika moninkertainen virrankulutus.

Jopa on "loistava" vaihtokauppa.

Kerrran siitä L2:sta on täytynyt tehdä inklusiivinen pitää siinä myös pitää yllä tietoa mitä dataa ei voi hävittää. Joten luulisin että samantien on tehty L1:n täydellinen varjokuva eli L1:n duplikaatit L2:ssa ovat vakiopaikoilla, samalla voidaan järjestää L2:n sisälle VIPT-tarkistus L1:n tageille jos halutaan.

Välimuistin invalidointi context switchin yhteydessä olisi myös melkoisen typerää, jos toisessa säikeessä viivytään vain hyvin vähän aikaa.

Vielä typerämpää se olisi vaihtaessa saman softan kahden eri säikeen välillä.

Kuten jo äsken sanoin, AMDn insinöörit eivät ole typeriä.

Väärän prosessin microtag johtaa vaan siihen, että way prediction ennustaa väärin kun sitä yritetään käyttää Ja tällöin L2-välimuistista (tai kauempaa) ladataan samaan wayhin oikea data ja vanhan prosessin data ja väärä microtag lentää L1stä mäkeen.

Microtagit invalidoidaan jokatauksesssa -> L1 ei ole käytettävissä context switchissä. Paskan väliä kun muutaman kellojakson menettää kun data on L2:ssa. SMT:ssä kumpikin threadi omaa oman cache-id:nsä eli eivät jaa L1:n cachea vaikka ajavat samaa threadia.

Niin jos homma toimisi kuten luulet. Data luetaan sen microtagin perusteella ja siirretään eteenpäin, jos sallitaan toisen prosessin lukevan toisen dataa pystytään sivukanavahyökkäyksellä saamaan esille tietoa jonka pitäisi pysyä salassa.

Lisäksi dataa ei voi siirtää L2:sta L1:een ilman että kaikki L1:n tagit on tarkastettu. Eli joko tarkastetaan L1:n kaikki tagit tai L2 tekee sen, ja AMD:n L1:n microtagien tapauksessa on hyvinkin dokumentoitu että L2 suorittaa sen.

Ja yksi fyysisen taggaamisen ominaisuus on että duplikaatioita samasta datasta ei voi tulla eri virtuaaliosoitteilla -> L1:n kaikkien wayden fyysiset tagit pitää tarkastaa ennen datan lataamista L2:sta L1:teen. Eli kun virtuaalinen microtag-way predictor missaa kaikki L1:n fyysiset tagit on kuitenkin tarkistaa ennenkuin L2 voi ladata mitään -> kerran L2 suorittaa em. toimenpiteen lienee aika päivänselvää että L1:ssä ei fyysisiä tageja ole.

Ja mitä tulee microtagien invalidointiin context switcheissä - aivan turha itkeä naurettavan mitättömän mahdollisen nopeusedun puolesta joka saataisiin jos sattumalta em. ydin palaisi suorittamaan edellistä threadia. Ja siitä insinöörien typeryydestä, jos microtagataan tai muuten oiotaan TLB:ssä niin turvallisuus on aika hyvällä pohjalla jos cachesta voidaan ladata vain ko. threadin sinne ensin itse lataamaansa dataa. Intelin toteutushan ei tätä kunnioita ja tunnetaan L1 terminal faultina, eli toisen prosessin dataa pääsee valumaan SMT:n threadien ja saman ytimen context-switchien välillä. Ratkaisunahan on SMT:n disablointi tai ainakin rajoittaminen samaan muistidomainiin ja L1:n tyhjennys mikrokoodilla context switchissä pelkkien tagien nollauksen sijaan - ja ko. L1-cachen huomattavan raskaan tyhjennysoperaation vaikutus suorituskykyyn on korkeintaan prosentteja. Tästä voi arvioida paljonko raudalla toteutettu microtagien invalidointi suorituskykyä syö.

 

[demu]

Vanhaa kunnon taistelumeininkiä taas...

 

[VmH]

Ettei vaan olisi alkanut olemaan Windows solmussa? Nimittäin itselläni ei ollut edes 2600k:lla mitään tuollaisia ongelmia. Kyllä Ryzen toi sitli kivasti lisää tehoja pelailuun ja ennen kaikkea jäi vielä reserviin. Pääsasia tietysti että olet päivitykseen tyytyväinen -eteenpäinhän tuo kehitys on mennyt kuitenkin (vähintään tietoturvan näkökulmasta)

Paha sanoa mutta itse huomasin ainakin selkeän eron spectre -päivityksen jälkeen. Eräässä pelaamassani pelissä yksi raidi alkoi tökkimään melko ratkaisevasti, joten fps lasku oli ainakin hyvin huomattavissa. Kaikista selkein ongelma oli kuitenkin se, että jos Chromen jätti taustalle päälle, niin pelissä laski huimasti fps. Discordissa alkoi myös äänet pätkimään jos chrome oli taustalla päällä pelin pyöriessä.

Tätä ongelmaa ei ollut koskaan ennen spectre päivitystä.

 

[Kankipappa]

Paperia lukiessa tuli vaan mieleen että ilmeisesti pitäisi olla muokattu kerneli että tätä pystyy edes tekemään ja tarvitsee myös fyysisen pääsyn koneeseen admin oikeuksin. Vai ymmärsinkö väärin?

Onko tälläkään siis mitään merkitystä mihinkään suuntaan vai onko tämä van keino kehittäjillä varmistaa että saavat kehitysrahansa myös jatkossa, johon myös Intel on lyönyt rahaansa jo pari vuotta.

 

[Luckyo]

Omalla kotikoneella skylake-s:llä en huomannut mitään vaikutusta, vaikka patchit on biosissa ja windowsissa. Tehonmenetyksen pitikin olla luokkaa 1-2%, mikä ei ole havaittavissa juuri missään kotikäytössä.

Palvelimissa sen sijaan olen nähnyt kaverien painivan reilusti yli 10% tehonpudotuksen kanssa. Tunnen ainakin kaksi tapausta jossa on jouduttu patchien jälkeen hankkimaan lisää palvelinkapasiteettia. Eli intel on siis saanut enemmän myyntiä noilla haavoittuvuuksilla. Tyhmää mutta totta.

 

[KVahlman]

Onko tälläkään siis mitään merkitystä mihinkään suuntaan vai onko tämä van keino kehittäjillä varmistaa että saavat kehitysrahansa myös jatkossa, johon myös Intel on lyönyt rahaansa jo pari vuotta.

Tietoturvatutkimuksella on aina merkitystä, varsinkin raudan kanssa kun sitä ei voida noin vain korjailla päivityksillä vaan homman pitäisi olla kerralla oikein. Se että kenen rahalla tutkimusta tehdään lienee toissijaista kunhan tulokset on julkisia ja todenmukaisia.

Ja jos Intel maksaisikin nimenomaan AMD:n raudan syynäystä (mistä ei siis tässä keississä ole kyse vaikka monet heti halusivat kun intelin nimi mainittiin tukijoissa) niin kyllä AMD silloin varmaan vaan kiittää Inteliä Zen4:n tietoturvan kehitystyöhön osallistumisesta. Mikäs sen kivempaa kuin saada joku muu maksamaan tuollaista testausta jota prossuvalmistajan soisi itsekin harrastavan?

 

[Cirrus]

Paperia lukiessa tuli vaan mieleen että ilmeisesti pitäisi olla muokattu kerneli että tätä pystyy edes tekemään ja tarvitsee myös fyysisen pääsyn koneeseen admin oikeuksin. Vai ymmärsinkö väärin?

Onko tälläkään siis mitään merkitystä mihinkään suuntaan vai onko tämä van keino kehittäjillä varmistaa että saavat kehitysrahansa myös jatkossa, johon myös Intel on lyönyt rahaansa jo pari vuotta.

Techin artikkeli linkkasi tomsin uutiseen jossa sanotaan:
"The researchers exploited the vulnerability via JavaScript run on Chrome and Firefox browsers, and also gained access to AES encryption keys. The exploit can also purportedly be used to penetrate cloud deployments in the data center. "

En itse ymmärtänyt mitenkään että tarvisi admin oikeuksia.

 

[Kankipappa]

Techin artikkeli linkkasi tomsin uutiseen jossa sanotaan:
"The researchers exploited the vulnerability via JavaScript run on Chrome and Firefox browsers, and also gained access to AES encryption keys. The exploit can also purportedly be used to penetrate cloud deployments in the data center. "

En itse ymmärtänyt mitenkään että tarvisi admin oikeuksia.

Papereissa taisi lukea jotenkin että tarvitsee paikallisen pääsyn, mutta ei tosiaan vaadi adminoikeuksia (unprivileged access).

 

[Cirrus]

Papereissa taisi lukea jotenkin että tarvitsee paikallisen pääsyn, mutta ei tosiaan vaadi adminoikeuksia (unprivileged access).

En ole edelleenkään samaa mieltä. Nyt kun et uskonut tuota tompan uutista, niin avasin itsekin paperin.
Proof of concept hyökkäykset kappaleissa 5.2.1 ja 5.2.2. vaatii paikallista accessia, mutta proof of concept javascriptillä kappaleessa 5.2.3. ei vaadi mitään paikallista accessia.

 

[Kankipappa]

En ole edelleenkään samaa mieltä. Nyt kun et uskonut tuota tompan uutista, niin avasin itsekin paperin.
Proof of concept hyökkäykset kappaleissa 5.2.1 ja 5.2.2. vaatii paikallista accessia, mutta proof of concept javascriptillä kappaleessa 5.2.3. ei vaadi mitään paikallista accessia.

Tuota paperia on muutenkin hankala lukea ja aiemmin tosiaan kommentoin puhelimella, niin en päässyt sitä uudelleen vilkaisemaan.

5.2.3 kohdassa mainitaan että sitä selaimissa tuokin on estetty ja siihen on jouduttu käyttämään javascriptissä high precision timeria. Viittaa vissiin tähän lähteissä (69): https://gruss.cc/files/fantastictimers.pdf eli 2017 vuoden vulnerabilityyn. Tuossa taas puhutaan että vaikka se olisi paikattu selaimista tuon julkaisun aikaan, niin se paikkaus ei olisi kuitenkaan riittänyt. Onko tuo sama javascript ongelma edelleen siis olemassa vielä vuonna 2020 selaimissa? Sitä en nyt jaksanut ottaa selvää, mutta aika vaikeaksi menee.

 

[Sami Riitaoja]

Siis tän nyt vuodetun AMD-haavoittuvuuden lopputuloshan oli että mitään suurempaa haavoittuvuutta ei löydetty. Nuo mitä saatiin aikaiseksi on jo paikattu muiden Spectre-haavoittuvuuksien takia.

Intelille taas tuli uusi ja paha tälläkertaa, eli Meltdown-prossuista löytyi LVI-nimellä tunnettu haavoittuvuus jonka paikkaaminen vaatii ohjelmien käännöksen uusiksi ja potentiaalinen hidastus 2-19x.......

 

[Stephen Elop]

Siis tän nyt vuodetun AMD-haavoittuvuuden lopputuloshan oli että mitään suurempaa haavoittuvuutta ei löydetty. Nuo mitä saatiin aikaiseksi on jo paikattu muiden Spectre-haavoittuvuuksien takia.

Lukasin tuota paperia. Jäin siihen käsitykseen, että nuo aiemmat paikkaukset eivät vaikuta tähän. Paitsi kotikäyttäjien selaimet voivat ilmeisesti olla turvassa patchien kanssa (mutu).

Näkisin että nyt on AMD:nkin prossut korkattu ja Intel on korkannut meltdownista/spectrestä asti kylmässä olleen samppanja pullon. Intel tukenut tutkijoita ruhtinaallisesti kuten paperissaan mainitsivat. Aika kovan työn tehneet selvittäessään dokumentoimattoman "cache-way prediction" -funkkarin toimintaa. Tosin en usko tutkijoiden olevan puolueellisia vaikka kohteena olikin vain AMD:n prossuja. Ne olivat vain hyvä haaste, kun muut ei niitä ole onnistuneet saamaan vuotamaan tietoa. Mutulla veikkaan että tämä sama haavoittuvuus on myös Intelin prossuissa, jos vain tutkisivat.

AMD:n kannattaisi muuttaa vastaustaan. Kyllä tää siellä pilvipalvelujen konesaleissa ainakin vähän vaikuttaa.

 

[Sami Riitaoja]

Lukasin tuota paperia. Jäin siihen käsitykseen, että nuo aiemmat paikkaukset eivät vaikuta tähän. Paitsi kotikäyttäjien selaimet voivat ilmeisesti olla turvassa patchien kanssa (mutu).

Näkisin että nyt on AMD:nkin prossut korkattu ja Intel on korkannut meltdownista/spectrestä asti kylmässä olleen samppanja pullon. Intel tukenut tutkijoita ruhtinaallisesti kuten paperissaan mainitsivat. Aika kovan työn tehneet selvittäessään dokumentoimattoman "cache-way prediction" -funkkarin toimintaa. Tosin en usko tutkijoiden olevan puolueellisia vaikka kohteena olikin vain AMD:n prossuja. Ne olivat vain hyvä haaste, kun muut ei niitä ole onnistuneet saamaan vuotamaan tietoa. Mutulla veikkaan että tämä sama haavoittuvuus on myös Intelin prossuissa, jos vain tutkisivat.

AMD:n kannattaisi muuttaa vastaustaan. Kyllä tää siellä pilvipalvelujen konesaleissa ainakin vähän vaikuttaa.

Siis onhan AMD:n prossuissakin sivukanavahaavoittuvuuksia ja mitä tällä saadaan ulos, joitakin bittejä osoitetietoja jotka todennäköisesti saadaan ulos ihan jo sillä jos prosessorissa on x-way associated cache - samoja osoitebittejä omaavat linjat ajavat toisiaan cachesta ulos. Tuo demo vuotaa kernel dataa oli ihan perus spectre jonka sivukanava oli vaihdettu tuohon AMD:n microtagiin perustuvaan - prossuihin voi nyt tehdä vaikka minkälaisia sivukanavia mutta salaisen datan vuotaminen on se varsinainen ongelma.

Tosin ei varmasti AMD:n osaltakaan ole kaikkea vielä nähty, esimerkiksi käskypuolen microtaggaus voi käyttää eri hashiä ja se on vielä avaamatta, datapuoli on paljon helpommin murrettavissa mutta käskypuoli on haavoittuvaisempi, ei välttämättä olisi typerää pistää käskypuolelle sopivasti erilainen häshäys. Mutta kohtuullisen vahva esitys AMD:llä toistaiseksi, tai oikeastaan toisinpäin - Intelin esitys on aika heikko, suurinpiirtein mitä ikinä kukaan keksiikään niin tuntuu aina toimivan Intelin raudalla.

 

[Sami Riitaoja]

... ja sitten aina kun jotain ladataan L1-välimuistista, pitäisi käydä kelaamassa kaikkien L2-wayiden tagit läpi että jostain niistä löytyy sekä oikea tagi että vielä sen lisäksi "tämä löytyy L1-välimuistista" bitti ennen kuin latausta saa retirettää.

Välttääksesi lataamasta n. 32 bitin verran L1-tagia tasan yhdestä waystä haluat ladata n. 8 * 28 = yhteensä n. 224 bitin verran tagia (yhteensä kaikista kahdeksasta L2-waystä, koska data voi olla duplikoitu mihin tahansa niistä), jotka vielä on selvästi kauempana siltä ytimeltä. ja välittää se sitten liukuhihnalla retireä odottamassa olevalle käskylle. Aika moninkertainen virrankulutus.

Niin ja siis L1-osumat tarkistetaan tottakai täysin virtuaalisesti. L2 hoitaa vain L1-microtagin missit ja muiden ytimien coherenssipyynnöt fyysisten tagien mukaan, threadi lukiessaan virtuaalisesti tagattua L1:tä ei tarvii fyysisiä tageja mihinkään.

Microtagihan on vain sen takia että L1-haut täyden 48-bittisen tagin avulla olisi täysin turhaa tuhlaamista. Microtagin osuman varmistaminen 100% varmaksi ei tarvitse osoitteen kääntämistä vaan ainoastaan loppujenkin virtuaalibittien tarkistamista. Tätä kait voisi nimittää vaikka L0-tlb:ksi kun ko. tlb ei käännä osoitetta mutta yhdessä L1:n linjojen fyysisten tagien kanssa(jotka siis sijaitsevat vain L2:ssa) L1:eeen tulevien osumat myös kääntyvät 100% varmasti eli L1-cache hit ei voi missata TLB:tä. Näin nimetyn L0:n tlb::n käännöspasiteetti olisi siis L1:n koko ilman muita rajoituksia. Toimiiko piiri näin olisi ihan testattavissakin, en ole ikinä tosin kenenkään nähnyt asiaa tutkivan.

L1 siis luetaan täysin virtuaalisesti ilman TLB-käännöksiä, ja mitään virtuaalisen cachen ongelmia pois luettuna mitätön alennus hit-ratessa ei tule koska L1 on myös fyysisesti tagattu L2:ssa ja L2 hoitaa L1:n muistihaut. Ja tämähän on varsin simppeli systeemi, enköhän tätä ole koittanut vaihtelevalla menestyksellä selitellä vuosia sittenkin. AMD:n dokumentointi Zenin L1-cachen microtageista ja niiden käyttäytymisestä viittaa aika vahvasti että olisivat käyttäneet prossuissaan sattumalta juuri tätä schemeä - tosin esimerkiksi L0-tlb:tä ei ole dokumentoitu toimimaan em. tavalla mutta eipä noista ole muutenkaan kaikkea sielunelämää paljastettu kovinkaan tarkasti.