AMD:n Zen 3 -prosessoreissa on Spectre v4:n kaltaisen haavoittuvuuden mahdollistava ominaisuus

[Kaotik]

AMD on kertonut Zen 3 -arkkitehtuurista löytyvän Predictive Store Forwarding -ominaisuuden mahdollistavan Spectre v4:n kaltaisen sivukanavahaavoittuvuuden.
Haavoittuvuuden kerrotaan koskevan etenkin ns. hiekkalaatikoissa (sandbox, muusta järjestelmästä eriytetty suoritusympäristö) pyöriviä sovelluksia ja yhtiö on kertonut ehdottaneensa jo Linux-puolelle ongelmaa paikkaavia päivityksiä.
Ominaisuus on oletuksena käytössä eikä haavoittuvuuden olemassaolo muuta tilannetta, sillä todellinen riski hyökkäyksille on AMD:n mukaan pieni. Yhtiön mukaan sen tiedossa ei ole ainuttakaan esimerkkiä haavoittuvuutta hyödyntävästä koodista.
AMD on julkaissut jo Linux-päivitykset, jotka mahdollistavat ominaisuuden kytkemisen pois päältä hleposti. Phoronixin testien mukaan ominaisuuden kytkeminen pois päältä heikentää suorituskykyä pahimmillaan noin 1-2 %.

Lähde: Predictive Store Forwarding

 

[KVahlman]

Tekisi mieli kaivaa esiin jonkun heittämä kommentti kun viimeksi asia oli kuuma topikki että onneksi AMD ei oio suorituskyvyn takia turvallisuuden kustannuksella, mutta ehkä se olisi liian perseilyä jopa tälle foorumille. Hieman vaan huvittaa näin jälkikäteen.

Olisi mielenkiitoista tietää miten paljon näillä on vaikutusta tulevaisuuden prosessoreita suunnitellessa (joudutaanko esim kokonaan luopumaan tämän tyyppisistä optimoinneista), mutta se taitaa olla aika hankala määrittää.

 

[Hannibal]

Ilmeisesti kaikki ennustavat systeemit on alttiita, joten tämä vaiva tulee olemaan riesana hamaan tulevaisuuteen prossien kanssa. Well... saas nähdä luovutaanko ennenpitkää kaikista vastaavista menetelmistä jossain vaiheessa.

 

[Kaotik]

Tekisi mieli kaivaa esiin jonkun heittämä kommentti kun viimeksi asia oli kuuma topikki että onneksi AMD ei oio suorituskyvyn takia turvallisuuden kustannuksella, mutta ehkä se olisi liian perseilyä jopa tälle foorumille. Hieman vaan huvittaa näin jälkikäteen.

Olisi mielenkiitoista tietää miten paljon näillä on vaikutusta tulevaisuuden prosessoreita suunnitellessa (joudutaanko esim kokonaan luopumaan tämän tyyppisistä optimoinneista), mutta se taitaa olla aika hankala määrittää.

Ominaisuutta ei olla kytkemässä vakiona pois päältä joten sitä tuskin tullaan poistamaan tulevistakaan malleista.

 

[FlyingAntero]

Tekisi mieli kaivaa esiin jonkun heittämä kommentti kun viimeksi asia oli kuuma topikki että onneksi AMD ei oio suorituskyvyn takia turvallisuuden kustannuksella, mutta ehkä se olisi liian perseilyä jopa tälle foorumille. Hieman vaan huvittaa näin jälkikäteen.

Olisi mielenkiitoista tietää miten paljon näillä on vaikutusta tulevaisuuden prosessoreita suunnitellessa (joudutaanko esim kokonaan luopumaan tämän tyyppisistä optimoinneista), mutta se taitaa olla aika hankala määrittää.

Eihän siinä ole mitään uutta, että AMD:n prosessorit ovat alttiita Spectrelle Intelin tapaan?

• AMD julkaisi oman tiedotteensa koskien Meltdown- ja Spectre-tietoturvauhkia - io-tech.fi
• AMD päivitti tilannettaan Spectre-haavoittuvuuden osalta, päivitysten jako jo käynnissä - io-tech.fi

AMD:n prosessorit eivät sen sijaan ole kärsineet ainakaan toistaiseksi Meltdownista. Jos olen oikein ymmärtänyt, niin Meltdown on ollut näistä vaarallisempi. En osaa sanoa, kumman korjaus aiheuttaa enemmän suorituskyvyn laskua mutta AMD:llä ei ole raportoitu vastaavia lukemia kuin Intelillä. Eikä tuo nyt raportoitu 1-2% kuulosta paljolta .

