AMD:n prosessorit ovat kaiken saatavilla olevan tiedon mukaan immuuneja polttavana puheenaiheena viime päivät olleelle Meltdown-haavoittuvuudelle, mutta samaan pakettiin kuuluva Spectre-haavoittuvuus koskee myös sen prosessoreita. Yhtiö on julkaissut aiheeseen liittyvän lausunnon ja aiemmin, mutta nyt yhtiö on julkaissut tarkempia tietoja koskien haavoittuvuuksien korjaamista.
AMD:n mukaan sen prosessorit ovat haavoittuvuia Spectren ensimmäiselle variantille ja teoriassa haavoittuvia sen toiselle variantille. Jälkimmäisestä puhutaan lähinnä teoreettisena haavoittuvuutena, koska yksikään taho ei ole onnistunut osoittamaan haavoittuvuutta. Yhtiö kuitenkin laskee teoreettisenkin mahdollisuuden haavoittuvuudeksi.
Yhtiön tuoreen päivityksen mukaan Spectren ensimmäinen variantti paikataan muiden alustojen tavoin käyttöjärjestelmäpäivityksillä. Windows-järjestelmille alun perin jaettu päivitys aiheutti ongelmia osalla AMD:n vanhemmista prosessoreista (Opteron-, Athlon- ja Turion X2 Ultra -sarjojen prosessoreille), jonka vuoksi sen jakelu keskeytettiin AMD:n prosessoreilla varustetuille kokoonpanoille väliaikaisesti. Sittemmin päivityksen jakamista on jatkettu myös niille AMD:n prosessoreille, joille päivitys ei aiheuttanut ongelmia. Myös Linux-alustojen ensimmäisen Spectre-variantin korjaavat päivitykset ovat parhaillaan jakelussa.
Toiselle Spectre-variantille on luvassa sekä prosessorin mikrokoodi- että käyttöjärjestelmäpäivityksiä. AMD:n mukaan sen Ryzen- ja Epyc-prosessoreille julkaistaan mikrokoodipäivitys tällä viikolla ja vanhemmille prosessoreille lähitulevaisuudessa. Päivitys julkaistaan valinnaisena, jolloin käyttäjät voivat itse päättää haluavatko he paikata teoreettisena pidetyn haavoittuvuuden vai eivät. Mikrokoodipäivitys tullaan jakamaan käyttäjille emolevyvalmistajien kautta BIOS-päivityksenä.
Ensimmäiset toisen Spectre-variantin käyttöjärjestelmätason päivitykset ovat parhaillaan jakelussa Linux-alustoille ja AMD kertoo tekevänsä yhteistyötä Microsoftin kanssa sovittaakseen päivitysten julkaisuaikataulut yhteen mikrokoodipäivitysten kanssa. AMD tekee lisäksi parhaillaan yhteistyötä Linux-kehittäjien kanssa Retpoline- eli ”Return trampoline” -päivityksen parissa, joka liittyy toisen Spectre-variantin paikkaamiseen.
Lähde: AMD
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ä.
"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ä.
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.
Edit
TLB on nimenomaan cache, cache osoitemuunnoksille.
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.
Mitähän ihmettä tässä oikein yrität selittää?
No tästä voidaan olla samaa mieltä
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.
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ä?
Jokos sen saa paljastaa kuinka meltdown lukua saatiin nopeutettua uudelleen , patsin jälkeenkin.
:facepalm:
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).
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.
Kun joku on pihalla kuin lumiukko ja postaa ihan täyttä tuubaa niin silloin reagoin ja kerron missä tuuba on tuubaa.
Jos postaisit jotain joka pitää paikkaansa niin sitten en "vastustaisi".
68030ssä. Sen jälkeen ei enää.
:facepalm:
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. SIvutaulujen latauksen tekee 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.
Kun joku on pihalla kuin lumiukko ja postaa ihan täyttä tuubaa niin silloin reagoin ja kerron missä tuuba on tuubaa.
Jos postaisit jotain joka pitää paikkaansa niin sitten en "vastustaisi".
68030ssä. Sen jälkeen ei enää.
:facepalm:
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. SIvutaulujen latauksen tekee 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.
Näin ohimennen mielenkiintoista lukea itselle täyttä haltiakieltä olevaa juttua sivukaupalla ja lähinnä kahden käyttäjän väittelyä. :dead:
Itseasiassa varsin mielenkiintoista luettavaa. Tästä kun koittaa poimia vielä sen oikean faktan niin saa hyvin tietoa ko. aiheesta. :tup:
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.
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.
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 😉
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.
No pistäs referenssi tähän, vai päättelitkö ihan itse 😀
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…
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)
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ä.
TLBllä ei edelleenkään ole tämän kanssa mitään tekemistä. Vaan vain sillä, koska laittomaan muistiosoitteeseen reagoidaan.
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)
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ä.
Pitää näköjään pitää oppitunti vielä L1-kakunkin toiminnasta…
L1n 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-datavälimuisteja.
VIPT:in toiminta 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ä välimuistin koko on 32kiB ja sen assosiatiivisuus on 8, tämä on erittäin tarkkaan suunntieltu 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 ifnorataan.
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).
Mielenkiintoista keskustelua. Jotenkin tulee tämä mieleen.
![[IMG]](https://images.duckduckgo.com/iu/?u=http%3A%2F%2Ffarm4.staticflickr.com%2F3414%2F4628611135_d94357c77a_z.jpg&f=1)
😀
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.
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ä.
Kyllä. Lähes kaikki on rikki. Toiset enemmän toiset vähemmän.
Tässä pari huumori kuvaa, intel logo tiimi ollut selvästi aikaansa edellä. 😆
Wanhat prossut saa kuin saakin Spectre päivityksiä, hieman statustietoa täältä: https://newsroom.intel.com/wp-content/uploads/sites/11/2018/02/microcode-update-guidance.pdf
Eli siellä on jo pre-betat olemassa Sandylle ja Ivylle jne. Eli eiköhän lähikuukausina noi tule jakoon ihan suoraan käyttöjärjestelmän päivitysten mukana.
Helpompi tapa käyttää näitä reikiä https://gizmodo.com/researchers-find-new-ways-to-exploit-meltdown-and-spect-1823020029
Vaikuttaa edelleen hyvin hitaalta ja epävarmalta nyhräämiseltä..
Ja sillähän ei ole mitään väliä, koska koneen korkkaajan tarvitsee perinteisesti onnistua hommassa vain kerran jolloin omistajan peli on menetetty
Toki sillä on paljonkin väliä, miten tuota voidaan hyödyntää suuressa mittakaavassa. Hitaalla nyhräyksellä on se paha riski, että käyttäjä vittuuntuu ja siivoaa nyhräävän haitakkeen pois ja tekee myös ilmoituksen korkatuusta sivustosta ja lähettää mahdollisesti näytteen virustorjuntafirmaan joka yrittää työntää haitakkeen koneelle.
Itsekin olen jokusen ilmoituksen tehnyt. Fiksut haitakkeen työntäjät eivät tosin yritä saada samaa konetta tekemään epämääräisyyksiä montaa kertaa peräkkäin / päivä.
Optimoit sitten koko TLB:n pois, muuten hyvä mutta ilman TLB:tä cache voi osoittaa sen 12 bitin verran, 4kilotavua assosiaktiivisuudesta riippumatta, se ei liity tähän. Intelin L1D-TLB taulukko 4KB:n sivuille taitaa nykyään olla 128, eli 7 bittiä ja 8 bitin cachelinjat eli jokainen cachelinja pystytään ohjaamaan omaan osoitteeseensa TLB:n avulla. TLB sitten voidaan optimoida, eli 36 virtuaalimuistibittiä on aivan turha dekoodata, esimerkiksi 9 eli sivutaulun mukainen määrä antaa 2megatavun alueen jolle voidaan mapata 128 cachelinjaa, assosiaktiivisuus vain pilkkoo nuo pienemmiksi osiksi eli koko TLB:tä ja välimuistia ei tarvitse käydä läpi haussa, ainoastaan se assosiaktiivisuuden osa joka voi sisältää tuloksen.
Intelin prosessorit tekevät täysin uskomattoman typeriä juttua MMU:n ja spekulatiivisten lukujen suhteen. KPTI korjaa vain kernelin suorat muistiosoitukset pois, koko userspace on silti aivan täysin haavoittuva. Oletko kattonut miten Intelin prossut vuotavat datan, ei tehdä mov haluamastaan osoitteesta ja käyttää sitä johonkin aktivoimaan cachelinja. Eli ei minkäänlaista suojausta, spekulatiivinen muistihaku rikkoo kaiken. Toimivat Meltdown-mikrokoodipäivitykset vain sitten joutuvat ottamaan myös spekulatiivisen muistinkäsittelyn pois päältä ja tämä syö suorituskykyä niin että tuntuu.
Meltdown-attack onnistuu melkein keltä tahansa joka saa hello worldin koodattua. Meltdown-paperissa koodia ei käytetä kuin kernelidatan vuotamiseen mutta sama tapahan toimii Spectrenä eli userspacen vakoiluna, kaikki userspaceen sandboxattu koodi pystyy lukemaan isäntäohjelman kaiken datan. Webbiselaimiinhan tuli "Fixi" jossa ajoitustarkkuutta laskettiin jotta aivan naurettavan helppo reiän hyödyntäminen ei onnistu, mutta se ei varmasti ole kovinkaan pitävä paikkaus.
:facepalm:
Yritä nyt ymmärtää, miten välimuistin osoitteistus ja kirjanpito toimii. Lue vaikka viestini uudestaan ajatuksella läpi.
Siihen, että katsotaan mistä paikasta välimuistia jotain data löytyy jos se sieltä löytyy ei tarvita muita kuin niitä alimpia bittejä. Se määräytyy tuollaisessa välimuistissa vain niiden 12 alimman bitin perusteella.
Siihen, että tarkastetaan että osoittaako tämä data välimusitissa siihen paikkaan mihin nyt tehdään access tarvitaan sitten koko osoitetietoa.
Tämä mahdollistetaan että itse dataa (ja tagibittejä) voidaan hakea rinnakkain välimuistista ja sen osoitteen ylompiä bittejä TLBstä.
Mutta se osumantarkastus voidaan tehdä vasta kun osoitteenkuunnos on tehty.
Näin toimii VIPT-välimuisti.
Se, millainen on TLBn rakenne ja se, millainen sen L1D-välimuistin rakenne on kaksi täysin eri asiaa.
Tässä puhuttiin datavälimuistin rakenteesta, ei data-TLBn rakenteesta.
:facepalm:
Ei ole mitään yhtenäistä 2 megatavun aluetta missään jos käytetään 4 kiB virtuaalimuistisivuja. Jokainen 4 kiB virtuaalimuistisivu voi osoittaa fyysisessä muistissa aivan eri paikkaan.
Ja sen sivun fyysinen osoite on kokonaisuudessaan siellä sivutaulun viimeisellä tasolla. Sivutaulun aiemmissa tasoissa on pointteri siihen seuraavaan tasoon, ei mitään fyysisen osoitteen "sillä kohdalla" olevia bittejä
(ja millä ihmeen laskuopilla saat jotain 128 välimuistilinjaa johonkin?)
Ja siinä vaiheessa kun tarkastetaan, onko välimuistissä indeksiin numero 0 säilötty osoitteiden 32768-32831 data vai osoitteiden 2147483648-2147483711 sisätämä data, tarvitaan kyllä ihan jokaista osoitteen yläbittiä. Jos siellä puuttuisi yksikin bitti, sitten sen bitin kohdan verran toisistaan eroavat eri osoitteet sotkeentuisi välimuistin kirjanpidossa.
Ja sitä "osaa" välimuistista jossa se data voi olla, kutsutaan nimellä "setti" ja sen järjestysnumeroon (alkaen nollasta) viitataan termillä "indeksi".
Ja vaikuttaa muutenkin siltä, että olet tainnut käsittänyt assosiatiivisuuden aivan väärinpäin.
Pitää nimenomaan vääntää VIELÄ enemmän rautalankaa välimuistista.
Tosin Dunning-Kruger-efekti taitaa olla sillä tasolla että mikään rautalanka ei taida mennä perille, että miksi edes yritän..
Seuraava ei liity vielä mitenkään virtuaalimuistiin eikä TLBhen:
Ilman assosiatiivisuutta oleva välimuisti == direct mapped, "suorasijoittava"
Direct-mapped-välimuistissa jokaiselle muistiosoitteelle on tällöin tasan yksi mahdollinen paikka(indeksi), missä se voi välimuistissa olla. Tällöin osoitteen N alinta bittiä kertoo SUORAAN ja TARKKAAN sen, mihin kohtaan välimuistia se data menee, jos se sinne menee.
Välimuisti jossa on 64 tavun linjat, 32 kilotavun kapasiteetti, tarkoittaa että eli indeksejä on 512 kappaletta(0-511). 6 alinta bittiä(0:5) valitsee tällöin tavun välimuistilinjalta, seuraavat 9 bittiä(5:14) osoitetta valitsee suoraan indeksin, jolta data löytyy, JOS se välimuistista löytyy. Ja kaikki ylemmät bitit tallennetaan välimuistin tagikenttään..
Eli tällöin muistiosoitteet esim. 0x0, 0x8000, 0x10000, 0x18000, 0x2000, 0x10000000, 0x20000000, 0x400000000000 mevät kaikki välimuisti-indeksiin, eli indeksiiin 0. Ainoastaan yksi niistä voi kerrallaan olla tallennettuna välimuistilinjaan. Ja osoitteet 0x40, 0x8040, 0x18040, 0x2040, 0x10000040, 0x20000040, 0x400000000040 menevät kaikki välimuisti-indeksiin 1. Ainoastaan yksi niistä voi kerrallaaan olla tallennettuna välimuistiin.
Kun sitten tulee muistiaccess vaikka osoitteeseen 0x50000000, otetaan esin osoitteesta ne bitit, joitka muodostavat indeksin, accessoidaan välimuistia siitä indeksista, ja verrataan, mitä välimuistin tag-kentästä löytyy siitä indeksistä. Löytyykö sieltä samat ylimmät bitit kuin mihin nyt halutaan osoittaa, jolloin välimuisti sisältää sen osoitteen mitä haluttiin hakea, vai löytyykö sieltä jotkut muut bitit, jolloin välimuistissa on talletettuna jonkun muun osoitteen data, ja meillä on huti.
Tämän tarkastamiseen tarvitaan osoitteen kaikki ylimmät bitit. Jos sieltä jätettäisiin joku ylempi bitti pois, sitten sen bitin position verran tosistaan eroavia osoitteita ei välimuistin kirjanpidossa voisi eroittaa toisistaan, ja välimuistista annettaisiin toisen data toisen osoitteella.
Suorasijoittavan välimuistin pahin huono puoli on, että usein tehdään accesseja välimuistin koon kerrannaisen päähän toisitaan(kaikki kiva on kahden potensseissa, sekä välimuistien koot että yleiset taulukkokoon koodissa jne). Accessit peräkkäin osoitteisiin 0x8000 ja 0x10000 ja sitten taas 0x8000 ja sitten taas 0x100000 johtaa siihen, että 0x10000 menee välimuistissa samaan kohtaan (indeksi numero 0) kuin missä 0x8000 oli eli 0x8000 heitetään välimuistista pihalle. Sitten se joudutaan kolmatta accessia varten jälleen lataaman välimuistiin, ja heittää samalla osoitteen 0x10000 datan pihalle välimuistista. Ja sitten jälleen viimeinenkin access on tämän takia huti.
Sitten otetaan virtuaalimuisti ja TLB huomioon:
Ja jos tällaisen 32kiB suorasijoittavan välimuistin kanssa käytetään 4 kiB virtuaalimuistisivuja, osoitteenmuunnos pitää tehdä ennen välimuistista hakemista, koska osoitteenmuunnos vaikuttaa bitteihin 12:14 joita tarvitaan indeksin valitsemiseen, eli ennen osoitteenmuunnosta ei voida tietää, mistä indeksistä se välimuistista löytyy. Ei siis voida käyttää VIPTiä
Jotta direct mapped-cachelle EI tarvi osoitteenmuunnosta tehdä ennen kuin access siihen aloitetaan, tarvii sen koon olla niin pieni, että koko indeksi löytyy sieltä virtuaalimuistisivun sisäisistä biteistä, eli cachen koko maksimissaan virtuaalimuistisivun kokoinen.
Assosiatiivinen välimuisti taas tarkoittaa sitä, että siellä on efektiivisesti monta pienempää välimuistia rinnakkain(jokaista näitä kutsutaan nimellä way/tie). 8-tie-joukkoassosiatiivisessa niitä on 8. Ja data voidaan säilöä mihin tahansa niistä siihen indeksiin, mihin se osoitteeseensa mukaan osuu.
Eli nyt osoitteiden 0x8000 ja 0x10000 data voikin olla yhtä aikaa säilöttynä välimuistiin, koska osoite 0x8000 voi olla vaikka laitettu ensimmäiseen tiehen indeksiin 0 ja 0x10000 toiseen tiehen indeksiin 0.
Yksi setti muodostaa kaikkien näiden kahdeksan rinnakkaisen välimuistien samalla indeksillä olevat välimuistilijat. 0x8000 ja 0x10000 on indeksiltään samat(0) eli osuu samaan settiin, mutta koska jokaisessa setissä on monta välimuistilinjaa, ne voivat olla yhtä aikaa välimuistissa.
Virtuaalimuisti ja joukkoassosiatiivisuus:
Eli 32 kiB 8-tie-joukkoassosiatiivinen välimuisti koostuu kahdeksasta 4 kiB tiestä, eli 64 B linjakoolla jokaisessa tiessä on 64 linjaa. Tällöin osoitteen bittejä 6:11 käytetään linjan valitsemiseen. Kaikki mahtuvat samalle 4kiB virtuaalimuistisivulle. Voidaan käyttää VIPTiä.
ps. yhdessä suunnittelemistani prosessoriytimistä on ollut myös välimuisti.
Oletan, että sinä et sitten saa hello worldiä koodattua.
Esität hirveän asiantuntevaa asioista, joista olet lukenut yksityiskohtaista juttua, mutta jatkuvasti tekstistäsi käy kuitenkin ilmi, että et ole ymmärtänyt suurinta osaa lukemastasi, koska aivan perusasioissa on vakavia puutteita.
Menisi varmaan moneen muuten täydestä, mutta täällä on esim. minä ja vmovapd jotka nähdään tämän läpi.
Mutta tosiaan, sitä ymmärtämystä näistä asioista voisi auttaa se, että ensin yrittäisit koodata sen hello wordiin vaikka ihan C-kielellä. Ei tietokoneen toimintaa oikeasti ymmärrä jos ei sille koodaa mitään. Toki pelkällä hello wordlilläkään ei vielä pitkälle pötkitä,
… ja niiden userspace-sandboksien murtamisessa se spectre toimii tasan yhtä hyvin KAIKILLA superskalaarisilla prosessoreilla kuin intelin prosessoreilla; Userspace-sandboksit ei perustu virtuaalimuistin oikeusbitteihin.
Suojautuaksesi tältä rautatasolla saat vaihta perus-pentiumiin , 1. sukupolven Atomiin tai johonkin ARM Cortex A55een. KAIKKI spekulatiivista suoritusta tekevät prosessorit ovat tasan yhtä lailla alttiita spectren 1. variantille.
Ja KAIKKI suorituskykyiset CPUt tekevät spekulatiivista suoritusta.
Toisilla ymmärtäminen prosessorin toiminnasta perustuu tietoon, kokemukseen ja ymmärtämiseen, toisilla uskoon ja epämääräisten yksittäisten tiedonjyvien lukemiseen ymmärtämättä yhtään kokonaiskuvaa ja niiden yksityiskohtaisten tiedonjyvästen merkitystä.
Toki kaikki sellainen, mitä ei ymmärrä, kuulostaa uskomattomalta.
Joko paljastit olet jälleen "uudella" tavalla täysin pihalla siitä, miten käyttäjärjestelmissä virtuaalimuistia käytetään, tai sitten sekoitat jälleen Meltdownia ja Specreä keskenään.
Userspace-ohjelmien muistia ole mapatty toisilleen. Meltdown ei toimi mappaamattomaan muistiin.
Ja Inteliä vastaan asian tiimoilta nostettujen kanteiden määrä on nyt noussut 35:een:
Spectre and Meltdown are now a legal pain for Intel — the chip maker faces 35 lawsuits over the attacks
Kyllä tästä jokin lasku täytyy kirjata jo ihan taseeseen.
Tätä keskustelua on ollut hauska seurata 🙂 Kieltämättä muutamassa kohtaa on meinannut kahvit tulla ulos nenästä.
No se on ollut paljon yksinkertaisempi kuin mistä nyt yrität vääntää juttua. Täähän ei ole edes mikään monimutkainen asia.
Eli jos sulla on x bittiä osoiteavaruutta niin kaikki muistiosoitteet on mapattava tähän muistiavaruuteen. Jos emme tarkasta kuin 12 alimpaa bittiä meillä on 4 kilotavua muistiavaruutta jolla cache voi operoida, pyöritteli sen miten päin tahansa.
Nyt jos meillä on täysi TLB käytössä pystytään mappaamaan kaikki muistiosoitteet koko muistiavaruudesta tähän cacheen(fully assosiactive, way-set assosiactive jakaa cachen sitten osiin). Jokainen TLB muunnos pitää kuitenkin suorittaa ennen muistiin viittaamista joten L1-tlb haussa voidaan hyvin tinkiä kuinka monta bittiä TLB:stä tarkistetaan, se yhdeksän bittiä oli vain esimerkki, eli jos TLB:stä tarkistetaan yhdeksän vähiten merkitsevää bittiä L1 TLB-haussa se muodostaa yhdessä 12 bittisen offsetin kanssa 21 bittisen alueen prosessin lineaarisessa osoiteavaruudessa. Toki koko tuo osoitteiston käännökset eivät ole yhtä aikaa TLB:n muistissa vaan ainoastaan TLB-entryjen mukainen määrä, eli jos esimerkiksi on se 128 4KB:n sivua TLB:ssä tuo kahden megan alue pitää sisällään 128 erillistä 4KB:n aluetta joiden kohdalla osoitemuunnos löytyy TLB:stä(ja vastaavasti 32 KB:n välimuisti pitää sisällään 64 erillistä 512 bitin aluetta) . Ja toki koko TLB-osuma pitää tarkistaa jossain vaiheessa(ennen storea) mutta tässä esimerkissä meillä on 2megan alue jolla ohjelma voi operoida ilman että TLB-muunnoksessa tulee vääriä muunnoksia noiden 9 virtuaalimuistibitin avulla.
Niin kuka on pihalla. Kaikki ohjelmistotko on erotettu erillisiin muistiavaruuksiin? Tuossahan oli esimerkkikin, webbiselaimen javascript joka pyörittää ulkopuolista koodia isäntäohjelman prosessissa, tälläisissä tapauksissa ulkopuolinen koodi voi täysin vapaasti lukea isäntäohjelman kaiken datan – ja tiedemme myös sen että selaimissa "korjaus" on toistaiseksi ajastimien tarkkuuden lasku tasolle jolla cachelinjojen nopeuden vakoilu on ainakin vaikeaa.
Mites esimerkiksi kaikki kääntäjien läpi ajettava koodi? JIT-kääntäjän pitäisi pyöriä eri muistiavaruudessa kuin ajettava koodi – mahtaakohan hidastaa 😀
Juu ei toimi. Virtuaalimuistin oikeusbitit eivät ole ongelma vaan se että Intelillä data prefetch tuo cachelinjoihin muutoksia myös pieleen spekuloiduissa muistihaussa, meltdown-vuodossa luetaan vain loopissa haluttua osoitetta ja data putkahtaa cacheen välittämättä edes oikeusbiteistä. Tämä on se ongelma mihin Intelin epätoivoiset mikrokoodipäivitykset yrittävät tuoda korjausta, mutta se vaatii myös ohjelmien uudelleenkäännön yms. skeidaa jotta homma saadan pelaamaan -> ainakin serverimaailmaan tuollaiset prossut on kyllä "rikki".
Spectressä sentään pitää huijata branch-predictor osoittamaan haluttua dataa, vähän sentään vaikeampi hyödyntää kuin suoraan pyytämällä haluamaansa dataa.
No väärällä mutta onhan tuossa kirjoituksessakin lähtötiedot väärin, 64 tavun cachelinjat on tietysti 9 bitin osoituksella eikä 8:n.
:facepalm:
Missään ei ole välimuisteja, jotka olisivat yksinkertaisempia kuin read-only-suorasijoittava välimuisti, jonka toiminnan selitin edellisessä viestissäni.
:facepalm:
Et siis ilmeisesti edelleenkään ymmärrä ihan perusteita siitä, mitä koko virtuaalimuistisivun käsite tarkoittaa, eli siis mikä on koko sivutukseen perustuvan virtuaalimuistin toimintaperiaate
Yritän nyt vielä vääntää senkin rautalangasta. (lisäselvennys vielä notaatiostani: 0x luvun alussa tarkoittaa tässä heksalukua, yleisimpien ohjelmointikielten notaatio, ohjelmointia kokemattomalle voi olla uusi juttu)
Sivuttavan virtuaalimuistin mappayksessa virtuaalisen ja fyysisen muistin välillä mäppäys tehdään sivu kerrallaan. Virtuaalisen musitin sivuja mäpätään osoittamaan vapaasti mihin tahansa fyyisen musitin sivuihin. Eli homma toimii siis täysin sivun koon granulariteetilla.
Muistiosoite koostuu kahdesta osasta: Sivun osoite (ylimnmät bitit) ja offset sivun sisällä (alimmat biit).
Jos muistiosoite on vaikka 0x00000034, sen sivun osoite on 0x00000000(josta voidaan impliittisesti jättää alimmat bitti pois, koska ne on aina nollia, eli 0x00000 ja offset sivun sisällä 0x34.
Jos muistiosoite on vaikka 0x00001034, sen sivun osoite on 0x000001000 (josta voidaan implisiittisesti jättää alimmat bitit pois, eli 0x00001, ja offset sivun sisällä 0x34.
jos muistiosoite on vaikka 0x12345678, sen sivun osoite on 0x12345000 (josta voidaan implisiittisesti jättää alimmat biti pois, eli 0x12345), ja offset sivun sisällä 0x678.
Virtuaalimuistia ei voida olla mäpätty osoittamaan siten että se alkaa jostain fyysisen muistisivun puolivälistä ja jatkuu seuraavan fyysisen muistisivun puoliväliin. Vaan se on mäpätty koko siihen sivuun.
Tämä tarkoittaa sitä, että se virtuaaliosoitteen muunnos fyysiseksi osoitteeksi ei koska niihin offsetteihin. Se, että joku osoite on sivun 576. osoite en aina sivun 576. osoite, riippumatta siihen, mistä sivusta on kyse.
Tämän takia mitään osoitteenmuynnosta ei tarvi tehdä niille alimmille 12 bitille. Ne on AINA VALMIIKSI OIKEAT KOSKA NE ON AINA SAMAT SEKÄ FYYSISELLE ETTÄ VIRTUAALISELLE OSOITTEELLE
Ensinnäkin,se, millainen assosiatiivisuus itse välimuistilla on ja millainen assosiatiivisuus TLBllä on on täysin erillisiä asioita.
Toisekseen, lähdet siitä virheellisestä lähtöoletuksesta, että täysin assosiatiivinen välimuosti olisi jotenkin normaalitilanne, josta "lähdetään liikkelle ja johon muita verrataan".
Tämä on väärä lähtöoletus, ja ne on hyvin harvinaisia, koska niiden osuman tarkastaminen yhtään suuremmasta välimuistista on äärimmäisen kallis operaatio(koska pitää verrata tagibittejä välimuistin joka ikisestä linjasta). Suorasijoittava on se yksinketainen perustapaus, ja muut on sitä että siitä lähdetään parantamaan.
Mitähän nyt oikein tarkoit sanalla "viitata" tässä….
… ei voida, koska pitää tarkistaa, että siinä välimuistissa sen indeksin kohdalla on juuri sen osoitteen data, jota halutan hakea. Eikä jonkun uun sellaisen osoitteen data, jonka alimmat biti sanoo että se menee siihen samaan paikkan välimusitissa, jos se on välimusitissa.
Haukut Inteliä siitä että intel ei ole suojannut prosessoreita hyvin hankalilta sivukanavhyökkäyksiltä ja itse olet valmis tekemään L1-datakakun, joka suostuu antamaan aivan väärän osoitteen dataa etkä näe tässä mitään ongelmaa
:facepalm:
:facepalm:
Tämä alkaa mennä jo kategoriaan "not-even-wrong".
Nykyaikaisissa prosessoreissa on 48-bittiset virtuaalisoitteet(*). Koska tahansa voi tulla osoituksia mihin tahansa näistä virtuaaliosoitteista. Ja mikä tahansa niistä virtuaaliosoitteista voi osoittaa mihin tahansa fyysesssä musitissa (paitsi että alimmat 12 bittiä on aina fyysisessä ja virtuaalisooitteessa samat). Kaikessa kirjanpidossa ja osoitteistuksessa pitää koko ajan ottaa tämä huomioon.
Ja sillä, mitkä entryt sieltä L1-DTLBstä löytyy, ja mitkä se joutuu hakemaan kauempaa, ei ole mitään tekemistä sen kanssa, mitä kirjanpitoa L1D-välimuisti tarvii. VIPT-välimuisti aloittaa accessinsa täysin TLBstä riippumatta(koska tarvii siihen accessiin aloittamiseen vain nitä alimpia 12 bitiä). Ja osuman tarkistamiseen tarvii sen koko fyysisen osoitteen, koska sen pitää pystyä erottamaan mikä tahansa fyysinen osoite toisistaan.
Se, että voidaan tehdä jonnekin 21 bitin alueelle muistisoituksia ilman että sen sisällä sekoaa mitään ei lohduta yhtään mitään, koska aina voi tulla accesseja sen 21 bitin alueen ulkopuolelle. Jos yritetään lukea osoitteesta 0x12345678 mutta saadaankin osoiteen 0x22345678 niin sitten prosessori toimii väärin.
Niinkuin oikeasti. Opettele ohjelmoimaan. Ensin jollain korkean tason kielellä, sen jälkeen assemblyllä. Sen jälkeen voisit ehkä alkaa joskus ymmärtääkin jotain.
(*) 64-bittisen pointterin ylimmät 16 bittiä on käyttämättä, voidaan myöhemmin ottaa käyttöön muuttamatta userspace-softia, vaatien muutosta vain kerneliin.
:facepalm:
Miten saat 64 tavun välimuistilinjoista 9 osoitebittiä?
Ei sen vapavalintaisen tavun osoiittamiseen sieltä tarvita kuin 6 bittiä.
Vai olet vuosia vängännyt vaikka mistä tietämättä edes niin yksinkertaista perusasiaa, että muistiositteet osoittaa tavuihin eikä bitteihin?
Ai näin korkealle tasolle pitää nousta? 2^9=512 bittia = 64tavua.
Puhuin siis TLB-optimoinnista, L1-cachen kanssa joko dekoodataan joka muistiviittauksessa koko virtuaalimuistiosuus TLB:stä tai luotetaan siihen että koodin tällähetkellä pyörivä osa mahtuu pienempäänkin muistijälkeen. Tästä oli polemiikkiä aikanaan software vs hardware TLB toteutuksissa kun tosiaan TLB:n osittainen dekoodaus avaa mahdollisuuksia side-channel vakoilulle mutta ongelma ei ole kovin suuri, hallittavissa ohjelmiston ja käyttöjärjestelmän suunnittelulla. Intelillä kuitenkin taisi mennä aika kauan vakuuttaa serverpuoli ratkaisun turvallisuudesta, ja sitten se kusee näin.
Käyttöoikeuden tarkastus olisi yksi bitti – tämänkin Intel on optimoinut pois, kertoneeko jotain siitä kuinka kriittinen TLB:n optimointi on.
Ja siis tämä on vain TLB:n nopeusoptimointi, kun on dekoodattu x määrä bittejä että TLB:n osumaprosentti on käyttötarkoitukseen riittävä voidaan mahdollisesti löydettyä osoitetta lähteä etsimään cachesta. TLB:n dekoodaus jatketaan loppuun sitten yhdessä cachen haun kanssa ja jos muistiviittaus tuli aluksi dekoodatun alueen ulkopuolelta tuli TLB miss ja perutaan tehdyt haut.
Jotenkin tämä keskustelu muistuttaa minua jostain aikaisemmasta väännöstä tämän aiheen ympärillä… siis, että keskustelussa on kaksi osapuolta, joista vain toinen tietää oikeasti mistä puhuu. Hieman rasittavaa edes sivusilmällä seurata tällaista…
Esimerkissäsi on tietoalkion koko. Jos on 2 kpl tuon kokoista(tai minkä kokoista tahansa) tietoalkiota, niihin viittaamisiin riittää yksi bitti. Se kuinka moneen alkioon pitää viitata määrittää indeksointiin tarvittavien bittien lukumäärän.
Edittiä eli korjausta.
:facepalm:
Missään viimeisen n. 50 vuoden aikana valmistetussa CPUssa normaalia muistia ei osoiteta bitti kerrallaan vain tavu kerrallaan.
Tämä jos mikä on ihan tietotekniikan alkeisasiaa.
(Ja jos jossain yli 50 vuotta vanhassa tietokoneessa muistiosoitteet osoittavat yksittäisiin tavuihin eikä bitteihin, C/C++-kieli ei toimi niissä, koska C-kielen speksi sanoo, että sizeof(char) == 1 ja kaikki osoitteenlaskenta mitä ohjelmissa tehdään pohjaa tähän)
(muutamassa hyvin harvinaisessa signaaliprosessorissa muistia osoitetaan esim. 16-bittinen sana kerrallaan, mutta tällaisetkin arkkitehtuurit ovat erittäin harvinaisia. Ja niillä siis joko char-tietotyyppi on 16-bittinen tai sitten 8-bittisten charrien accessoiminen pointtierien päästä vaatii monen käskyn verran ylimääräistä maskausta ja shiftausta)