Intelin prosessoreista löytynyt bugi vaatii suorituskykyyn vaikuttavan käyttöjärjestelmätason

[hkultala]

On selaimen sandboxista karkailevia javascript-exploitteja ollut ennenkin. Rowhammer.js tulee ensimmäisenä mieleen. Toinen julkaistu metodi on ASRL-muistiavaruuteen hyökkääminen välimuistin kautta: media.ccc.de - ASLR on the line

Oikein toimivalla ajoympäristöllä Javascriptillä on mahdotonta saada aikaan muistiviittausta, joka viittaa osoitteeseen, jossa ei ole mitään ohjelman dataa koskaan ollutkaan.
Eli jos tässä on kyse tuosta spekuloidusta latauksesta kernelin muistiosoitteeseen, tätä on mahdotonta hyödyntää javascriptin kautta.

Rowhammer onnistuu javascriptistä, koska javascriptissä voi allokoida ison taulukon ja tehdä sen sisälle paljon laillisia muistinosoituksia.

 

[E.T]

Itse veikkaan ettei 99 % tavallisista käyttäjistä huomaa hidastumista ollenkaan,jollain sopivalla testillä varmaankin näkyy mutta ei käytännössä.Samoin veikkaan että pörssikurssit on muutaman viikon kuluttua suurin piirtein hässäkkää edeltävällä tasolla,ei AMD prossu muutu yhtään paremmaksi siitä mitä se oli viikko sitten.

Kyllä tällä tulee olemaan myös pitempiaikaisiakin vaikutuksia suursijoittajien silmissä:
Kotikäytössä reikien paikkausten nopeuspenalty tuskin tulee olemaan merkityksellinen, mutta palvelinpuolella IO-puoli on kovassa käytössä.
Ja siellä liikkuu suuret rahat ja tämä nostaa AMD:n houkuttelevuutta uusia hankintoja tehdessä.

 

[hkultala]

Peruskäytössä eroa tuskin joo huomaa, mutta sit ku tulee puheeseen tyyliin videoenkoodaus taikka montaa ydintä käyttävät pelit, ni siinä todennäköisesti on eroa. Tosin, isoin robleemahan on tottakai tietoturva, siitä ei koskaan saisi tinkiä.

Videoenkoodauksessa nimenomaan ei huomaa, koska siinä tehdään hyvin pieni määrä IO-operaatioita suhteessa laskennan määrän. Datan lukeminen ja talletus tehdään siinä hyvin isoissa blokeissa kerrallaan, joten niiden lukemiseen ja kirjoittamiseen menee hyvin pieni määrä kernelkutsuja.

Melko sama juttu montaa säiettä käyttävillä peleillä. Säikeistykseen liittyen lähinnä se säikeiden luominen hidastuu, mutta säikeiden luominen on muutenkin harvinainen ja hidas asia, joka tehdään pääsääntöisesti ohjelmaa käynnistettäessä, eikä kesken kaiken.

 

[r00t]

Mielenkiintoista nähdä miten virtualisointialustoja kauppaavat Vmware, Oracle ja Microsoft suhtautuvat asiaan ja mitä korjauksia tulee. Ja ennenkaikkea - miten vaikuttaa suorituskykyyn. Hlökohtainen veikkaus on että eniten performance-hittiä ottaa Vmware

 

[Taneli-]

Eli nopeasti laskien jos nyt on käytössä 5GHz kellotettu Intelin prosessori se päivityksen jälkeen vastaa noin 4.75-3.5GHz samanlaista prosessoria niissä ohjelmissa/peleissä jne. missä tuo ongelma ilmenee. JOS esim. näytönohjain tms. ei ole se jarruttava tekijä. (5-30%)

 

[-SD-]

Ei kait tässä sen kummempaa kuin, että odottelemme koetuloksia ennen ja jälkeen korjauspäivityksen.

 

[hkultala]

Eli nopeasti laskien jos nyt on käytössä 5GHz kellotettu Intelin prosessori se päivityksen jälkeen vastaa noin 4.75-3.5GHz samanlaista prosessoria niissä ohjelmissa/peleissä jne. missä tuo ongelma ilmenee. JOS esim. näytönohjain tms. ei ole se jarruttava tekijä. (5-30%)

Lasket täysin rikkinäisillä luvuilla.

Peleillä se hidastuvuus on keskimäärin luokkaa 0.5%, ei 5-30%.


5% tuli Linusilta keskimääräisillä softankehittäjän linux-workloadeilla, jotka on eri asioita kuin windows-pelaajan workloadit.

30% taas oli worst-case real-world-softa joka teki erittäin paljon kernel-kutsuja, mutta teki silti jotain järkevää, eikä pelkkiä kernel-kutsuja kernel-kutsujen ilosta.

 

