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

[leripe]

Suoritinhaavoittuvuutta hyödyntävien haittaohjelmien määrä räjähti, ainakin 130 näytettä löydetty



Mukava tässä surffailla koneella, jossa tietää ongelman olevan. :/

Jokos intel on julkaissut korjaukset kaatuiluihin kaikilla prossuilla?
Muutoinhan noita biosseja yms ei voi edes päivittää ja nyt ollaan sitten uhille alttiita..

 

[Griffin]

Suoritinhaavoittuvuutta hyödyntävien haittaohjelmien määrä räjähti, ainakin 130 näytettä löydetty



Mukava tässä surffailla koneella, jossa tietää ongelman olevan. :/

Mikäs siinä on ongelmana, kunhan ei ajele mitään epämääräisiä softia koneella? ... Pistää javan pois, jos epäilee sen vuotavan jotain..

Muutenkin tuollahan muistinluku on ainankin hidasta ja vie paljon prossutehoa, melko epäkätevää siis tonkia mitään...
Project Zero: Reading privileged memory with a side-channel

 

[mRkukov]

Mikäs siinä on ongelmana, kunhan ei ajele mitään epämääräisiä softia koneella? ... Pistää javan pois, jos epäilee sen vuotavan jotain..

Javan? Kuka nyt Javaa mihinkään käyttäisi.

Javascriptiä taas huono disabloida kun puoli nettiä lopettaa toiminnan. Olihan youtubessakin jo mining scriptiä mainoksissa. Miksei tätä voisi olla? Vaikea suojautua ja kyllä esim nettisivujen passut kelpaa hakkereille.

 

[Zacksa]

Olihan youtubessakin jo mining scriptiä mainoksissa.

Jotain lähdettä tälle?

 

[Griffin]

Javan? Kuka nyt Javaa mihinkään käyttäisi.

Javascriptiä taas huono disabloida kun puoli nettiä lopettaa toiminnan. Olihan youtubessakin jo mining scriptiä mainoksissa. Miksei tätä voisi olla? Vaikea suojautua ja kyllä esim nettisivujen passut kelpaa hakkereille.

Eikös selainten sciptienginet ole sabotoitu nykyisin ihan erikseen selainten päivityksissä s.e. ei tahdo ajastukset onnistua, eli lukeminen on muuttunut erittäin hitaasta mahdottomaksi tuota kautta.

Muutenkin, kun selaimen prosessi vie jotain 100 000K - 300 000 K, ja ei edes tiedä oikein, mitä sieltä etsiä, niin melko hidasta ja toivotonta sieltä on mitään oikeasti löytää, kuin lähinnä vahingossa.

 

[mRkukov]

Eikös selainten sciptienginet ole sabotoitu nykyisin ihan erikseen selainten päivityksissä s.e. ei tahdo ajastukset onnistua, eli lukeminen on muuttunut erittäin hitaasta mahdottomaksi tuota kautta.

Muutenkin, kun selaimen prosessi vie jotain 100 000K - 300 000 K, ja ei edes tiedä oikein, mitä sieltä etsiä, niin melko hidasta ja toivotonta sieltä on mitään oikeasti löytää, kuin lähinnä vahingossa.

Kyllä, mutta jos bittimikroon on uskominen niin:

Lisäksi Av-test havaitsi ensimmäisen JavaScript-pohjaisen proof-of-concept-hyökkäyskoodin Spectre-haavoittuvuuteen.

Jos on proof-of-concept olemassa niin ei kauaa mene että siitä tehdään myös oikeita haitakkeita. Jos se kerran toimii, niin kyllä sitä tullaan käyttämään. Rikollisia ei kiinnosta joutuuko se käyttäjän kone jauhamaan 10min yhtä salasanaa. Jos se on ongittavissa, se on ongittavissa. Tehdään vaikka javascript joka aktivoituu vasta 5min jälkeen, eli silloin kun käyttäjä on jättänyt sivun auki ja lähtenyt hakemaan kahvia. Takaisin tullessa scripti on ehtinyt jautaa ne pari passua ja lähettänyt ne hökkääjälle. Käyttäjä refreshaa sivun ja "jumissa ollut" sivu alkoi taas toimia oikein ja koneen tuuletinkin rauhottui. Asia jää sikseen ja salasanat/tunnukset/muut vuotaneet maailmalle ilman mitään merkintöjä mihinkään logiin. Sehän näissä pelottaa, ettei noista jää mitään jälkeä koneelle.

 

[Kerosiini]

Jotain lähdettä tälle?

Coinhive Cryptojacker Deployed on YouTube via Google Ads

 

[Griffin]

Kyllä, mutta jos bittimikroon on uskominen niin:


Jos on proof-of-concept olemassa niin ei kauaa mene että siitä tehdään myös oikeita haitakkeita. Jos se kerran toimii, niin kyllä sitä tullaan käyttämään. Rikollisia ei kiinnosta joutuuko se käyttäjän kone jauhamaan 10min yhtä salasanaa. Jos se on ongittavissa, se on ongittavissa. Tehdään vaikka javascript joka aktivoituu vasta 5min jälkeen, eli silloin kun käyttäjä on jättänyt sivun auki ja lähtenyt hakemaan kahvia. Takaisin tullessa scripti on ehtinyt jautaa ne pari passua ja lähettänyt ne hökkääjälle. Käyttäjä refreshaa sivun ja "jumissa ollut" sivu alkoi taas toimia oikein ja koneen tuuletinkin rauhottui. Asia jää sikseen ja salasanat/tunnukset/muut vuotaneet maailmalle ilman mitään merkintöjä mihinkään logiin. Sehän näissä pelottaa, ettei noista jää mitään jälkeä koneelle.

Muistaakseni sanottiin jotain, että kalibrointiin menee ei javascriptiversiolla ensin se 10-30 minuuttia ja senjälkeen onnistuu "lukeminen" melko surkealla nopeudella. Joku variannti oli muistaakseni käytössä " heti, mutta jos etsittävä alue on esim 50 000 kt (puolet selaimen yleensä syömästä muistista) ja nopeus on 2 kt /s, niin aikaa vierähtää 12500s, ennen kuin puolet alueesta on tutkittu, joka on noin 3, 5 tuntia. Tiedä sitten sietääkö käyttäjä hirttävää konetta edes tuon aikaa..
Jos selain järjestelisi muistinsa uudestaan esim kerran /10 minuuttia, niin tuolla olisi melkoisen toivotonta etsiä tasan mitään sieltä... Tuo on vain ihan liian hidasta, nykyisillä tietomäärillä.

Lisäksi kun se muisti on täynnä kaikenlaista paskaa, niin mistä sen tietää, mikä siellä on se salasana? Ei siellä ole mitenkään välttämättä tiettyjä merkkejä edes ennen sitä salasanaa. Tietysti joku salasanavaulttisofta / selaimen salasanamuisti, jos sitä käyttää, voi olla tuolle altis.

Todennäköisesti paljon helpommin saa sen salasanan huijaamalla sitä käyttäjää esim oikeannäköisellä loginilla väärässä paikassa..
-------------------------
Oikea uhka tuo on järjestelmille, joissa asiakas pyörittää virtuaalikoneessa softaa, kun tuolla pääsee isännän ja muiden asiakkaiden dataan käsiksi.. Lisäksi voisi kuvitella, jotta tuolla voisi ehkä lukea softista suojattuja avaimia, ne kun voivat möhöttää sillä muistissa, kun vain se haluttu softa on päällä, jos suojaus on tehty laiskasti. Jos taas suojaus decryptaa itsensä vain välillä muutamaksi kymmeneksi nanosekunniksi, niin ei tuolla mitään suoraan käyttökelpoista irtoa irtoa, vaan joutuu debuggailemaan lisäksi mahdollisesti ankarastikin..

 

[Griffin]

Coinhive Cryptojacker Deployed on YouTube via Google Ads

Mainoksethan tulee ihan oletuksena blokata, kun ne sisältävät milloin mitäkin haitaketta ym. Muutoinkin aiheuttavat nykyisin huomattavaa prossukuormaa ja netinkäyttöä VAIKKA sattuisivat olemaan "puhtaita". Valitettavasti on menty siihen, että haitallisuutensa takia mainoksien blokkauksesta on tullut tärkeämpi edellytys, kuin esim jostain viruskilleristä.

 

[Kizmo]

Puhumattakaan salasanoja mielenkiintoisemmista saaliista eli vaikka kohdennettu hyökkäys kryptolompakko ohjelmistoja vastaan.

 

[jukeb0xi]

Hiljaista ollut korjausten suhteen, mutta nyt ilmeisesti Skylake-prossuille saatu valmiiksi hiotumpi päivitys mikrokoodiin, joka on jaettu nyt laitevalmistajille. Muut arkkitehtuurit saavat vielä odotella omaansa.

Intel releases new Spectre microcode update for Skylake; other chips remain in beta

 

[Sami Riitaoja]

Juuri selitin, bugien kiertämiseksi ja testaamisen helpottamiseksi KAIKESTA tehdään sellaista että sen saa pois päältä tai flushattua.
Yksi reset-signaali ja yksi disable-signaali per asia.

