Oikein toimivalla ajoympäristöllä Javascriptillä on mahdotonta saada aikaan muistiviittausta, joka viittaa osoitteeseen, jossa ei ole mitään ohjelman dataa koskaan ollutkaan.
Kyllä tällä tulee olemaan myös pitempiaikaisiakin vaikutuksia suursijoittajien silmissä:
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.
Lasket täysin rikkinäisillä luvuilla.
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.
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ä)
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.
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.
Myös VM maailmassa? Myönnettäköön etten aihetta kauhean hyvin tunne.
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.
Jos kyse on side-channel-hyökkäyksestä, niin ei.dakyy sanoi:
Spekulaatiosi kaltainen hyökkäys kuvailtiin juuri jossakin analyysissä.
Tuli, mutta AMD korjasi virheen nopeasti. Eli todellisuudessa ei tullut.
Toivotaan että tämä myös pitää paikkaansa.
Entäs sellaset pelit jotka lukee tyyliin kaiken kiintolevyiltä? The Secret World sellanen että jos magneettikiekolta koittaa pelaa niin peli lagaa niin tajuttomasti.
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.
Kyllä se intelilläkin on estetty.
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.
Ei, se että suunnittelee järjestelmän joka on altis täysin uudentyyppiselle side channel -hyökkäykselle ei ole mitään puusilmäisyyttä.jive sanoi:
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.
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.
Kylläjive sanoi:
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.jive sanoi:
Olin väärässä tästä.
En satavarma, mutta melko varma. Se tiedetään käytännössä varmasti, että tämä koodi liittyy spekulatiiviseen suoritukseen.
Tekee aika hallaa kaikille näille low power prossuille, apollo lake yms, ja uusi gemini lake myös.Tekee tämä bugi muuten helvetin hyvää Braswell-celeronilla pyörivälle kympille
Täyttääpäs.
Seuraava on mihinkään perustumatonta jorinaa:
Mutta hyväksyttiinkö se patchin patchi jo?
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.
Tuo on nimenomaan yksinkertainen selitys, joka tulee suoraan siitä, miten nykyaikaisen prosessorin spekulatiivinen suoritus toimii.
Äärimmäisen epätodennäköistä.
Edelleen: Ei siinä ole mitään valmistusvikaa. Se toimii täysin speksien mukaan.
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.
No valmistusvika ei joo ole kyseessä, mutta suunnitteluvirhe on.