[Agent_007]

Peruskäytössä eroa tuskin joo huomaa, mutta sit ku tulee puheeseen tyyliin videoenkoodaus taikka montaa ydintä käyttävät pelit, ni siinä todennäköisesti on eroa. Tosin, isoin robleemahan on tottakai tietoturva, siitä ei koskaan saisi tinkiä.

Videopakkauksessa Phoronixin testissä erot osuvat virhemarginaalin sisään sekä FFMPEG:in että x264:n osalta. Ja noissa ei tosiaan muutenkaan pitäisi tulla takkiin, kun videopakkauksessa ei kerneliä tarvita.

 

[Kizmo]

Videopakkauksessa Phoronixin testissä erot osuvat virhemarginaalin sisään sekä FFMPEG:in että x264:n osalta. Ja noissa ei tosiaan muutenkaan pitäisi tulla takkiin, kun videopakkauksessa ei kerneliä tarvita.

Synteettinen pakkaustesti ei ole videoeditointia.

Tahtoisin nähdä sen kun editoidaan videota oikeasti, tai vaikka lennosta livestreamia useampaa HDMI kaapparikorttia käyttäen..

 

[Kaotik]

30% taas oli worst-case real-world-softa joka teki erittäin paljon kernel-kutsuja, mutta teki silti jotain järkevää, eikä pelkkiä kernel-kutsuja kernel-kutsujen ilosta.

Käsittääkseni tuo 30% oli myös synteettinen eikä real world -testi, eikä ole edes etäisesti lähellä worst casea synteettisissä testeissä (Phoronixin tiedostojärjestelmätestissä Coffee Lake otti yli 50% hittiä)

 

[hkultala]

Lähdekoodia tyyppi ei vielä julkaissut.

Mielenkiintoinen yksityiskohta on sanat "no page faults required".

spekulaatiota:

Voi olla että "no page faults required" on toteutettu sillä, että muistiaccessi kiellettyyn osoitteeseen tehdään väärin ennustetussa haarautumisessa, eli siis if-blokissa jonne koodin ei pitäisi mennä. Tämä todennäköisesti taas tarkoittaa, että koodissa pitää nähdä jonkin verran vaivaa sen haarautumisenennustuksen huijaamiseen

 

[Agent_007]

Synteettinen pakkaustesti ei ole videoeditointia.

Tahtoisin nähdä sen kun editoidaan videota oikeasti, tai vaikka lennosta livestreamia useampaa HDMI kaapparikorttia käyttäen..

Ei pitäisi siltikään mennä kernelille kovin paljoa tavaraa. Laiteajurit ovat pitkälti userspace-kamaa nykyään. Ja myös ne nopeat laiteajurit, kuten DPDK ja SPDK.

 

[Mjortten]

Oikein toimivalla ajoympäristöllä Javascriptillä on mahdotonta saada aikaan muistiviittausta, joka viittaa osoitteeseen, jossa ei ole mitään ohjelman dataa koskaan ollutkaan.

Ja täysin virheettömästi toimiva JS-ajoympäristö on? Noh, vitsit vitseinä, eikä ongelman ydin tässä tapauksessa ei ole JavaScriptin mahdollinen heikkous tai soveltuvuus hyökkäykseen. Mutta onhan ainakin WebKit tunnetusti ollut hyvä alusta erilaisille jailbreakeille. Sinänsä hauska yksityiskohta, että pleikka nelonen, mikä on murrettu nimenomaan WebKit/JavaScript ROP-koodilla, on sisuksiltaan AMD.

 

[Kizmo]

Ei pitäisi siltikään mennä kernelille kovin paljoa tavaraa. Laiteajurit ovat pitkälti userspace-kamaa nykyään. Ja myös ne nopeat laiteajurit, kuten DPDK ja SPDK.

Myös VM maailmassa? Myönnettäköön etten aihetta kauhean hyvin tunne.

 

[hkultala]

Ja täysin virheettömästi toimiva JS-ajoympäristö on? Noh, vitsit vitseinä, eikä ongelman ydin tässä tapauksessa ei ole JavaScriptin mahdollinen heikkous tai soveltuvuus hyökkäykseen. Mutta onhan ainakin WebKit tunnetusti ollut hyvä alusta erilaisille jailbreakeille. Sinänsä hauska yksityiskohta, että pleikka nelonen, mikä on murrettu nimenomaan WebKit/JavaScript ROP-koodilla, on sisuksiltaan AMD.