Ja SINÄ nimenomaan efektiivisesti väitit että sen sisäiseen taulukoihin voisi päästä käsiksi, kun rupesit höpöttämään mutupaskaa siitä että niitä flushattaiisiin yksi kerrallaan tuhansien käskyjen ajan. Sekä edellisessä viestissäsi että tuossa alla.

Hienoa logiikkaa, samassa viestissä sekä väität että jotain tehdään jollain tavalla että kiistät sen rajapinnan olemisen, millä sen voi tehdä

Noinkohan olen kertonut. Toki kaiken saa päältä ja pois, mutta prosessorin initissä, ei ajossa olevasta kivestä. BTB-taulu on vaan branch-prediction yksiköiden taulukkoja jotka nykyprosessoreissa ovat monitasoisisa ja suoria manipulointikäskyjä noihin ei ole, eli jos ne halutaan flushata ajetaan prosessorissa koodinpätkä joka muuttaa noiden taulujen arvot epäkuranteiksi.

... juuri ylempänä selität, että sellaisia käskyjä ei voi olla, joilla tämä koodinpätkä sen tekisi, koska haarautumisyksikkö on erillään datapolusta


Niinkuin oikeasti. Ymmärrän, että et ole opiskellut digitaali- tai tietokonetekniikkaa, etkä oikeasti ymmärrä miten nykyaikaiset prosessorit toimivat, mutta voisitko edes YRITTÄÄ YMMÄRTÄÄ ja voisitko edes YRITTÄÄ OLLA KONSISTENTTI siinä millaiseksi prosessorin rakenteen kuvittelet?

Koodinpätkä on siis jotain ajettavaa koodia joka saa branc-predictorin arvot muuttumaan epäkuranteiksi mahdollisen haavoittuvuuden hyödyntämiseen. Sinun tulkintasi sanomisistani on jotain ihan muuta.

Ja itse aloit höpöttämään kiikuista yms, mikälie aivopieru, tähän asiaan liity millään tavalla.

Nythän on myös tutkittu mitä tuo Intelin buginen mikrokoodipätsi tekee, TDP ylittyy sitä käytettäessä yli 150%:llä josta seuraa epävakaus. Intelillä on erityisen raskaat kiikkujen resetointilinjat käytössä

 

[Sami Riitaoja]

Se poikkeus pitää heittää oikeassa kohdassa, oikean käskyn jälkeen, siten että kaikki sitä ennen tulleet käskyt suoritetaan loppuun asti.
Suoritusvaiheessa käskyt voi olla suorituksessa eri järjestyksessä kuin alkuperäisessä koodissa, joten sitä ei voi tehdä vielä siellä.

Ja laiton lataus (tai muu poikkeus) ei aina tarkoita ohjelman tappamista.

Ohjelmaa saatetaan erimerkiksi ajaa debuggerissa, ja halutaan tarkat tiedot siitä, mikä se laiton käsky on, ja mitä osoitetta se käsittelee, ja suoritusta saatetaan haluta tällöin jopa jatkaa virheen jälkeen virheen analysoimiseksi paremmin.

Spekulatiivisten käskyjen ajo ei näy millään tavalla debuggerissa. Ja spekulatiivinen laiton lataus ei ole mikään syy tappaa ohjelmaa, eikä mikään spekulatiivisen ajon poikkeus pitäisi näkyä ulospäin.

Mutta se mitä siis voisi tehdä on, että heti kun huomataan että nyt tapahtuu jotain laitonta, ei edes lasketa sitä, vaan merkataan sen tuottamalle tulokselle että "laiton arvo" ja jos mitään yritetään laskea siten että joku inputti sisältää tämän markkerin, sitten niidenkin tuloksiksi tulee "laiton arvo". Tämä voi kuitenkin vaatia yhden bitin lisää, joko itse rekisterihin jotka niitä arvoja tallettaa tai johonkin kirjanpitoon.

Jos siis puhutaan meltdownista niin prossulle riittää että kunnioitetaan muistisuojausta, prosessorit jotka eivät näin tee ovat "rikki". Suorastaan edesvastuutonta antaa ylemmän suojaustason lukea alemman dataa missään tilanteessa. Spectre on sitten ongelmallisempi, ensin pitäisi tietää että luetaan ei ohjelmalle kuuluvaa dataa, jos se tiedettäisiin niin prosessorit jotka eivät ole "rikki" eivät ko. ongelmasta kärsisi.

 

[Griffin]

Olisi mielenkiintoista, jos tutkisi, miksi ohjelma on kaatunut ja selityksessä lukisi:
On mahdollista, että ohjelma olisi ehkä myöhemmin lukenut tietoja kielletystä muistiosoitteesta.

 

[hkultala]

Spekulatiivisten käskyjen ajo ei näy millään tavalla debuggerissa.

Ei näykään, enkä ole missään väittänytkään, että näkyisi.

(Tässä puhuttiin ihan normaalisti, eikä spekulatiivisesti suoritetuista käskyistä.)

Ja spekulatiivisesti suoritettu käsky muuttuu efektiivisesti ei-spekulatiivisesti suoritetuksi käskyksi siinä vaiheessa, kun kaikki sitä edeltävät haarautumiskäskyt on resolvattu ja selviää, että tämä käsky todellakin piti suorittaa (tai vaihtoehtoisesti, se tapetaan kun joku edelläolevista haarautumiskäskyistä resolvataan siten että selviää, että haarautumisenennustus on ennustanut väärin, eikä sitä pitänytkään suorittaa). Mutta käskyn varsinaisen arkkitehtuurilliset vaikutukset näkyy vasta siinä vaiheesa, kun käsky retireää.

Ja spekulatiivinen laiton lataus ei ole mikään syy tappaa ohjelmaa, eikä mikään spekulatiivisen ajon poikkeus pitäisi näkyä ulospäin.

Ei niin. Enkä ole niin väittänytkään.

Ja se poikkeus heitetään vasta siellä retire-vaiheessa, eikä sellainen spekulatiivisesti suoritettu käsky, jota ei oikeasti pitäny suoittaa, koskaan pääse sinne retire-vaiheeseen. Vaan se flushataan liukuhihnalta siinä vaiheessa kun se edeltävä väärin ennustettu haarautuminen resolvataan ja haarautumishuti käsitellään.

Mitään "spekulatiivista poikkeuksenheittoa" ei tapahdu.

Mutta hyvä, alat pikku hiljaa oppia jotain.

Jos siis puhutaan meltdownista niin prossulle riittää että kunnioitetaan muistisuojausta, prosessorit jotka eivät näin tee ovat "rikki". Suorastaan edesvastuutonta antaa ylemmän suojaustason lukea alemman dataa missään tilanteessa. Spectre on sitten ongelmallisempi, ensin pitäisi tietää että luetaan ei ohjelmalle kuuluvaa dataa, jos se tiedettäisiin niin prosessorit jotka eivät ole "rikki" eivät ko. ongelmasta kärsisi.

Intelin prosessorit kunnioittavat muistinsuojausta. Muistinsuojauksen speksit sanoo, että yritys lukea laittomasta osoitteesta johtaa siihen, että käsky nostaa poikkeuksen, eikä koskaan tallenna tulostaan arkkitehtuurilliseen tulosrekisteriin. Tämä pitää täysin paikkaansa intelin prosessoreilla.

 

[Sami Riitaoja]

Intelin prosessorit kunnioittavat muistinsuojausta. Muistinsuojauksen speksit sanoo, että yritys lukea laittomasta osoitteesta johtaa siihen, että käsky nostaa poikkeuksen, eikä koskaan tallenna tulostaan arkkitehtuurilliseen tulosrekisteriin. Tämä pitää täysin paikkaansa intelin prosessoreilla.

Mutta nimenomaan tämä on ongelma, näin toimivat prosessorit ovat "rikki". Eli ylemmän tason koodi voi lukea alemman tason muistia ja ko. muisti saadaan näkymään ylemmän tason koodissa. Meltdown, prosessori on rikki muistinsuojauksen osalta. Ihan sama vaikka tottakai tarkoitus on ollut pitää muisti suojattuna, kyseinen toteutus ei vaan toimikaan. Hätäratkaisuna näille prosessoreille sitten on nyt väliaikaisesti(suorituskyvyn kustannuksella) eriytetty käyttöjärjestelmissä kernelin muisti kokonaan ylemmän tason ohjelmista ja generoitu kernelin osoitteet sattumanvaraisiksi mutta se ei poista sitä tosiasiaa että Meltdown-prosessorit eivät ole edes teoriassa turvallisia, vuotaminen on vain tehty vähän haastavammaksi. Kaikista korkean turvallisuuden vaatimista palvelimista pyritään aivan varmasti hävittämään Meltdown-haavoittuvat prossut niin nopeasti kuin suinkin - nyt vain väliaikaispaikkauksilla odotetaan että Intel saa sellaisia tehtyä.

 

[Sami Riitaoja]

Branch target bufferissahan on myös ongelmana että nykyään se toimii myös instruction cachena, eli joissain tapauksissa hyppykäskyn suorittamat käskytkin löytyvät BTB:stä. Nyt kun prosessori on flushannut TLB:nsä itse cachen data on kuitenkin tallessa ja kun spectrellä hyökätään BTB:hen sieltä löytyvät käskyt lukevat datan suoraan cachesta -> jos BTB:tä ei saada flushattua seuraava homma on kirjoittaa koko cachet yli.

 