• Meltdown & Spectre: Misconceptions, Current Status, & Expert Interviews

To summarize the summary of our previous article: Meltdown is generally agreed to be more severe, but limited to Intel, while Spectre has to do with a fundamental aspect of CPUs made in the past 20 years. They involve an important technique used by modern CPUs to increase efficiency, called “speculative execution,” which is allows a CPU to preemptively queue-up tasks it speculates will next occur.

 

[KVahlman]

Ominaisuutta ei olla kytkemässä vakiona pois päältä joten sitä tuskin tullaan poistamaan tulevistakaan malleista.

Niin lähinnä tarkoitin miten se vaikuttaa suunnitteluun sitten kun keksitään uutta, ei varmaan joo olemassaoleviin designeihin ruveta muutoksia tekemään.

Eihän siinä ole mitään uutta, että AMD:n prosessorit ovat alttiita Spectrelle Intelin tapaan?

Juu ei ole.

 

[hkultala]

En keksi tapaa "korjata" tuota raudalla poistamatta koko PSF-ominaisuutta käytöstä.

Näkisin, että järkevä toimintamalli tämän suhteen AMDltä on jatkaa ennallaan. PSF:n saa BIOSista kytkettyä pois päältä. Kaikessa normaalissa koti-/työpöytäkäytössä todennäköisyys siihen, että tämän kautta saisi mitään haitallista tehtyä on niin äärimmäisen pieni, että PSF kannattaa pitää päällä, mutta joissain super-high-security-palvelimissa voi tämän takia olla järkeä kytkeä tuo pois päältä.

Mutta, JOS joskus joku onnistuu tekemään tunnetun vakavahkon exploitin, joka tätä hyödyntää (minkä todennäköisyyttä pidän hyvin pienenä), sitten voi olla järkevä että ihmiset kääntää BIOSista PSF:n pois päältä.

 

[hik]

Kun haavoittuvuudet on akateemista luokkaa, tuntuu että olisi hyvä jos käyttöjärjestelmä koko ajan tietäisi milloin prosessorin pitää hetkellisesti toimia jossain aukottomassa tilassa, eli ohjelmat pyytäisivät tarpeen mukaan "haavoittumatonta" tilaa käyttikseltä. Ehkä semmoisen tekeminen olisi kumminkin isompikin toimintamallin muutos, kun jotain luottamuksellista, vaikka käyttäjän selaimeen tallentamat salasanat, saattaa olla koko ajan muistissa. Mulle sopisi hyvin jos salasanat hoituisi sitä varten erikseen tehdyllä vähävirtaisella miniprosulla, jossa toimisi tarvittaessa myös matopeli.

 

[KVahlman]

Näkisin, että järkevä toimintamalli tämän suhteen AMDltä on jatkaa ennallaan. PSF:n saa BIOSista kytkettyä pois päältä. Kaikessa normaalissa koti-/työpöytäkäytössä todennäköisyys siihen, että tämän kautta saisi mitään haitallista tehtyä on niin äärimmäisen pieni, että PSF kannattaa pitää päällä, mutta joissain super-high-security-palvelimissa voi tämän takia olla järkeä kytkeä tuo pois päältä.

Joo, varmaankin näin. Toisaalta jos suorituskykyero on kauttaaltaan tuo pari prosenttia niin aika vähän on syitä jättää sitä päällekään nyt kun siinä on todettu (minimaalinen) riski.

 

[hkultala]

Kun haavoittuvuudet on akateemista luokkaa, tuntuu että olisi hyvä jos käyttöjärjestelmä koko ajan tietäisi milloin prosessorin pitää hetkellisesti toimia jossain aukottomassa tilassa, eli ohjelmat pyytäisivät tarpeen mukaan "haavoittumatonta" tilaa käyttikseltä. Ehkä semmoisen tekeminen olisi kumminkin isompikin toimintamallin muutos, kun jotain luottamuksellista, vaikka käyttäjän Chromeen tallentamat salasanat, saattaa olla koko ajan muistissa.

Muistaakseni ARMilla on ainakin jossain käskykannan versiossa ollut joitain käskyjä, joilla on pyritty minimoimaan sivukanavariskejä mm. speksaamalla, että näiden käskyjen suoritusajan pitää olla aina sama riippumatta syötteestä.

Eli kryptokoodi joka käsittelee kryptoavaimia käyttää näitä käskyjä, jotta sen suoritusajasta / sen tekemien muistihakujen ajoituksesta ei voi päätellä yhtään, millasilla arvoilla siellä lasketaan.