Jos se javascript-ajoympäristö sisältää sellaisen bugin, että sillä voi tehdä javascriptistä laittomia muistiaccesseja, sitten sen tietoturva on joka tapauksessa vakavasti pilalla. Ja se pyritään korjaamaan ASAP jos siitä sellainen aukko löytyy.

 

[Sampsa]

Saksalaiset Computerbase ja Hardwareluxx ajaneet Windows-testejä kuluttajan näkökulmasta:

Windows Build 1709 vs. Build 17063

Intel: Details und Benchmarks zur Sicherheitslücke in allen CPUs

Intel kämpft mit schwerer Sicherheitslücke im Prozessor-Design (Update: Windows-Benchmarks) - Hardwareluxx

Näistä siis tuo 1709 on Fall Creators Update ja tuo 17063 uudempi KPTI-korjauksella varustettu Insider Preview.

 

[Teuras]

ohhoh! Nytpä oli pommi, seuraillaan... (onkohan sopimus sakkoa paukkumassa?)
inteliltä taitaa sulaa nyt isosti valuuttaa tähän sotkuun, kun pääsi julkiseksi ja isommin jos eivät keksi muutakuin purkkaa korjatakseen.

 

[tonkar]

Kyllähän nuo peleissäkin näkyvät olevan tulokset virhemarginaalin ulkopuolella eli kyllä tässä on tosi kyseessä. Ja nuo ovat simppelit FPS-testit, saa nähdä tuleeko myös stutterointia, latausaikojen nousua yms.

 

[DaKyy]

Eiköhän sieltä vähintään joukkokanne jenkeissä ole luvassa suorituskyvyn ja tietoturvan vuoksi.

 

[Puurokulho]

Avg fps peleissä ei juurikaan mitään mitään kerro, mielenkiinnolla odotan mitä frametimet sanoo.

 

[Sothis]

Linuxillahan käsittääkseni sama suorituskykyhitti tuli myös MADin laskimille kernelikorjauksen jälkeen. Onko jo tiedossa, että miten Windows hoitaa homman? Kärsiikö myös MAD nuo samat laskut suorituskyvyssä?

 

[hkultala]

ohhoh! Nytpä oli pommi, seuraillaan... (onkohan sopimus sakkoa paukkumassa?)
inteliltä taitaa sulaa nyt isosti valuuttaa tähän sotkuun, kun pääsi julkiseksi ja isommin jos eivät keksi muutakuin purkkaa korjatakseen.

Eiköhän sieltä vähintään joukkokanne jenkeissä ole luvassa suorituskyvyn ja tietoturvan vuoksi.

Jos kyse on side-channel-hyökkäyksestä, niin ei.

Side-channel-haavoittuvuus ei ole bugi, vaan ominaisuus. Prosessori toimii softan näkökulmasta täysin kuin sen pitäisi.

Ja se että AMD on tälle immuuni, kyse lienee enemmän siitä että AMDllä kävi hyvä tuuri, ettei AMD ehtinyt toteuttaa yhtä aggressiivista muistioperaatioiden uudelleenjärjestelyä tai spekulatiivista suoritusta, ei siitä että AMD olisi osannut ja Intel olisi mokannut; Tämä vaikuttaa jutulta johon KUKAAN ei tietoisesti osannut varautua.



Side-channel-haavoittuvuudesta:

Kyseessä on vähän saman tason juttu, kuin että naapurisi on perustanut leipomon, joka tekee uusia todella hyvänmakuisia kakkuja, ja sinä haluat vakoilla, mitä ainesosia siinä reseptissä on. Naapurisi on kuitenkin huolehtinut tietoturvastaan, etkä pääse sitä mitenkään suoraan vakoilemaan.

Huomaat kuitenkin, että lähikauppasi (joka ei suoraan suostu kertomaan, mitä muille asiakkaille myy) on suurentanut selvästi hyllyään, jossa säilöö kardemummaa, ja kardemumma on kaupasta aina joko lopussa, tai sitä on kaupassa todella paljon, hyvin tuoreella päivämäärällä.

Tästä voi päätellä, että kardemumman kulutus kaupassa on kasvanut selvästi, ja naapurisi salaisessa reseptissä käytetään kardemummaa.

 

[Cirrus]

Lähdekoodia tyyppi ei vielä julkaissut.

Mielenkiintoinen yksityiskohta on sanat "no page faults required".

spekulaatiota:

Voi olla että "no page faults required" on toteutettu sillä, että muistiaccessi kiellettyyn osoitteeseen tehdään väärin ennustetussa haarautumisessa, eli siis if-blokissa jonne koodin ei pitäisi mennä. Tämä todennäköisesti taas tarkoittaa, että koodissa pitää nähdä jonkin verran vaivaa sen haarautumisenennustuksen huijaamiseen