[hkultala]

Branch target bufferissahan on myös ongelmana että nykyään se toimii myös instruction cachena, eli joissain tapauksissa hyppykäskyn suorittamat käskytkin löytyvät BTB:stä.

Tuota kutsutaan nimellä "branch folding".

Ja se oli lähinnä 1980-luvun lopun ja 1990-luvun RISC-prossujen temppu eikä juuri käytetä enää superskalaarisissa prosessoreissa:

Yksinkertaisissa In-order-prosessoreissa fetchin viivästyminen kellojaksolla tarkoitti sitä, että koko prosessorin liukuhihna hukkasi aina kellojakson. Tämän takia branch foldingia tarvittiin 1980-1990-luvuilla.

Nykyaikaisissa Out-Of-Order-prosesoreissa taas prosesorin etupää menee kaukana suorituksen edellä, ja välissä olevissa puskureissa riittää tyypillisesti hyvin käskyjä suoritettavaksi, se että fetch ei välillä tee mitään kellojakson ajan ei yleensä vielä yhtään hidasta suoritusvaihetta.

Ja jotta säästettäisiin edes kokonainen kellojakso nykyaikaisilla 4 käskyä fetchaavilla prosessoreilla, siellä BTBssä pitäisi sitten olla 4 käskyä, ei vain 1 käsky.

Ja Nykyään tähän on modernimpia ja parempiakin ratkaiuja:

Joissakin nykyaikaisissa prosessoreissa (ainakin Zen) tässä on menty vielä pidemmälle, ja haarautumisenennutimen ja fetchinkin väliin on lisätty puskurit. Haarautumisenennustin laittaa jonoon osoitteita joista fetch hakee käskyjä ja käskynhakuyksikkö hakee näistä osoitteista käskyjä, kun ehtii.


(lisäksi vielä nykyään myös decoden ja renamenkin välissä on vielä puskurit, ja superskalaarisisssa in-order-prosessoreissakin on tyypillisesti jonkinlainen käskypuskuri decoden ja suorituksen välissä, joten niissäkään se branch folding ei säästäisi keskimäärin ainakaan läheskään täyttä kellojaksoa)


Toki nykyaikaisissa prossuissa on myös micro-oppeja säilövä looppipuskuri, mutta se on sitten myös vielä oma lukunsa. Sekin on kuitenkin selvästi eri juttu kuin branch folding.

Nyt kun prosessori on flushannut TLB:nsä itse cachen data on kuitenkin tallessa ja kun spectrellä hyökätään BTB:hen sieltä löytyvät käskyt lukevat datan suoraan cachesta -> jos BTB:tä ei saada flushattua seuraava homma on kirjoittaa koko cachet yli.

Nykyaikaisilla prosssoreilla TLB tagataan, ei flushata context switchin yhteydessä (SMTn toteuttaminen vaatii tätä).

TLBn tagibiteistä nähdään, että nämä entryt ei ole tällä hetkellä/tälle käskylle voimassa, eikä niitä käytetä. Sitten myöhemmin kun prosessorin tila on jälleen vaihtunut, ne entryt on taas voimassa, eikä niitä tarvi uudestaan ladata sivutauluista asti muistista.

Spectren 2.variantin ongelma ei ole BTBssä oleva käsky vaan BTBssä oleva käskyosoite. Siellä on osoite niihin käskyihin, jonka hyökkääjä haluaa suoritettavan. Ja ne käskyt on kernelin luettavissa, koska
A) kerneliin on mäpätty koko user-prosssin muistialue samaan paikkaan. (jos ei olisi, kaikki IO kernel- ja user-tilojen välillä olisi paljon hankalampaa ja hitaampaa).
B) hyökkääjä voi hyväksikäyttää/väärinkäyttää jo kernelin omalla muistialueella olevaa koodia, kun vain tietää sen osoitteen jotenkin.

Ja ratkaisuksi ei tarvi flushata mitään, riittää se, että myös BTB tagataan. Että BTB ei toimisi sellaisten ennustusten mukaan, jotka on "opetettu" eri tilassa kuin missä prosessori nyt on.

AMDllä tilanne spectren 2.variantin suhteen on käsittääkseni se, että kernel-tilassa ei koskaan spekulatiivisesti suoriteta koodia muistista, joka on on määritelty user-tilan muistiksi. Tämäkään ei kuitenkaan suojaa siltä, että kernelin omaan muistiin on saatu se hyökkääjän koodi jotenkin ujutettua, ja hyökkäjä tietää sen osoitteen.

 

[Sami Riitaoja]

Nykyaikaisilla prosssoreilla TLB tagataan, ei flushata context switchin yhteydessä (SMTn toteuttaminen vaatii tätä).

Miksi TLB flushattaisiin normaalisti toimivassa prosessorissa? TLB flush on tällähetkellä käytetty paikka Meltdownista kärsiville prosessoreille jotta kernelidatan sijainti saadaan piilotettua.

TLB taggaus on virtualisointia varten kun pitää käyttää useampia TLB-tauluja, Intelhän nyt hyödyntää em. ominaisuutta TLB ongelmansa kanssa eli ei tarvitse täysiä TLB flusheja kun taggaillaan eri taulut kernelille ja user-modelle - jos prosessori ei olisi "rikki" sitäkään kikkailua ei tarvittaisi.

 

[hkultala]

Miksi TLB flushattaisiin normaalisti toimivassa prosessorissa?

SINÄHÄN tässä alunperin TLBn flushauksesta aloit puhumaan, en minä.

Nyt kun prosessori on flushannut TLB:nsä...

Kontrollirekisterillä CR3 säädellään sitä, mistä prosessorin sivutaulut löytyy.
Jos CR3n arvo muuttuu, myös virtuaalimuistimappaus muuttuu.

Jotta prosessori toimii oikein kun CR3sta muutetaan, TLB pitää joko tagata CR3n arvolla TAI TLB pitää flushata kun CR3n arvo muuttuu.

TLB flush on tällähetkellä käytetty paikka Meltdownista kärsiville prosessoreille jotta kernelidatan sijainti saadaan piilotettua.

Nyt menee syy ja seuraus pahasti sekaisin.

TLBn flushaaminen ei auttaisi yhtään mitään, jos itse sivutauluihin ei kosketa, koska ne muistissa olevat SIVUTAULUT määrittelee sen virtuaalimuistimappauksen. TLB on vain cache sen osoitemuunnoksen tekemiseksi nopeammin, ilman että tarvii jokaista muistiaccessia varten tehdä 4 ylimääräistä muistiaccessia niihin sivutauluihin.

TLB taggaus on virtualisointia varten kun pitää käyttää useampia TLB-tauluja, Intelhän nyt hyödyntää em. ominaisuutta TLB ongelmansa kanssa eli ei tarvitse täysiä TLB flusheja kun taggaillaan eri taulut kernelille ja user-modelle - jos prosessori ei olisi "rikki" sitäkään kikkailua ei tarvittaisi.

Sekoitat nyt sen, mikä on itse korjaus ja mikä on siihen liittyvä lisäominaisuus/optimointi.

Ja se yleisin käyttötarkoitus/pakottavin syy TLBn tagaamiselle on SMT, prosessorilla voi olla yhtä aikaa ajossa monta eri prosessia. Molemmilla pitää olla omat TLB-entrynsä, koska näillä kahdella prosessilla voi olla(tai siis ON!) aivan erilaiset virtuaalimuistimappaukset

 

[Sami Riitaoja]

SINÄHÄN tässä alunperin TLBn flushauksesta aloit puhumaan, en minä.



Kontrollirekisterillä CR3 säädellään sitä, mistä prosessorin sivutaulut löytyy.
Jos CR3n arvo muuttuu, myös virtuaalimuistimappaus muuttuu.

Jotta prosessori toimii oikein kun CR3sta muutetaan, TLB pitää joko tagata CR3n arvolla TAI TLB pitää flushata kun CR3n arvo muuttuu.

No nyt jos puhutaan x86:sta, väitit että context switchissä TLB tagataan tai flushataan. Ei tehdä kumpaakaan, TLB taggaus ei ole x86:ssa edes tuettu (virtualisoinnin ulkopuolella)kuin Intelin Sandy bridgestä eteenpäin eikä sitä ole missään käytetty kun olisi vain hidastanut toimintaa. X86 tarvitsee TLB flushin virtuaalimuistiavaruuden muutoksissa, Kerneli siis lähinnä poikkeustapauksissa ja user-mode prosessin vaihdossa. Muuten vain vaihdellaan toimintatilaa user-moden ja kernel-moden välillä ilman tarvetta TLB:n putsauksiin.

Nyt menee syy ja seuraus pahasti sekaisin.

TLBn flushaaminen ei auttaisi yhtään mitään, jos itse sivutauluihin ei kosketa, koska ne muistissa olevat SIVUTAULUT määrittelee sen virtuaalimuistimappauksen. TLB on vain cache sen osoitemuunnoksen tekemiseksi nopeammin, ilman että tarvii jokaista muistiaccessia varten tehdä 4 ylimääräistä muistiaccessia niihin sivutauluihin.