Nykyiset kääntäjät on kuitenkin iso ongelma sille, että yritetään kirjoittaa koodi tavalla, joka minimoi sivuvaikutukset; Kääntäjät on liian innokkaita tekemään häröjä optimointeja, jotka taas potentiaalisesti avaavat sivukanavat, jotka pyrittiin poistamaan kirjoittamalla koodi alunperin hiukan hitaalla tavalla; Kääntäjä huomaa, että kun koodin muuttaa vähän toiseen muotoon, sitä voidaan 90% tapauksissa suorittaa nopeammalla tavalla (ja sitten avataan sivukanava joka mahdollistaa sen tunnistamisen, ollaanko siinä 90% vai 10% tapauksessa). Ja usein tämän kontrollointiin ei ole kääntäjissä mitään järkeviä vipuja; Joskus kääntäjät tekevät tällaisia vaikka sille sanoisi että älä optimoi yhtään(-O0) , ja vähintään se -O0 kytkee päältä myös ziljoona hyödyllistä optimointia ja usein allokoi kaikki paikalliset muuttujat pinoon ja suorituskyky putoaa neljäsosaan.

Ja kaikki haarautumiseen liittyvät sivukanavat on kuitenkin siitä ongelmallisia, että haarautumisenennustuksen tai edes spekulatiivisen suorituksen kytkeminen pois päältä käytännössä johtaisi usein niin suureen hidastumiseen, että sitä ei haluta tehdä. Mutta tässä PSF:ssähän tosiaan ei ole kyse haarautumisesta.

 

[hik]

Muistaakseni ARMilla on ainakin jossain käskykannan versiossa ollut joitain käskyjä, joilla on pyritty minimoimaan sivukanavariskejä mm. speksaamalla, että näiden käskyjen suoritusajan pitää olla aina sama riippumatta syötteestä.

Eli kryptokoodi joka käsittelee kryptoavaimia käyttää näitä käskyjä, jotta sen suoritusajasta / sen tekemien muistihakujen ajoituksesta ei voi päätellä yhtään, millasilla arvoilla siellä lasketaan.

Nykyiset kääntäjät on kuitenkin iso ongelma sille, että yritetään kirjoittaa koodi tavalla, joka minimoi sivuvaikutukset; Kääntäjät on liian innokkaita tekemään häröjä optimointeja, jotka taas potentiaalisesti avaavat sivukanavat, jotka pyrittiin poistamaan kirjoittamalla koodi alunperin hiukan hitaalla tavalla; Kääntäjä huomaa, että kun koodin muuttaa vähän toiseen muotoon, sitä voidaan 90% tapauksissa suorittaa nopeammalla tavalla (ja sitten avataan sivukanava joka mahdollistaa sen tunnistamisen, ollaanko siinä 90% vai 10% tapauksessa). Ja usein tämän kontrollointiin ei ole kääntäjissä mitään järkeviä vipuja; Joskus kääntäjät tekevät tällaisia vaikka sille sanoisi että älä optimoi yhtään(-O0) , ja vähintään se -O0 kytkee päältä myös ziljoona hyödyllistä optimointia ja usein allokoi kaikki paikalliset muuttujat pinoon ja suorituskyky putoaa neljäsosaan.

Ja kaikki haarautumiseen liittyvät sivukanavat on kuitenkin siitä ongelmallisia, että haarautumisenennustuksen tai edes spekulatiivisen suorituksen kytkeminen pois päältä käytännössä johtaisi usein niin suureen hidastumiseen, että sitä ei haluta tehdä. Mutta tässä PSF:ssähän tosiaan ei ole kyse haarautumisesta.

Yleisellä tasolla tarkoitin, että nykyiset aukkoja puoliksi umpeen laastaroivat työkalut on kauhean tylppiä työkaluja. Suurin osa tiedosta ei ole luottamuksellista ja melkein poikkeuksetta tiedetään jo ennalta, missä ja milloin sitä käsitellään. Sovellusohjelmat tai jopa käyttäjä itse voisi kertoa käyttikselle, milloin luottamuksellista tietoa käsitellään, ja käyttiksellä olisi toimintatila ja jatkossa jopa erillistä rautaa sitä varten, toki ensin alkuun hiukan korotetulla hintalapulla.

 

[Sami Riitaoja]

Eihän siinä ole mitään uutta, että AMD:n prosessorit ovat alttiita Spectrelle Intelin tapaan?