Spekulaatiosi kaltainen hyökkäys kuvailtiin juuri jossakin analyysissä.

Ja myöhempään kommenttiisi, että amd on turvallinen vahingossa.

Kyllä nyt olet väärässä. Amd nimenomaisesti ilmoitti että myös spekuloduissa referensseissä amd on estänyt alemman tason oikeudet omaavan koodin accessin ylemmän tason dataan.

 

[mRkukov]

Linuxillahan käsittääkseni sama suorituskykyhitti tuli myös MADin laskimille kernelikorjauksen jälkeen. Onko jo tiedossa, että miten Windows hoitaa homman? Kärsiikö myös MAD nuo samat laskut suorituskyvyssä?

Tuli, mutta AMD korjasi virheen nopeasti. Eli todellisuudessa ei tullut.
Eiköhän sama käy winkkarin puolella. Intel yrittää pakottaa korjauksensa kaikkiin, mutta AMD ei halua sitä omille prossuilleen kun se on turhaa.

Amd nimenomaisesti ilmoitti että edes spekuloduissa referensseissä amd on estänyt alemman tason oikeudet omaavan koodin accessin ylemmän tason dataan.

Toivotaan että tämä myös pitää paikkaansa.

 

[miiksu]

Lasket täysin rikkinäisillä luvuilla.

Peleillä se hidastuvuus on keskimäärin luokkaa 0.5%, ei 5-30%.


5% tuli Linusilta keskimääräisillä softankehittäjän linux-workloadeilla, jotka on eri asioita kuin windows-pelaajan workloadit.

30% taas oli worst-case real-world-softa joka teki erittäin paljon kernel-kutsuja, mutta teki silti jotain järkevää, eikä pelkkiä kernel-kutsuja kernel-kutsujen ilosta.

Entäs sellaset pelit jotka lukee tyyliin kaiken kiintolevyiltä? The Secret World sellanen että jos magneettikiekolta koittaa pelaa niin peli lagaa niin tajuttomasti.

 

[Fenotype]

Perse, eikö enää voi sanoa kuinka intelin prosessoreissa on fyysinen tietoturva haavoittuvuus, kun se on nyt koko maailman tiedossa. Tosin ei kukaan uskonut aiemminkaan ja hullun maine tuli nopiaan.

50-70MB/s lukunopeuden hidastuminen näyttää uskomattomalta, pakko olla kyllä joku virhe..

 

[jive]

Side-channel-haavoittuvuus ei ole bugi, vaan ominaisuus. Prosessori toimii softan näkökulmasta täysin kuin sen pitäisi.

Ja se että AMD on tälle immuuni, kyse lienee enemmän siitä että AMDllä kävi hyvä tuuri, ettei AMD ehtinyt toteuttaa yhtä aggressiivista muistioperaatioiden uudelleenjärjestelyä tai spekulatiivista suoritusta, ei siitä että AMD olisi osannut ja Intel olisi mokannut; Tämä vaikuttaa jutulta johon KUKAAN ei tietoisesti osannut varautua.

Side channel hyökkäyksen määritelmästä olen liki samaa mieltä, mutta tässä on kyllä kyse zero-day exploitin kaltaisesta asiasta. Joko Intelin insinöörit ovat puusilmiä, mitä en usko, tai sitten todennäköisemmin kyseessä on ollut tietoinen tehokkuusoptimointi.

Räpylä pystyyn kuka oikeasti tekee koodissa input-validoinnin aina ja kaikkialla vaikka siitä kriittisellä polulla tulisikin lisää viipeitä koodiin?

 

[hkultala]

Spekulaatiosi kaltainen hyökkäys kuvailtiin juuri jossakin analyysissä.

Ja myöhempään kommenttiisi, että amd on turvallinen vahingossa.

Kyllä nyt olet väärässä. Amd nimenomaisesti ilmoitti että myös spekuloduissa referensseissä amd on estänyt alemman tason oikeudet omaavan koodin accessin ylemmän tason dataan.

Kyllä se intelilläkin on estetty.

Se estäminen vaan on tehty viivästetysti siten, että se rikkinäisen muistiaccessin sisältävä käsky nostaa poikkeuksen, jolloin tulosta ei koskaan tallenneta mihinkään arkkitehtuurillisesti näkyvään rekisteriin, kun se laittoman muistiaccessin tehnyt käsky eikä mikään sen jälkeen tuleva käsky ei koskaan valmistu.