Intelin ongelma on tällähetkellä että spekulatiivinen koodinsuoritus ei välitä suojaustasoista mitään. Siksi TLB-cachen side-channel hyökkäyksellä saadaan luettua ylemmän tason koodilla alemman tason suojauksen alla olevaa koodia. TLB flush tyhjentää tuon osoitemuunnostaulun ja hyökkäys kuivuu kokoon sen osalta. Meltdown-paikkahan erottaa kernelin omaan muistiavaruuteensa mutta pakkohan se usermoden kuitenkin pitää tarvittava tieto mahdollistamaan kerneliin siirtyminen -> TLB flushataan vielä siiryttäessä kernelin puolelle.

Sekoitat nyt sen, mikä on itse korjaus ja mikä on siihen liittyvä lisäominaisuus/optimointi.

Ja se yleisin käyttötarkoitus/pakottavin syy TLBn tagaamiselle on SMT, prosessorilla voi olla yhtä aikaa ajossa monta eri prosessia. Molemmilla pitää olla omat TLB-entrynsä, koska näillä kahdella prosessilla voi olla(tai siis ON!) aivan erilaiset virtuaalimuistimappaukset

SMT ei vaadi TLB:n tagaamista, eikä x86 mahdollista sitä muutenkaan, muistitauluissa ei ole threaditietoa ollenkaan. TLB ja cachet on prosessorissa jaettu threadien kesken, toki dynaamisesti mutta jaettu kuitenkin.

TLB-taggaus on ollut ainakin kymmenen vuotta x86:ssakin ihan puhtaasti virtualisoinnin takia, ajettaessa useampia kerneleitä TLB-joudutaan flushaamaan aina kernelin vaihdon yhteydessä jos mahdollisuutta ajaa useampaa virtuaalimuistimappausta yhtäaikaa ei ole. Normikäytössä taggaukselle ei ole ollut suorituskyvyn optimoinnin takia tarvetta.

 

[hkultala]

Intelin ongelma on tällähetkellä että spekulatiivinen koodinsuoritus ei välitä suojaustasoista mitään.

Oikeammin, että suojaustarkistuksiin reagoidaan vasta retire-vaiheessa, eikä memory-vaiheessa.

Siksi TLB-cachen side-channel hyökkäyksellä saadaan luettua ylemmän tason koodilla alemman tason suojauksen alla olevaa koodia. TLB flush tyhjentää tuon osoitemuunnostaulun ja hyökkäys kuivuu kokoon sen osalta. Meltdown-paikkahan erottaa kernelin omaan muistiavaruuteensa mutta pakkohan se usermoden kuitenkin pitää tarvittava tieto mahdollistamaan kerneliin siirtyminen -> TLB flushataan vielä siiryttäessä kernelin puolelle.

Edelleenkään millään TLB-flushilla ei ole mitään väliä jos sivutauluista löytyy se data jota niistä ei pitäisi löytyä. TLB on vain välimuisti niille sivutauluille.

Jos niitä itse sivutauluissa olevia virtuaalimuistimappauksia ei muuteta, ne kernelin osoitteet kyllä lautautuu sinne TLBhen sieltä muistissa olevista sivutauluista, ja se flushaus on tehty täysin turhaan.

SMT ei vaadi TLB:n tagaamista, eikä x86 mahdollista sitä muutenkaan
muistitauluissa ei ole threaditietoa ollenkaan.
TLB ja cachet on prosessorissa jaettu threadien kesken, toki dynaamisesti mutta jaettu kuitenkin.

Ymmärrätkö edes, mikä ero on säikeellä ja prosessilla?

Kaikki SMT:tä tukevat CPUt kykynevät ajamaan montaa prosessia yhtä aikaa. Ei vain montaa säiettä.

Niillä prosesseilla voi olla eri virtuaalimuistimappaukset. Jolloin on pakko merkata, kumman prosessin muistimäppäyksistä on kyse.

 

[Sami Riitaoja]

Edelleenkään millään TLB-flushilla ei ole mitään väliä jos sivutauluista löytyy se data jota niistä ei pitäisi löytyä. TLB on vain välimuisti niille sivutauluille.

Jos niitä itse sivutauluissa olevia virtuaalimuistimappauksia ei muuteta, ne kernelin osoitteet kyllä lautautuu sinne TLBhen sieltä muistissa olevista sivutauluista, ja se flushaus on tehty täysin turhaan.

Ja milläs se kernelisivudata latautuu sinne TLB:hen userpuolen softalla? No onhan se hyökkäys mahdollinen ehkä jollain tavalla ja kerran TLB pitää kuitenkin flushata niin se on sitten suorituskyvyn puolesta aivan sama ajaa kerneli omassa muistiavaruudessaan.

Ymmärrätkö edes, mikä ero on säikeellä ja prosessilla?

Kaikki SMT:tä tukevat CPUt kykynevät ajamaan montaa prosessia yhtä aikaa. Ei vain montaa säiettä.

Niillä prosesseilla voi olla eri virtuaalimuistimappaukset. Jolloin on pakko merkata, kumman prosessin muistimäppäyksistä on kyse.

No vaihdetaan prosessi tilalle, ei muuta tilannetta virtuaalimuistimappauksen osalta. Jos virtuaalimuistitaulukoissa olisi prosessitieto tätä voitaisiin käyttää mutta x86:ssa ei ole. Eli cachet ja TLB:t vain yksinkertaisesti jaetaan prosessien välillä. Ja nähtävästi myös arkkitehtuureissa joissa ASID löytyy ei sitä käytetä tuossa tarkoituksessa, Intel skippaa yhden bitin dekoodauksen lukuvaiheessa, prosessitiedon dekoodaus tuossa vaiheessa olis ainakin magnitudin raskaampi operaatio

 

[hkultala]

Ja milläs se kernelisivudata latautuu sinne TLB:hen userpuolen softalla?

Jälleen kerran on aivan perusasiat hukassa asiasta josta vänkää.


Sivutaulu-entry latautuu muistista TLBhen kun yrittää accessoida virtuaaliosoitetta, jonka osoitteenmuunnostietoihin tarvitaan sitä sivutaulua.

Ja ennen meltdown-workaroundia kaikki ne kernel-muistiosoitteet oli ihan näkyvissä sivutauluissa jotka oli user-tilassa käytössä. Niihin itse osoitteisiin ei vaan ollut luku- eikä kirjoitusoikeuksia.

No onhan se hyökkäys mahdollinen ehkä jollain tavalla ja kerran TLB pitää kuitenkin flushata niin se on sitten suorituskyvyn puolesta aivan sama ajaa kerneli omassa muistiavaruudessaan.

Edelleenkään et ymmärrä mikä on syy, ja mikä on seuraus.

Koska perusymmärrys virtuaalimuistin toiminnassa on hukassa.

 

[hkultala]

No vaihdetaan prosessi tilalle, ei muuta tilannetta virtuaalimuistimappauksen osalta. Jos virtuaalimuistitaulukoissa olisi prosessitieto tätä voitaisiin käyttää mutta x86:ssa ei ole.

Ilmeisesti tarkoitat "virtuaalimuistitaulukoilla" sivutauluja.

Eikä sitä prosessi-id:tä tarvisi olla sivutauluissa. Voidaan tagata se sen mukaan, mikä oli CR3-rekisterin sekä CR4-rekisterin oleellisten bittien arvo sitä TLB-entryä muistista ladatessa.

No vaihdetaan prosessi tilalle, ei muuta tilannetta virtuaalimuistimappauksen osalta.

Niinkuin oikeasti.

Yritä nyt opetella edes perusasiat siitä, mikä on prosessi ja mikä säie, sen sijaan että luet hirveästi nippelitietoa ymmärtämättä sitä lukemaasi oikeasti.

Eli cachet ja TLB:t vain yksinkertaisesti jaetaan prosessien välillä.

Ei sitä TLBtä voi vain jakaa merkkaamatta jonkinlaiseen kirjanpitoon, KUMMAN prosessin entrystä on kyse. Koska sama virtuaaliosoite tarkoittaa eri fyysistä osoitetta eri prosesseille.
jos toinen prosessi voisi käyttää toisen prosessin lataamaa TLB-entryä, sen tekemät luvut ja kirjoitukset menisivät väärään fyysiseen osoitteeseen.

Välimuistit sen sijaan kaikissa x86-prossuissa on tagattu fyysisillä osoitteilla eikä virtuaalisoitteilla, jolloin ne voidaan jakaa monen säikeen välillä ilman ylimääräistä kirjanpitoa.


Mutta: jos molemmat säikeet aina kuuluisivat samalle prosessille, niiden virtuaalimuistimappays OLISI SAMA, jolloin ne SAISIVAT jakaa sen TLBn ilman mitään ylimääräistä kirjanpitoa.

En kuitenkaan tiedä yhtään sellaista CPU:ta, joka tulisi tällaista rajoitettua "saman prosessin sisäistä" monisäikeistystä, koska se olisi sekä hyvin ongelmallinen softien yhteensopivuuden kannalta, että tarkoittaisi että sitä voisi käyttää paljon harvemmin.