• AMD julkaisi oman tiedotteensa koskien Meltdown- ja Spectre-tietoturvauhkia - io-tech.fi
• AMD päivitti tilannettaan Spectre-haavoittuvuuden osalta, päivitysten jako jo käynnissä - io-tech.fi

AMD:n prosessorit eivät sen sijaan ole kärsineet ainakaan toistaiseksi Meltdownista. Jos olen oikein ymmärtänyt, niin Meltdown on ollut näistä vaarallisempi. En osaa sanoa, kumman korjaus aiheuttaa enemmän suorituskyvyn laskua mutta AMD:llä ei ole raportoitu vastaavia lukemia kuin Intelillä. Eikä tuo nyt raportoitu 1-2% kuulosta paljolta .

• Meltdown & Spectre: Misconceptions, Current Status, & Expert Interviews

Kerrataas, vielä: Meltdown on rikkoo totaalisesti prosessorin muistisuojauksen. Ilman korjausta Meltdown-prosessori pystyy lukemaan myös muiden suojaustasojen sisältöä ongelmitta. Tämä kuten useimmat muut sivukanavahyökkäykset pystyy vuotamaan vain saman suojaustason muistin sisältöä.

Meltdown "korjaus" softalla estää noiden muiden suojaustasojen muistinsisällön vuotamisen - Meltdown-prosessori on ja tulee aina olemaan täysin rikki tämänkaltaisen sivukanavuotojen osalta - niissä sen sijaan että käytettäisiin tälläistä vaikeahkoa tapaa vuotaa sisältöä voidaan melkein suoraan vain lukea haluttua dataa - ainoa korjaus asiaan on estää itse sivukanavan mahdollisuus vuotaa data esimerkiksi muokkaamalla threadin ajoitukset niin epätarkoiksi että itse sivukanavavuotoa ei pystytä suorittamaan. Em. korjauskaan ei tietysti ole ikinä varma.

 

[hkultala]

Kerrataas, vielä: Meltdown on rikkoo totaalisesti prosessorin muistisuojauksen. Ilman korjausta Meltdown-prosessori pystyy lukemaan myös muiden suojaustasojen sisältöä ongelmitta. Tämä kuten useimmat muut sivukanavahyökkäykset pystyy vuotamaan vain saman suojaustason muistin sisältöä.

Meltdown "korjaus" softalla estää noiden muiden suojaustasojen muistinsisällön vuotamisen - Meltdown-prosessori on ja tulee aina olemaan täysin rikki tämänkaltaisen sivukanavuotojen osalta - niissä sen sijaan että käytettäisiin tälläistä vaikeahkoa tapaa vuotaa sisältöä voidaan melkein suoraan vain lukea haluttua dataa - ainoa korjaus asiaan on estää itse sivukanavan mahdollisuus vuotaa data esimerkiksi muokkaamalla threadin ajoitukset niin epätarkoiksi että itse sivukanavavuotoa ei pystytä suorittamaan. Em. korjauskaan ei tietysti ole ikinä varma.

Höpöhöpö.

Melkoista liioittelua edelleen.

Meltdownilla ei todellakaan pysty "suoraan" lukemaan mitään laitonta dataa, koska yrityksestä suoraan lukea laitonta dataa lentää aina poikkeus (ja sen myötä ohjelman kaatuminen) ennen kuin se luettu data voi päätyä prosessorin arkkitehtuurilliseksi tilaksi.

Meltdownin hyödyntäminen on hyvin epäsuoraa ja vaatii edelleen hyvin suurta kikkailua, 1) pitää ensinnäkin onnistua tekemään haarautuminen jonka prossu ennustaa varmuudella väärin, ja sijoittaa sen toiselle puolelle se laiton luku. Mutta sitä laitonta lukua ei saa koskaan suoraan tehdä, koska se johtaisi sen ohjelman tappamiseen heti. 2) Ja tämän lisäksi pitää se vielä jotenkin saada kikkailtua käyttöön se data, joka on prosessorin datapolulla pelkästään spekulatiivisesti, ilman mitään arkkitehtuurillista keinoa päätyä mihinkään arkkitehtuurilliseen rekisteriin. Tämä on kaikkea muuta kuin helppoa tai nopeaa, vaikka onkin mahdollista, kun prosessorin rakenne tunnetaan tarpeeksi hyvin.

Se että väitetään että pystyy "suoraan lukemaan' tai että "on täysin rikki" osoittaa jälleen taas melkoista Dunning-Krueger-huippua tai suhteellisuustajun puutetta.