Ja sitä poikkeusta ei saa laukaista heti, vaan kaikki alkuperäisessä koodissa sitä ennen olevat käskyt pitää ensin suorittaa loppuun, ja poikkeus laukeaa vasta kun ne on suoritettu(ja valmistuneet), koska koodin pitää toimia täysin samalla kuin liukuhihnoittamaton, käskyjä uudelleenjärjestelemätön prosessori sen suorittaisi.


Side channel-hyökkäykset vaan ovat kieroja, niillä pystytään exploittaamaan täysin määritelmän mukaisesti toimivia suorituskykyoptimoituja järjestelmiä, jotka pyrkivät aina toimimaan tilanteeseen nähden optimaalisella tavalla, kun mitataan mikä se suorituskyky oli ja siitä aletaan päättelemään, että mikä se tilanne oli.


Mutta joo, onhan se mahdollista että se laittoman osoitteen sisältävä latauskäsky AMDllä abortataan jo heti suoritusvaiheessa. Pidän tätä kuitenkin epätodennäköisenä, koska se tarkoittaisi sitä, että prosessorin pitäisi samalla sekä heti suoritusvaiheessa abortoida se latauskäsky(ja insertoida jotain roskaa tai joku hautakuvimarkkeri sen tulokseksi), että kuitenkin laukaista se sen aiheuttama poikkeus vasta viivästetysti myöhemmin kun on sen käskyn valmistumisen aika.

 

[hkultala]

Side channel hyökkäyksen määritelmästä olen liki samaa mieltä, mutta tässä on kyllä kyse zero-day exploitin kaltaisesta asiasta.

Tämä on kylläkin nimenomaan ~40-day exploit eikä zero-day exploit. Tämä on tullut intelin, microsoftin ja linux-kehittäjien tietoon jo marraskuussa, ja vahvaa spekulaatiota siitä, mistä tässä on kyse on tullut julkiseksi vasta vuodenvaihteessa.

Joko Intelin insinöörit ovat puusilmiä, mitä en usko, tai sitten todennäköisemmin kyseessä on ollut tietoinen tehokkuusoptimointi.

Ei, se että suunnittelee järjestelmän joka on altis täysin uudentyyppiselle side channel -hyökkäykselle ei ole mitään puusilmäisyyttä.

Puusilmäisyyttä intelillä on se, että ne laittavat prosessoriinsa tietoisesti backdoorin(AMT) (josta sitten löytyi jo yksi paha tietoturva-aukko), mutta sillä taas ei tämän kanssa ole mitään tekemistä

 

[jive]

Linuxillahan käsittääkseni sama suorituskykyhitti tuli myös MADin laskimille kernelikorjauksen jälkeen.

Juu koska ensireaktio oli pakottaa PTI päälle kaikille x86 arch prossuille. Myöhemmin joku laittoi julkiseksi patchin jossa ehtoa muokattiin siten että PTI pakotettiin päälle vain jos x86 suoritin ei ollut AMD:n valmistama.

 

[jive]

Ei, se että suunnittelee järjestelmän joka on altis täysin uudentyyppiselle side channel -hyökkäykselle ei ole mitään puusilmäisyyttä.

Sen mitä olen asiasta lueskellut verkosta vaikuttaa että Intel on tietoisesti skipannut yhden trust boundaryn vahtimisen koska se vaatisi ylimääräistä prosessointia ja näytti siltä että boundaryn rikkominen ei ollut päätöstä tehtäessä mahdollista. Noh jos tarkistukset olisi toteutettu joka tapauksessa niin se että joku myöhemmin onkin löytänyt tavan injektoida hyökkäyskoodia rajalle ei olisi aiheuttanut loppupeleissä mitään fataalia.

SCAt mielestäni ovat aina haavoittuvuuksia, joissa käytetään hyväksi varsinaisen ilmiön sivuvaikutuksia, kuten hyvin tuossa leipurianalogiassa esitit. Tämä haavoittuvuuden hyödyntäminen ei kuitenkaan vaadi mitään muuta kuin koodia eikä siksi mielestäni kelpaa sivukanavahyökkäykseksi.

 

[hkultala]

Sen mitä olen asiasta lueskellut verkosta vaikuttaa että Intel on tietoisesti skipannut yhden trust boundaryn vahtimisen koska se vaatisi ylimääräistä prosessointia ja näytti siltä että boundaryn rikkominen ei ollut päätöstä tehtäessä mahdollista.

Noh jos tarkistukset olisi toteutettu joka tapauksessa niin se että joku myöhemmin onkin löytänyt tavan injektoida hyökkäyskoodia rajalle ei olisi aiheuttanut loppupeleissä mitään fataalia.

Ei, se tarkastus kyllä tehdään. Prosessori heittää aina poikkeuksen ennen kuin se laittomasti ladattu data ilmestyy arkkitehtuurillisesti näkyviin, eli se ei koskaan voi ilmestyä arkkitehtuurillisesti näkyviin.