Monet näyttikset sen sijaan saattavat voimia näin, niissä saattaa samassa ytimessä pystyä olemaan ajossa yhtä monta work grouppia joiden on pakko olla samaa kerneliä, samasta softasta yms. rajoituksia.

 

[Sami Riitaoja]

Ilmeisesti tarkoitat "virtuaalimuistitaulukoilla" sivutauluja.

Eikä sitä prosessi-id:tä tarvisi olla sivutauluissa. Voidaan tagata se sen mukaan, mikä oli CR3-rekisterin sekä CR4-rekisterin oleellisten bittien arvo sitä TLB-entryä muistista ladatessa.

Tagataan mihin kun arkkitehtuurissa ei ole sille tilaa? Ja TLB cache on niin nopeuskriittinen paikka että vaikka ASID löytyisi TLB-entrystä sitä ei tuohon tarkoitukseen käytetä.

Ei sitä TLBtä voi vain jakaa merkkaamatta jonkinlaiseen kirjanpitoon, KUMMAN prosessin entrystä on kyse. Koska sama virtuaaliosoite tarkoittaa eri fyysistä osoitetta eri prosesseille.
jos toinen prosessi voisi käyttää toisen prosessin lataamaa TLB-entryä, sen tekemät luvut ja kirjoitukset menisivät väärään fyysiseen osoitteeseen.

Välimuistit sen sijaan kaikissa x86-prossuissa on tagattu fyysisillä osoitteilla eikä virtuaalisoitteilla, jolloin ne voidaan jakaa monen säikeen välillä ilman ylimääräistä kirjanpitoa.

Eli siis kun se on jaettu tilanne on se että kummallakin prosessilla on omat TLB:nsä. Nopeammat TLB:t on jaettu yleensä staattisesti puoliksi ja vähemmän nopeuskriittiset dynaamisesti eli toinen prosessi voi saada suuremman osan käyttöönsä.

Siinä SMT:ssä on siis kaksi erillistä prosessoria jotka jakaa resursseja ja TLB ei kuulu näihin jaettuihin resursseihin, kumpikin TLB:n puolikas palvelee vain omaa prosessiaan.

 

[hkultala]

Tagataan mihin kun arkkitehtuurissa ei ole sille tilaa?

Sinne TLBhen.

Sinne voi ihan vapaasti toteutus lisätä bittejä, sen formaatti ei ole arkkitehtuurillisesti määriteltyä tilaa.

Arkkitehtuurillisesti on määritelty ainoastaan CR3/CR4-rekisterit, sivutaulujen formaatti ja TLBn flushauskäsky jolla sieltä voidaan poistaa yksittäisiä entryjä.

Ja TLB cache on niin nopeuskriittinen paikka että vaikka ASID löytyisi TLB-entrystä sitä ei tuohon tarkoitukseen käytetä.

"TLB cache"... mitäs nyt tuolla tarkoitat?


Ja tuo "nopeuskriittinen paikka" ja "tuohon tarkoitukseen".


Kaikki TLB-accessit on sitä, että tehdään osoitteenmuunnosta lukemiselle tai kirjoitukselle.

Sinä nyt ilmeisesi haet tässä sitä, että "käytetään vain virtualisointiin".

Mutta sinne ei todellakaan aleta tekemään kahta täysin erilaista ja erinopeuksista datapolkua LSUihin sen mukaan, onko nyt virtualisointi käytössä vai ei.

Se TLB-haku kestää ihan yhtä kauan kummassakin tapauksessa. Ja prosessorin pitää siihen pystyä silloin kun se virtualisointi on käytössä.

Ja itseasiassa:

Nehalemissa L1D-viive kasvoi kolmesta neljän kellojaksoon. Syy saattoi olla juuri tässä.

Eli siis kun se on jaettu tilanne on se että kummallakin prosessilla on omat TLB:nsä. Nopeammat TLB:t on jaettu yleensä staattisesti puoliksi ja vähemmän nopeuskriittiset dynaamisesti eli toinen prosessi voi saada suuremman osan käyttöönsä.

Siinä SMT:ssä on siis kaksi erillistä prosessoria jotka jakaa resursseja ja TLB ei kuulu näihin jaettuihin resursseihin.

Kyllä se on ihan dynaamisesti jaettu ainakin Zenillä:

Mutta todennäköisesti tuossa SMT-TAGinä on kuitenkin vain se yksi bitti että kummasta virtuaaliytimestä on kyse, eikä CR3+CR4n sisältöjen perusteella tehtyä tagausta.


Samoin ainakin Sandy Bridgellä ja Haswellilla (ja Ivy Bridgellä ja Broadwellillä) TLBt on täysin dynaamisesti jaettu virtuaaliytimien välillä. Näissä load- ja store-puskurit on käytännössä ainoat staattisesti jaetut resurssit.

 

[Sami Riitaoja]

Mennyt jo niin sivuraiteille että tiedä mistä aloittaisi.

Eli siis kuten sanoin, context switchissä ei normaalissa x86-ympäristössä tarvitse tehdä TLB flushia, ainoastaan user mode puoli TLB:sta flushataan prosessin vaihtuessa.

TLB taggaus taas ... eli x86:ssa sitä ei normaalisti käytetä, ja jos käytetään niin sitä ei käytetä SMT:n virtuaaliprosessorien erotteluun, ainoastaan TLB:n sisällöt tallennetaan ja palautetaan palattaessa samaan prosessiin.

Ja prossu toki voi mapata TLB:n dynaamisesti kahdelle threadille yhdellä bitillä mutta se on eri asia kuin mitä yleensä tarkoitetaan TLB:n taggauksella.

 

[Sami Riitaoja]

"TLB cache"... mitäs nyt tuolla tarkoitat?

TLB on nimenomaan cache, cache osoitemuunnoksille.

Ja tuo "nopeuskriittinen paikka" ja "tuohon tarkoitukseen".

Eli TLB on yksi nopeuskriittisimpiä kohtia prossun liukuhihnalla, joka osoitetieto pitää saada muutettua ennen cachen lukemista. Eli TLB:n taggaus tietylle prosessille vaatii sen verran monta bittiä että sitä ei yleensä käytetä TLB-muunnoksia tehtäessä vaikka arkkitehtuuri sitä tukisi.

Kaikki TLB-accessit on sitä, että tehdään osoitteenmuunnosta lukemiselle tai kirjoitukselle.

Sinä nyt ilmeisesi haet tässä sitä, että "käytetään vain virtualisointiin".

Mutta sinne ei todellakaan aleta tekemään kahta täysin erilaista ja erinopeuksista datapolkua LSUihin sen mukaan, onko nyt virtualisointi käytössä vai ei.

Se TLB-haku kestää ihan yhtä kauan kummassakin tapauksessa. Ja prosessorin pitää siihen pystyä silloin kun se virtualisointi on käytössä.

Ja itseasiassa:

Nehalemissa L1D-viive kasvoi kolmesta neljän kellojaksoon. Syy saattoi olla juuri tässä.

Mitähän ihmettä tässä oikein yrität selittää?

Kyllä se on ihan dynaamisesti jaettu ainakin Zenillä:

Mutta todennäköisesti tuossa SMT-TAGinä on kuitenkin vain se yksi bitti että kummasta virtuaaliytimestä on kyse, eikä CR3+CR4n sisältöjen perusteella tehtyä tagausta.

No tästä voidaan olla samaa mieltä

Samoin ainakin Sandy Bridgellä ja Haswellilla (ja Ivy Bridgellä ja Broadwellillä) TLBt on täysin dynaamisesti jaettu virtuaaliytimien välillä. Näissä load- ja store-puskurit on käytännössä ainoat staattisesti jaetut resurssit.

Intelillä ainakin ITLB on joko staattisesti jaettu tai kokonaan duplikoitu threadien välillä.

Mutta pointtihan ei ollut se vaan että TLB-taggaus ei ole pakollinen SMT:ssä, TLB:t voivat olla täysin erilliset virtuaaliprosessoriytimien kesken.

 

[Sami Riitaoja]

Jälleen kerran on aivan perusasiat hukassa asiasta josta vänkää.


Sivutaulu-entry latautuu muistista TLBhen kun yrittää accessoida virtuaaliosoitetta, jonka osoitteenmuunnostietoihin tarvitaan sitä sivutaulua.

Ja ennen meltdown-workaroundia kaikki ne kernel-muistiosoitteet oli ihan näkyvissä sivutauluissa jotka oli user-tilassa käytössä. Niihin itse osoitteisiin ei vaan ollut luku- eikä kirjoitusoikeuksia.



Edelleenkään et ymmärrä mikä on syy, ja mikä on seuraus.

Koska perusymmärrys virtuaalimuistin toiminnassa on hukassa.

Nyt oot oikeassa, näin tää Intelin tapauksessa toimii. Mutta enpä tosiaan itse tajunnut koko asiaa, missään ei ole mun mielestä uutisoitu että Intelin MMU:kin vuotaa kuin seula. Tottakai MMU:n pitäisi tehdä käyttöoikeustarkastus ennen uuden osoitemuunnoksen tekemistä, tässä Meltdown-vuodossa on siis PALJON vakavammasta ongelmasta kyse kuin oon käsittänytkään.

