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

Kaotik

Banhammer
Ylläpidon jäsen
Liittynyt
14.10.2016
Viestejä
16 167
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
 
Liittynyt
11.02.2019
Viestejä
924
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ää.
 
Liittynyt
14.12.2016
Viestejä
2 236
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

Banhammer
Ylläpidon jäsen
Liittynyt
14.10.2016
Viestejä
16 167
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

ɑ n d r o i d
Liittynyt
17.10.2016
Viestejä
6 490
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: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 :hmm:.
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.
 
Liittynyt
11.02.2019
Viestejä
924
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.
 
Liittynyt
22.10.2016
Viestejä
7 541
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ä.
 
Viimeksi muokattu:

hik

Liittynyt
06.04.2017
Viestejä
1 124
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.
 
Viimeksi muokattu:
Liittynyt
11.02.2019
Viestejä
924
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.
 
Liittynyt
22.10.2016
Viestejä
7 541
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

Liittynyt
06.04.2017
Viestejä
1 124
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.
 
Liittynyt
03.01.2018
Viestejä
417
Eihän siinä ole mitään uutta, että AMD:n prosessorit ovat alttiita Spectrelle Intelin tapaan?
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 :hmm:.
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.
 
Liittynyt
22.10.2016
Viestejä
7 541
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.
 
Toggle Sidebar

Statistiikka

Viestiketjut
124 786
Viestejä
2 436 547
Jäsenet
49 073
Uusin jäsen
Antero10

Hinta.fi

Ylös Bottom