Mutta siihen tarkistuksen tulokseen reagoidaan liian myöhään, koska sen datan perusteella välimuisti voi pollutoitua(eri tavalla riippuen siitä, mitä se data oli) ja SCAlla siitä välimuistin pollutoitumisesta voidaan päätellä asioita.

SCAt mielestäni ovat aina haavoittuvuuksia, joissa käytetään hyväksi varsinaisen ilmiön sivuvaikutuksia, kuten hyvin tuossa leipurianalogiassa esitit.

Kyllä

Tämä haavoittuvuuden hyödyntäminen ei kuitenkaan vaadi mitään muuta kuin koodia eikä siksi mielestäni kelpaa sivukanavahyökkäykseksi.

Tässä määritelmäsi SCAsta on väärä. Kyllä ne monet aiemmatkin SCAt on ihan ohjelmakoodilla exploitattavissa, eikä tämä sen suhteen eroa niistä mitenkään. Itse asiassa jotkut aiemmat SCAt perustuvat siinä mielessä samaan mekanismiini, että niissäkin profiloidaan latauskäskyjä ja sen perusteella päätellään, mitä välimuistista löytyy. Niissä vaan hyökkäyksen toimintamekanismi on muuten ollut hyvin erilainen, niissä on vakoiltu esim. toista samalla ytimellä ajettavaa säiettä yhteisen välimuistin käytöksen perusteella.

Ja tässä exploitissa se laittomasti ladattu data ei koskaan ole käytettävissä/havaittavissa millään suoralla arkkitehtuurillisella keinolla.

Siihen pääsee käsiksi ainoastaan mittaamalla muiden latauskäskyjen suoritusaikaa ja päättelemällä sen perusteella, mihin osoitteita prosessorin välimuisti sisältää. Tämä on nimenomaan SCA.

 

[hkultala]

Oikein toimivalla ajoympäristöllä Javascriptillä on mahdotonta saada aikaan muistiviittausta, joka viittaa osoitteeseen, jossa ei ole mitään ohjelman dataa koskaan ollutkaan.
Eli jos tässä on kyse tuosta spekuloidusta latauksesta kernelin muistiosoitteeseen, tätä on mahdotonta hyödyntää javascriptin kautta.

Olin väärässä tästä.

Javascriptissä voi osoittaa taulukon yli, ja prosessori voi spekulatiivisesti suorittaa sitä latauskoodia ennen kuin se taulukon kokotarkastus laukeaa.

Tämän exploitin hyödyntäminen javascriptistä on kuitenkin todella paljon vaikeampaa kuin Cstä+assemblystä koska javascriptissä ei oikein pääse suoraan osoitteisiin käsiksi, eikä muutenkaan pysty kontrolloimaan niin tarkasti sitä koodia että osaa virittää sille sopivan ajoituksen.

 

[Cirrus]

En ole nyt ollenkaan vakuuttunut että kyseessä oleva haavoittuvuus on vain side channel tyyppisellä attackilla hyödynnettävissä. Registerin eilisessä analyysissä erästä toista sca:taan tehtyä patchityyppiä sanottiin käytettävän tämänkin torjuntaan, mutta silti tät arveltiin pahemmaksi.

@hkultala olet nyt siis satavarma että tässä virheessä data ei näy suoraan?

 

[Teuras]

Voi pojat, kun nyt olisi menossa centerin päivitys ja laite tilaukset sisällä

Uskoisin hien nousevan pintaan sen normaalin %- päivityksen vaihtuessa ja nykyisen kokoonpanon suorituskyvyn häviävän samaan aikaan...

 

[hkultala]

En ole nyt ollenkaan vakuuttunut että kyseessä oleva haavoittuvuus on vain side channel tyyppisellä attackilla hyödynnettävissä. Registerin eilisessä analyysissä erästä toista sca:taan tehtyä patchityyppiä sanottiin käytettävän tämänkin torjuntaan, mutta silti tät arveltiin pahemmaksi.

@hkultala olet nyt siis satavarma että tässä virheessä data ei näy suoraan?

En satavarma, mutta melko varma. Se tiedetään käytännössä varmasti, että tämä koodi liittyy spekulatiiviseen suoritukseen.

Ja ei sillä spekulatiivisesti suoritetulla datalla oikein ole mitään "virallista" reittiä tulla arkkitehtuurillisesti näkyville, koska spekulatiivisen suorituksen pointti on, että jos sitä ei pitänytkään suorittaa, se perutaan. Ja näitä on kyllä testattu perusteellisesti, ja ties mitkä softat olisi jo buganneet pahasti jos se spekulatiivisen suorituksen seurauksena syntynyt data olisikin näkyvissä jossain (siellä aiemmin olleen datan sijasta).