-> luettuna alkuperäisestä Meltdown raportista: Sidechannel hyökkäys spekulatiiviseen osoitteeseen saa prossun tekemään pagewalkin, päivittämään TLB:n cacheen osoitemuunnoksen ja lataamaan ko. cachelinen muistiin josta siitä voidaan kaivella dataa toisella hyökkäyksellä -> aivan naurettavan helppoa pollata koko kernelin muistiavaruus ja siinä sivussa koko fyysinen muistiavaruus siltä osin kun se on kerneliin mapattu.

Sitten vielä Intel on lisännyt TSX:n jossa on ominaisuuksia joissa on tietoturvan kannalta aika kyseenalaisia ratkaisuja, paketoituja käskyjä jotka palauttaa prosessorin edeltävään tilaan jos yksi paketoinnin käskyistä ei mene läpi -> lopputuloksena tuon Meltdown raportin esimerkkikoodilla saadaan dumpattua 6700K:lla 503KB/s kernelidataa 0.02% virheprosentilla aivan koko muistiavaruudesta.

Juu Meltdown-paikoilla oli hiukan kiire, toisaalta mitä vittua Intel, kuka tuolla puljussa on antanut valtuutukset poistaa kaikki normaalit käyttöoikeustarkastukset käytöstä?

 

[Fenotype]

Jokos sen saa paljastaa kuinka meltdown lukua saatiin nopeutettua uudelleen , patsin jälkeenkin.

 

[hkultala]

Nyt oot oikeassa, näin tää Intelin tapauksessa toimii. Mutta enpä tosiaan itse tajunnut koko asiaa, missään ei ole mun mielestä uutisoitu että Intelin MMU:kin vuotaa kuin seula. Tottakai MMU:n pitäisi tehdä käyttöoikeustarkastus ennen uuden osoitemuunnoksen tekemistä, tässä Meltdown-vuodossa on siis PALJON vakavammasta ongelmasta kyse kuin oon käsittänytkään.

Ehdotit juuri Catch-22-järjestelmää.

Että voidaan tarkasta käyttöoikeudet, pitää prosessorilla olla sivutaulujen data.
Mutta että voidaan ladata sivutaulujen data, pitäisi sinun mielestäsi olla ensin tarkastettu käyttöoikeudet.

Sivutaulujen lataamisessa ei ole mitään haavoittuvaista. Niitä ei koskaan ladata käyttäjän määrittelmästä paikasta, vaan kernelin määrittelemästä paikasta. Ja tämä paikka on määritelty fyysisenä osoitteena eikä virtuaaliosoitteena. Niitä ladatessa ei edes pystyisi tekemään mitään käyttöoiikeustarkastusta, koska käyttöoikeudet on määritelty vain virtuaaliosoitteille (sivukohtaisesti).

 

[Sami Riitaoja]

Ehdotit juuri Catch-22-järjestelmää.

Että voidaan tarkasta käyttöoikeudet, pitää prosessorilla olla sivutaulujen data.
Mutta että voidaan ladata sivutaulujen data, pitäisi sinun mielestäsi olla ensin tarkastettu käyttöoikeudet.

Sivutaulujen lataamisessa ei ole mitään haavoittuvaista. Sivutauluja ei koskaan ladata mistään normaalin käyttäjän oikeuksilla määritellystä paikasta, vaan niiden paikka määritellään vain kernelin toimesta.

Sun pitää vastustaa ihan periaatteesta kaikkea mun kirjoittamaa? MMU on ihan erillinen, prosessorista riippumaton yksikkö. MMU:lle on aivan perusasia että käyttöoikeudet tarkastetaan ennenkuin osoitemuunnos välitetään prosessorille, mitä vittua sillä koko MMU:lla tekee jos se ei sitä suorita. TLB:n nopeusoptimoinnin nyt tajuaa mutta MMU:lla pitäisi olla aikaa tarkistaa oikeudet aina.

 

[hkultala]

Sun pitää vastustaa ihan periaatteesta kaikkea mun kirjoittamaa?

Kun joku on pihalla kuin lumiukko ja postaa ihan täyttä tuubaa esittäen todella tietävää asiantuntijaa niin silloin reagoin ja kerron missä tuuba on tuubaa.
Jos postaisit jotain joka pitää paikkaansa niin sitten en "vastustaisi".

Sinulla vaan tuntuu olevan ihan käsittämätön Dunning-Kruger-efekti tietotekniikan osaamisessasi. Jatkuvasti luulet osaavasi asioita, joita et oikeasti osaa etkä ymmärrä ja sitten hirveällä innolla alat vänkäämään niistä.

MMU on ihan erillinen, prosessorista riippumaton yksikkö.

Jossain 68020ssä(jossa se oli optionaalinen, eri piirilläkin). Sen jälkeen ei enää.

MMU:lle on aivan perusasia että käyttöoikeudet tarkastetaan ennenkuin osoitemuunnos välitetään prosessorille, mitä vittua sillä koko MMU:lla tekee jos se ei sitä suorita. TLB:n nopeusoptimoinnin nyt tajuaa mutta MMU:lla pitäisi olla aikaa tarkistaa oikeudet aina.

Näytät olevan täysin pihalla siitä, mitä sivutaulut ovat.

Sivutaulujen lataus ei ole käyttäjän tekemä muistinlataus. Sivutaulut ladataan, jotta se MMU itse voi toimia, ja sen jälkeen tehdä sen osoitteenmuunnoksen ja oikeustarkastuksen sille käyttäjän tekemällä muistiaccessille. Sivutaulujen latauksen tekee oikeastaan MMU, ei "käyttäjän koodi".

Ninkuin oikeasti, voisitko ystävällisesti ensin yrittää ottaa perusasiosta ensin selvää.
Se, että luet vaikka mitä nippelitietoa ei paljoa auta jos et ymmärrä lukemaasi, jos et ymmärrä vänkäämiesi asioiden oikeita toimintaperiaatteita.

 

[Sami Riitaoja]

Kun joku on pihalla kuin lumiukko ja postaa ihan täyttä tuubaa esittäen todella tietävää asiantuntijaa niin silloin reagoin ja kerron missä tuuba on tuubaa.
Jos postaisit jotain joka pitää paikkaansa niin sitten en "vastustaisi".

Sinulla vaan tuntuu olevan ihan käsittämätön Dunning-Kruger-efekti tietotekniikan osaamisessasi. Jatkuvasti luulet osaavasi asioita, joita et oikeasti osaa etkä ymmärrä ja sitten hirveällä innolla alat vänkäämään niistä.




Jossain 68030ssä ehkä. Sen jälkeen ei enää.





Näytät olevan täysin pihalla siitä, mitä sivutaulut ovat.

Sivutaulujen lataus ei ole käyttäjän tekemä muistinlataus. Sivutaulut ladataan, jotta se MMU itse voi toimia, ja sen jälkeen tehdä sen osoitteenmuunnoksen ja oikeustarkastuksen sille käyttäjän tekemällä muiestiaccessille. Sivutaulujen latauksen tekee oikeastaan MMU, ei "käyttäjän koodi".

Ninkuin oikeasti, voisitko ystävällisesti ensin yrittää ottaa perusasiosta ensin selvää.
Se, että luet vaikka mitä nippelitietoa ei paljoa auta jos et ymmärrä lukemaasi, jos et ymmärrä vänkäämiesi asioiden oikeita toimintaperiaatteita.

Nyt et vittu oo tosissas, eiks tää kerro just susta

Siis kun MMU teke pagewalkin eli hakee muistisivut ja tekee osoitteenmuunnoksen miksi se ei tässä vaiheessa tarkistaisi myös käyttöoikeuksia ja vasta sen jälkeen kirjoittaisi tulosta TLB:hen myöhemmin käytettäväksi? Side-channel attack vaatii että osoitemuunnos löytyy TLB:stä jotta ko. osoitteen muisti voidaan lukea sinä aikana kun spekulatiivista väärää osoitetta ei ole vielä sellaiseksi ehditty tunnistaa.

 

[Hessu]

Näin ohimennen mielenkiintoista lukea itselle täyttä haltiakieltä olevaa juttua sivukaupalla ja lähinnä kahden käyttäjän väittelyä.

Itseasiassa varsin mielenkiintoista luettavaa. Tästä kun koittaa poimia vielä sen oikean faktan niin saa hyvin tietoa ko. aiheesta.

 

[hkultala]

Siis kun MMU teke pagewalkin eli hakee muistisivut ja tekee osoitteenmuunnoksen miksi se ei tässä vaiheessa tarkistaisi myös käyttöoikeuksia ja vasta sen jälkeen kirjoittaisi tulosta TLB:hen myöhemmin käytettäväksi?

Riippumatta siitä, on se nyt tehtävä muistiosoite laillinen, laiton vai spekulatiivinen laiton, se muunnosdata halutaan sinne TLBhen tallettaa, jotta seuraava osoitteenmuunnos ja turvallisuustarkastus sille samalle sivulle olisi myös nopea. Saadaan sitten seuraavalle accessille nopeasti se tieto, mihin sivuun se osoittaa ja tieto että "tämä on laiton osoite, sen pitää heittää poikkeus" sen sijaan että alettaisiin siinä vaiheessa jälleen tekemään neljää (turhaa) muistiaccessia sen sivutaulun lataamiseksi, kun sitä edellisen kerran ladatassa ei sinne TLBhen tallennettu.