Eli sillä laittomasti ladatulla datalla ei siis yksinkertaisesti ole mitään mahdollista/laillista arkkitehtuurillisesti näkyvää paikkaa minne mennä(koska kaikkialla se ylikirjoittaisi jonkun sinne kuuluvan muun datan), joten ainoa keino päästä siihen käsiksi on arkkitehtuurillisen tilan ulkopuolelta, SCAlla.

 

[Smanci]

Tekee tämä bugi muuten helvetin hyvää Braswell-celeronilla pyörivälle kympille

 

[runboy93]

Tekee tämä bugi muuten helvetin hyvää Braswell-celeronilla pyörivälle kympille

Tekee aika hallaa kaikille näille low power prossuille, apollo lake yms, ja uusi gemini lake myös.

 

[hkultala]

Kyseessä on valmistusvirhe, joka ei käytännössä vanhene koskaan, eikä prosessori täytä enää sille myydessä luvattuja arvoja.

Täyttääpäs.

Se suorittaa jokaisen käskyn aivan kuin sen käskyn spesifikaatio sanoo, tasan siinä ajassa kuin mitä sen spesifikaatio sanoo. (*)

Tämä ei ole bugi, tämä on feature.



(*) todellisuudessa joissain käskyissä on kyllä bugeja, mutta niillä bugeilla ei tämän exploitin kanssa ole mitään tekemistä.

 

[Cirrus]

En satavarma, mutta melko varma. Se tiedetään käytännössä varmasti, että tämä koodi liittyy spekulatiiviseen suoritukseen.

Ja ei sillä spekulatiivisesti suoritetulla datalla oikein ole mitään "virallista" reittiä tulla arkkitehtuurillisesti näkyville, koska spekulatiivisen suorituksen pointti on, että jos sitä ei pitänytkään suorittaa, se perutaan. Ja näitä on kyllä testattu perusteellisesti, ja ties mitkä softat olisi jo buganneet pahasti jos se spekulatiivisen suorituksen seurauksena syntynyt data olisikin näkyvissä jossain (siellä aiemmin olleen datan sijasta).

Eli sillä laittomasti ladatulla datalla ei siis yksinkertaisesti ole mitään mahdollista/laillista arkkitehtuurillisesti näkyvää paikkaa minne mennä(koska kaikkialla se ylikirjoittaisi jonkun sinne kuuluvan muun datan), joten ainoa keino päästä siihen käsiksi on arkkitehtuurillisen tilan ulkopuolelta, SCAlla.

Seuraava on mihinkään perustumatonta jorinaa:
Onko asiaa pakko lähestyä noin ”monimutkaisesti”?
Jospa oikeuksien tason tarkistuksen saa menemään sekaisin tuolla spekulatiivisellä kikkailulla ja tämän jälkeen muuta kernel-tason dataa avautuu näkyviin?

 

[Elvis Jagger]

Juu koska ensireaktio oli pakottaa PTI päälle kaikille x86 arch prossuille. Myöhemmin joku laittoi julkiseksi patchin jossa ehtoa muokattiin siten että PTI pakotettiin päälle vain jos x86 suoritin ei ollut AMD:n valmistama.

Mutta hyväksyttiinkö se patchin patchi jo?
Edit: Linux Will End Up Disabling x86 PTI For AMD Processors - Phoronix

 

[Cirrus]

Jos prossu hidastuu valmistusvian korvaavan paikkauksen takia, niin kyllähän se silloin on viallinen tuote ollut jo myydessä.

Kyseessä ei ole valmistusvika jos koskaan kukaan ei ole väittänytkään että vehje toimisi jotenkin muuten. Se että softavalmistajat haluavat tehdä tuotteistaan entistä tietoturvallisempia ei ole rautavika.

 

[hkultala]

Seuraava on mihinkään perustumatonta jorinaa:
Onko asiaa pakko lähestyä noin ”monimutkaisesti”?

Tuo on nimenomaan yksinkertainen selitys, joka tulee suoraan siitä, miten nykyaikaisen prosessorin spekulatiivinen suoritus toimii.

Jospa oikeuksien tason tarkistuksen saa menemään sekaisin tuolla spekulatiivisellä kikkailulla ja tämän jälkeen datat avautuu näkyviin?

Äärimmäisen epätodennäköistä.

Ne suojausbitit on ensin muistissa olevissa sivutauluissa, joista ne ladataan TLBhen.