Ja Meltdownin kannalta ihan sama missä järkestyksessä oikeuksien tarkastaminen ja TLBn kirjoitus tehdään, kun molemmat kannattaa kuitenkin tehdä, kun ongelma ei Meltdownissa ole mikään tarkastuksen tekemättä jättäminen vaan siihen reagoiminen. Efektiivisesti ne tehdään kuitenkin rinnakkain.

Side-channel attack vaatii että osoitemuunnos löytyy TLB:stä jotta ko. osoitteen muisti voidaan lukea sinä aikana kun spekulatiivista väärää osoitetta ei ole vielä sellaiseksi ehditty tunnistaa.

Mihin nyt viitaat sanalla "sellaiseksi?" Laittomaan vai spekulatiiviseen?

Ja tulkitsee tuon kummalla tahansa tavalla, ei vaadi etukäteen. Se TLB-entry voidaan aivan hyvin ladata sillä samalla muistiaccessilla mikä sen laittoman spekulatiivisen latauksen tekee, jos se ei tule DRAM-muistista asti vaan esim L2-välimuistista, ja samalla jollain muulla fyysisen muistin lataamisella tai hitaiden käskyjen (esim jakolaskujen) sekvenssillä hidastetaan sen haarautumisen tarkastamista.

 

[Sami Riitaoja]

Riippumatta siitä, on se nyt tehtävä muistiosoite laillinen, laiton vai spekulatiivinen laiton, se muunnosdata halutaan sinne TLBhen tallettaa, jotta seuraava osoitteenmuunnos ja turvallisuustarkastus sille samalle sivulle olisi myös nopea. Saadaan sitten seuraavalle accessille nopeasti se tieto, mihin sivuun se osoittaa ja tieto että "tämä on laiton osoite, sen pitää heittää poikkeus" sen sijaan että alettaisiin siinä vaiheessa jälleen tekemään neljää (turhaa) muistiaccessia sen sivutaulun lataamiseksi, kun sitä edellisen kerran ladatassa ei sinne TLBhen tallennettu.

No TLB:n osalta voisi äärimmäinen optimointi mennäkin näin. Mutta entäpäs miksi sitten sen spekulatiivisen laittoman osoitteen data ladataan cacheen, sitä ei melko varmasti tulla tarvitsemaan

Ja Meltdownin kannalta ihan sama missä järkestyksessä oikeuksien tarkastaminen ja TLBn kirjoitus tehdään, kun molemmat kannattaa kuitenkin tehdä, kun ongelma ei Meltdownissa ole mikään tarkastuksen tekemättä jättäminen vaan siihen reagoiminen. Efektiivisesti ne tehdään kuitenkin rinnakkain.

Jaksat ja jaksat jänkätä. Intelin x86-prossut on nykyisin täysin rikki tietoturvallisuuden osalta koodilla jota niiden olisi tarkoitus ajaa, etkö näe tässä mitään ongelmaa?

Ja mikä itse Meltdown-ongelma on, siis prosessori saadaan huijattua lataamaan spekulatiivisesti koko muistinsa tarkastamatta käyttöoikeuksia juuri sen takia missä järjestyksessä käyttöoikeuksia tarkistetaan ja TLB:hen kirjoitetaan. Olin aluksi vähän skeptinen kun AMD ilmoitti heti että heidän prossunsa ei kärsi Meltdownista mutta tarkemmin ajateltuna se on aivan päivänselvää, prossun tietoturvasuunnittelun pitää olla aivan perseestä ennenkuin Meltdown tässä määrin tulee mahdolliseksi.

Mihin nyt viitaat sanalla "sellaiseksi?" Laittomaan vai spekulatiiviseen?

Ja tulkitsee tuon kummalla tahansa tavalla, ei vaadi etukäteen. Se TLB-entry voidaan aivan hyvin ladata sillä samalla muistiaccessilla mikä sen laittoman spekulatiivisen latauksen tekee, jos se ei tule DRAM-muistista asti vaan jostain välimuistista, ja samalla jollain muulla fyysisen muistin lataamisella tai hitaiden käskyjen (esim jakolaskujen) sekvenssillä hidastetaan sen haarautumisen tarkastamista.

No pistäs referenssi tähän, vai päättelitkö ihan itse

 

[antero]

Mitä tämä uutisen otsikko oikein tarkoittaa : "Intelin prosessoreista löytynyt bugi vaatii suorituskykyyn vaikuttavan käyttöjärjestelmätason"

Taitaa olla lyhennetty otsikkoa leikkaamalla.

 

[user9999]

Mitä tämä uutisen otsikko oikein tarkoittaa : "Intelin prosessoreista löytynyt bugi vaatii suorituskykyyn vaikuttavan käyttöjärjestelmätason"

Taitaa olla lyhennetty otsikkoa leikkaamalla.

Intelin prosessoreista löytynyt bugi vaatii suorituskykyyn vaikuttavan käyttöjärjestelmätason päivityksen
Puuttuu forum puolelta tuo päivityksen. Ei taida mahtua otsikkoon...

 

[hkultala]

No TLB:n osalta voisi äärimmäinen optimointi mennäkin näin. Mutta entäpäs miksi sitten sen spekulatiivisen laittoman osoitteen data ladataan cacheen, sitä ei melko varmasti tulla tarvitsemaan

Niin, siinä Intel tekee turhaa työtä ja haaskaa energiaa ja muistikaistaa melko harvinaisessa tilanteessa. (ja lisäbonuksena on altis meltdownille).

Ja syynä oli se, että näin saatiin prosessorin rakenteesta yksinkertaisempi, vähemmän logiikkaa sinne latausyksiköihin. Siinä vaiheessa kun tämä ratkaisu tehtiin varmaan myös ajateltiin, että tämä tekee prosessorista luotettavamman, vähemmän paikkoja bugeille. Tämä vaan osoittautui virheelliseksi päätelmäksi.

Tämän takia pidän todennäköisempänä, että AMD on immuuni Meltdownille nimenomaan sen takia, että AMD halusi tehdä omista prossuistaan energiatehokkaampia eikä halunnut haaskata virtaa (ja kaistaa) tekemällä turhia laittomia loadeja, ja oli valmis lisäämään prosessoreihinsa monimutkaisuutta niiden laittomien latausten katkaisemiseen jo aiemmassa vaiheessa. Ja tämä sähkönkulutuksen ja muistikaistan optimointi myös teki AMDstä immuunin meltdownille. Eli että ihan virran- ja kaistansäästösyistä AMD sattui tekemään prossuistaan immuuneja meltdownille.

(en kuitenkaan ole varma tästä AMDn motivaatiosta)

Jaksat ja jaksat jänkätä. Intelin x86-prossut on nykyisin täysin rikki tietoturvallisuuden osalta koodilla jota niiden olisi tarkoitus ajaa, etkö näe tässä mitään ongelmaa?

Ei ne ole mitenkään "täysin rikki". Ne on täysin speksinsä mukaisia, alkuperäinen speksi vaan ei ota sivukanavahyökkäyksiä huomioon. Ja meltdowniin on olemassa softa-workaround joka suojaa siltä, siitä vaan tulee pieni suorituskykyhaitta kernel-kutsujen yhteydessä.

Ja mikä itse Meltdown-ongelma on, siis prosessori saadaan huijattua lataamaan spekulatiivisesti koko muistinsa tarkastamatta käyttöoikeuksia juuri sen takia missä järjestyksessä käyttöoikeuksia tarkistetaan ja TLB:hen kirjoitetaan. Olin aluksi vähän skeptinen kun AMD ilmoitti heti että heidän prossunsa ei kärsi Meltdownista mutta tarkemmin ajateltuna se on aivan päivänselvää, prossun tietoturvasuunnittelun pitää olla aivan perseestä ennenkuin Meltdown tässä määrin tulee mahdolliseksi.

TLBllä ei edelleenkään ole tämän kanssa mitään tekemistä. Vaan vain sillä, koska laittomaan muistiosoitteeseen reagoidaan.

No pistäs referenssi tähän, vai päättelitkö ihan itse

Ihan itse päättelin. Ei vaadi paljoa päättely- eikä laskutaitoa, kun ymmärtää miten välimuisti ja virtuaalimuisti toimii.

Sivutauluja kakutetaan melko normaalisti ainakin L2-kakuissa, (L1-kakuista en ole aivan varma, mutta ilmeisesti ei niissä). (*). X86-64lla sivutaulut on nykyään 4-tasoisia (mutta voidaan laajentaa 5-6 tasoon myöhemmin). Neljä riippuvaista latausta L2-kakusta tekee n. 48 kellojaksoa.

Efektiivisesti osoitteenmuunnos siis kestää n. 48 kellojaksoa ylimääräistä, jos sivutaulut tulee L2-kakuista eikä muunnostietoa löydy TLBstä.