Ei siellä oikein ole mitään syytä olla sellaista keinoa millä ne virtuaalisivun suojausbitit voisi sen latausvaiheen aikana selektiivisesti korruptoida. Sivutaulu-entry ladataan TLBhen aina sellaisenaan.

Ja jos koko prosessorin tila korruptoituisi pois user-tilasta kernel-tilaan.. se olisi VARMASTI huomattu jo aikapäiviä sitten prosessorin ensimmäisissä testeissä firman sisällä, nämä on niin oleellisia juttuja että ne on kyllä testattu perusteellisesti.

Eli se "yksinkertainen vaihtoehtosi" on todellisuudessa vaatisi prosessoriin paljon enemmän monimutkaisuutta, rakenteen jonka olemassaoloon ei ole mitään syytä tai järkeä.

 

[potaatti55]

Tämmöistä laittoivat Inteliltä: Intel Responds to Security Research Findings

 

[jsa]

Hohhoijjaa tota intelin "ulostuloa". Odottavan on pitkä...

 

[hkultala]

Jos prossu hidastuu valmistusvian korvaavan paikkauksen takia, niin kyllähän se silloin on viallinen tuote ollut jo myydessä.

Edelleen: Ei siinä ole mitään valmistusvikaa. Se toimii täysin speksien mukaan.

Jos haluat vetää autovertauksen, niin pikemminkin kyse on siitä, että ilkivalta autoja kohtaan lisääntyy, teineille tulee muotiin heitellä autoja nyrkinkokoisilla kivillä, ja tämän johdosta autoihin päätetään jälkikäteen asentaa vahvemmat lasit jotta ne kestää sellaisten kivien osumat, joita auton laseja ei alunperin suunniteltu kestämään. Nämä vahvemmat lasit kuitenkin painavat enemmän minkä takia auton kiihtyvyys hidastuu parin prosentin verran, tehon ja huippunopeuden säilyessä ennallaan.

 

[Kapteeni_kuolio]

No mutta, hyvää syy päivittää 8700k tulevaan 8-core malliin ja z390 alustaan, sinä lienee korjattu ns. rautatasolla! Olin jo pähkäilly et millä sen oikeuttas itselleen, ei tartte enää murehtia, kätevää!

 

[Sami Riitaoja]

Piti regata kun on sen verran mielenkiintoinen bugi.

Eli Intelin prossut vuotaa kuin seula, ongelmana on että spekulatiivinen luenta tehdään tarkistamatta oikeuksia, tästä on varmasti selvää nopeushyötyä/virransäästöä.

Eli homma tehdään antamalla prosessorille mahdollisuus tehdä spekulatiivinen luku kerneliosoitteesta(joka kait saadaan TLB:stä side-channel hyökkäyksellä) ja sen perään vaikka add:tään ko. spekulatiivisen käskyn tulos userspacessa olevaan osoitteeseen, ja tulos saadaan noilla side-channel luvuilla luettua userspacen cachesta vaikka tulos ei ikinä varsinaisesti mihinkään näykään. Eli koko kerneli on luettavissa. Korjaushan on pilkkoa kerneli satunnaisiin osoitteisiin ja tyhjennellä TLB usermoodin ohjelmia ajettaessa, ISO kysymys on että kun prosessorissa on noin rankka haavoittuvuus päästäänkö silti ketjussa takaisinpäin jollain keinolla, ja jos päästään niin Intelillä on todella paljon suurempi ongelma kuin pieni hidastuminen.

 

[Cirrus]

Äärimmäisen epätodennäköistä.

No the register viittasi (taisi olla täällä just se) pociin ja väitti nähneensä toisen pocin, jolla voi lukea tai joka leakkaa kernel dataa userille.

 

[FireFly Renaissance]

Edelleen: Ei siinä ole mitään valmistusvikaa. Se toimii täysin speksien mukaan.

Jos haluat vetää autovertauksen, niin pikemminkin kyse on siitä, että ilkivalta autoja kohtaan lisääntyy, teineille tulee muotiin heitellä autoja nyrkinkokoisilla kivillä, ja tämän johdosta autoihin päätetään jälkikäteen asentaa vahvemmat lasit jotta ne kestää sellaisten kivien osumat, joita auton laseja ei alunperin suunniteltu kestämään. Nämä vahvemmat lasit kuitenkin painavat enemmän minkä takia auton kiihtyvyys hidastuu parin prosentin verran, tehon ja huippunopeuden säilyessä ennallaan.

No valmistusvika ei joo ole kyseessä, mutta suunnitteluvirhe on.

Jos turvatyynyt ei laukea kolarissa (tarvittaessa) niin kyllä se silloin on suunnitteluvirhe, vaikka ne jossain toisessa kolarissa laukeisivatkin.