Aivan triviaalia viivästää sitä ehdon tarkastelua tuon verran enemmän. Yksi riippuvainen haku DRAM-muistista asti sille hypyn ehdolle tekee heti yli 100 kellojaksoa.



(*)
Ja juuri tähän sivutaulujen kakuttamiseen liittyi Phenomin kuuluisa bugi, siinä ei toteutunut välimuistin koherenttius täydellisesti sivutaulujen latausten osalta ja tietyssä tilanteessa sivutauluja muuttaessa toinen prosessoriydin luki ne välimuistista väärin; workaround oli kokonaan kieltää sivutaulujen lataaminen välimuistista ja ladata ne aina DRAMilta asti)

 

[Sami Riitaoja]

Ihan itse päättelin. Ei vaadi paljoa päättely- eikä laskutaitoa, kun ymmärtää miten välimuisti ja virtuaalimuisti toimii.

Sivutauluja kakutetaan melko normaalisti ainakin L2-kakuissa, (L1-kakuista en ole aivan varma, mutta ilmeisesti ei niissä). (*) Neljä riippuvaista latausta L2-kakusta tekee n. 48 kellojaksoa.

Efektiivisesti osoitteenmuunnos siis kestää n. 48 kellojaksoa ylimääräistä, jos sivutaulut tulee L2-kakuista eikä muunnostietoa löydy TLBstä.

Aivan triviaalia viivästää sitä ehdon tarkastelua tuon verran enemmän. Yksi riippuvainen haku DRAM-muistista asti sille hypyn ehdolle tekee heti yli 100 kellojaksoa.

Taidatpa vaan olla päättelyinesi yksin. Näitähän kutsutaan TLB-sidechannel hyökkäyksiksi nimenomaan sen takia että TLB:n tulokset tulevat liukuhihnalle käskyn kulkiessa, koko TLB:tä ei välttämättä dekoodata vaan vain osa jonka perusteella pystytään L1-cachesta lukemaan data, ja Intelin tapauksessa esimerkiksi se käyttöoikeus tarkastetaan vasta liukuhihnan lopussa, varmaan samalla kun tarkistetaan että osittain dekoodattu osoitemuunnos osui. Tästä sitten seuraa että aikaa ajaa spekulatiivisia käskyjä hyödyntäen on tietty osa liukuhihnan pituutta, 48 kellojaksoa (optimistinen arvio pagewalkille) on varmasti riittävän pitkä aika vesittämään tuon idean, varsinkin kun ainakaan esimerkeissä ei ole käytetty mitään poikkeuksellisen pitkiä suoritusaikoja omaavia käskyjä, kaikki tapahtunee normaalin liukuhihnan pituudella.

Saat pistää referenssiä jos joku muu on kanssasi samaa mieltä.

 

[hkultala]

Taidatpa vaan olla päättelyinesi yksin. Näitähän kutsutaan TLB-sidechannel hyökkäyksiksi nimenomaan sen takia että TLB:n tulokset tulevat liukuhihnalle käskyn kulkiessa, koko TLB:tä ei välttämättä dekoodata vaan vain osa jonka perusteella pystytään L1-cachesta lukemaan data, ja Intelin tapauksessa esimerkiksi se käyttöoikeus tarkastetaan vasta liukuhihnan lopussa, varmaan samalla kun tarkistetaan että osittain dekoodattu osoitemuunnos osui.

Pitää näköjään pitää oppitunti vielä L1-kakunkin toiminnasta...


L1D:n indeksoimiseen ei järkevästi toteutetulla(eli VIPT =Virtually indexed, physically tagged-tyyppisellä) L1D-välimuistilla tarvita YHTÄÄN bittiä sieltä TLBstä. Ja intel ei ole ainakaan 486n jälkeen tehnyt muita kuin VIPT-tyyppisiä L1D-välimuisteja.

VIPT:in toiminta nyky-x86lla:

Virtuaalimuistisivu on 4096 tavua. Osoitteen 12 alinta bittiä(tai oikeastaan bitit 6:11, alimmat 6 voi vielä ignorata, koska välimuistilinjat) kertoo suoraan, missä indekseissä data voi välimuistissa olla. 8-tie-joukkoassosiatiivisessa välimuistissa on 8 kohtaa, joilla on tämä sama indeksi.

(ei ole sattumaa, että intelin nykyprossuilla L1D-välimuistin koko on 32kiB ja sen assosiatiivisuus on 8, tämä on erittäin tarkkaan suunniteltu ominaisuus)

Näiden kahdeksan kohdan lukeminen (sekä data että tag-bitit) voidaan(*) siis aloittaa HETI odottamatta yhtään mitään TLBltä.

Eli samaan aikaan voidaan rinnakkain tehdä seuraavat asiat:

* lukea 8stä mahdollisesta (saman indeksin omaavasta kohdasta) paikasta välimuistista data ja tagit
* lukea TLB.

JA sitten seuraavalla kellojaksolla, kun nämä on tehty, tehdään tarkastus, vastaako jonkun kahdeksasta ladatusta välimuistilinjasta tag-bitit sitä arvoa, mikä TLBltä saatiin.
Ja tähän tarvitaan ihan kokonaan se fyysinen sivuosoite. (niitä alimpia bittejä jolla välimuistia indeksoidaan ei tarvita, mutta niitä ei TLBssä olekaan)

Jos jonkun ladatun välimuistilinjan tagit osuu, sitten meillä on osuma, ja sen sisältö (alimpien kuuden osoitebitin osoittamasta kohdasta) välitetään lataukselle datana, ja muiden välimuistilinjojen data ignorataan.

Jos taas minkään ladatun välimuistilinjan tagit ei osu, meillä on huti, ja sitten pitää lähteä huhuilemaan dataa seuraavalta välimuistitasolta.


Että mistä ihmeen osittain dekoodatusta osoitteenmuunnoksesta nyt oikein höpiset?


(*)
Käytännössä tosin virran säästämiseksi nykyään kaikista kahdeksasta ei välttämättä ainakaan dataa accessoida heti rinnakkain, vaan ehkä ensin vain kaikkien tagit sekä data vain yhdestä, jossa se todennäköisemmin on, ja sitten menee esim. ylimääräinen kellojakso jos se ei ole siellä, vaan jossain muussa (way prediction).

 

[demu]

Mielenkiintoista keskustelua. Jotenkin tulee tämä mieleen.

 

[JiiPee]

Ei ne ole mitenkään "täysin rikki". Ne on täysin speksinsä mukaisia, alkuperäinen speksi vaan ei ota sivukanavahyökkäyksiä huomioon. Ja meltdowniin on olemassa softa-workaround joka suojaa siltä, siitä vaan tulee pieni suorituskykyhaitta kernel-kutsujen yhteydessä.

No kyllähän ne nyt on aika helvetin isosti rikki vaikka kuinka vänkyttäisit muuta. Lisäksi kuiske kuuluu että nuo workaroundit on jo kierretty joten seuraavaan workaroundia odotellessa ja katsotaan miten sitten taas tulee performance hittiä.

 

[Cirrus]

No kyllähän ne nyt on aika helvetin isosti rikki vaikka kuinka vänkyttäisit muuta. Lisäksi kuiske kuuluu että nuo workaroundit on jo kierretty joten seuraavaan workaroundia odotellessa ja katsotaan miten sitten taas tulee performance hittiä.

Ja vaikka sinä kuinka vänkyttäisit, niin intel ei ole rikki eikä amd ole rikki.

Jos intel on rikki, niin siitä seuraa että amd on rikki. Tästä taas seuraa että koko konsepti rikki on merkityksetön. Kaikki on aina rikki.

 

[JiiPee]

Ja vaikka sinä kuinka vänkyttäisit, niin intel ei ole rikki eikä amd ole rikki.

Jos intel on rikki, niin siitä seuraa että amd on rikki. Tästä taas seuraa että koko konsepti rikki on merkityksetön. Kaikki on aina rikki.

Jos Intelin prosessorit ei olisi isosti rikki, niin ei olisi nyt mitään meltdown fiaskoa.

 

[Cirrus]

Jos Intelin prosessorit ei olisi isosti rikki, niin ei olisi nyt mitään meltdown fiaskoa.

Eli koko konsepti rikki on täysin hyödytön. Kaikki on rikki. Logiikallasi mikä tahansa jälkikäteen löydettävissä oleva asia tekee rikkinäiseksi, joten siitä seuraa että kaikki rikki.

Amd:stä löytyi spectre, joten sekin on rikki. Armit on rikki. Jne.

Täyttä paskaa sanon minä.

 

[JiiPee]

Eli koko konsepti rikki on täysin hyödytön. Kaikki on rikki. Logiikallasi mikä tahansa jälkikäteen löydettävissä oleva asia tekee rikkinäiseksi, joten siitä seuraa että kaikki rikki.

Amd:stä löytyi spectre, joten sekin on rikki. Armit on rikki. Jne.

Täyttä paskaa sanon minä.

Kyllä. Lähes kaikki on rikki. Toiset enemmän toiset vähemmän.

 

[Fenotype]

Tässä pari huumori kuvaa, intel logo tiimi ollut selvästi aikaansa edellä.

Spoileri: kuva1

Spoileri: kuva