Intelin prosessorit ovat saaneet viime vuosina ryöpytystä tietoturvaongelmistaan, mutta tällä kertaa on AMD:n vuoro. Grazin teknillisen yliopiston tutkijat ovat onnistuneet takaisinmallintamaan AMD:n L1D-välimuistin ennustajayksikön ja hyödyntämään sen kautta saatua tietoja muiden haavoittuvuuksien kanssa.
”Take A Way”:ksi ristitty hyökkäys sisältää todellisuudessa kaksi erillistä hyökkäystä, Collide+Proben ja Load+Reloadin. Haavoittuvuus koskee kaikkia AMD:n Bulldozer- ja Zen-johdannaisia arkkitehtuureita. Haavoittuvuudet on testattu toimiviksi myös laboratorion ulkopuolelle Epyc-pilvipalvelimissa hyödyntämällä JavaScriptiä Chrome- ja Firefox-selaimilla.
Tutkijoiden mukaan takaisinmallintamalla L1D-välimuistin ennustajan (L1D cache way predictor). Saatujen tietojen perusteella toteutettu Collide+Probe-hyökkäys mahdollistaa muistihakujen tarkkailun ilman, että hyökkääjän tarvitsisi tietää tarkkailtavaa muistiosoitetta, kun kaksi prosessia käyttää samaa ydintä. Load+Reload puolestaan mahdollistaa ennustajan hyödyntämisen paljastamaan, onko samaa ydintä käyttävä prosessi käyttänyt tiettyjä muistiosoitteita.
Kehittäjien mukaan Take A Way vuotaa kutienkin vain pieniä määriä metadataa, eikä siten ole verrattavissa esimerkiksi Spectre- ja Meltdown-hyökkäyksiin. AMD puolestaan on kommentoinut Tom’s Hardwarelle, että se ei varsinaisesti laskisi näitä uusiksi hyökkäyksiksi, mutta ei kiellä haavoittuvuuden olemassaoloa. Yhtiö ei ole kertonut vielä, miten se tulee korjaamaan asian, mutta tutkijoiden mukaan erilaisia korjaustapoja olisi sekä rauta- että ohjelmistopohjaisesti olemassa useita.
Netissä nousi myös pienoinen kohu, kun tutkijoiden huomattiin saavan osan rahoituksestaan Inteliltä. Samat tutkijat ovat kuitenkin julkaisseet myös useita Inteliä koskevia haavoittuvuuksia, eikä mikään tapauksessa anna syytä epäillä rahoituksen vaikuttaneen tutkimukseen tai että Intel olisi kehottanut tutkimaan asiaa.
Lähde: Tom’s Hardware
Lähde: https://www.amd.com/en/corporate/product-security
Missäs tälläisen suorituskyvyn heikkenemisen sitten huomasit?
Tuon prossun suorituskyky kun ei 4/8 vuoksikaan ole aina välttämättä riittävä joten ytimien ja yleisen suorituskyvyn puute softissa/peleissä selittyy muulla kuin Spectrellä ja on siis täysin normaalia kyseiselle prossulle.
Alt+tab sovelluksen pyöriessä taustalla aiheutti huomattavasti isomman tehohävikin, kuin aiemmin. Jos vähänkin oli chromea tai discordia käytössä samaan aikaan, niin discordin toiminta heikkeni selvästi. Intel myös myönsi että vanhemman arkkitehtuurin prosessoreihin tehohävikki tuli vaikuttamaan eniten. Näistä löytyi myös paljon testejä spectre päivityksen ennen/jälkeen.
Nykyään voi huoletta unohtaa vaikka chromen 16 linkillä auki taustalle pyörimään eikä vaikuta esim. Discordin tai pelien toimintaan millään lailla.
Se, mitä pitää tarkkailla on, kuinka paljon nämä paikat vaikuttavat prosessorin nopeuteen. Ihan hatusta heitettynä mutuvakiolla Intelin koostetut tietoturvapaikat ovat hidastaneet prosessoreita yhteensä 10-15%. Se on hirveän paljon. Phoronixilla oli tästä testi pari haavoittuvuutta sitten.
Nytkin kiinnostaa vaan se, että otetaanko L1 cache prediction pois päältä, tehdäänkö jotain pieniä mitigointeja vai annetaanko asian olla? Ts. paljon prosessorini kärsii tästä paikasta?
Ettei vaan olisi alkanut olemaan Windows solmussa? Nimittäin itselläni ei ollut edes 2600k:lla mitään tuollaisia ongelmia. Kyllä Ryzen toi sitli kivasti lisää tehoja pelailuun ja ennen kaikkea jäi vielä reserviin. Pääsasia tietysti että olet päivitykseen tyytyväinen -eteenpäinhän tuo kehitys on mennyt kuitenkin (vähintään tietoturvan näkökulmasta)
Intelin paikkaukset ovat hidastaneet niitä kotikäyttäjälle selvästi vähemmän, muutaman prosentin luokkaa, mikä on melko merkityksetön, mutta palvelinkäytössä selvästi enemmän, jopa kymmeniä prosentteja.
Ratkaisevaa on prosessorin käyttötarkoitus. Kotikäyttäjälle nämä on edelleen melko merkityksettömiä, mutta datakeskuksissa on tavittu paljon lisätehoa korvaamaan näitä.
Offtopic, mutta tästä tuli kieltämättä mieleen kuinka paljon pienet muutokset vaikuttaa isossa skaalassa…
The Linux Kernel Seeing Backport Progress Finally For The "$1.5 Million Dollar Bug"
Tuskin tehdään yhtään mitään, varsinaisia haavoittuvuuksiahan ei löydetty.
Ja kyse ei varsinaisesti ole way-predictorista joka olisi kytkettävissä pois päältä vaan L1-cache on tagattu vain tuolla microtagilla. Way predictor on aikaisemmin ollut vihje jonka mukaan cachesta on tarkastettu vihjeen osoittama linja ensin ja loput jos ei tullut osumaa. Microtagilla AMD:n tapauksessa cache-setistä tarvitsee tutkia maksimissaan vain 8 bittiä jokaisesta setin 8:sta linjasta joten kaikki linjat tutkitaan kerralla ja hudin tulessa siirrytään L2:een. Eli jos jotain kytkettäisiin pois niin se olisi koko L1-cache.
Mitä tuossa nyt on "haavoittuvuuksia" löydetty niin tietämällä tuon microtagin hash-algoritmi on helppo tehdä koodinpätkä jolla saadaan osittaisia muistiosoitteita(vähiten merkitsevät 28 bittiä) dekoodattua kernelistä. Toki hash-algoritmin tietäminen mahdollistaa haavoittuvuuksien etsimisen prosessorista, ja em. artikkelin kirjoittanut ryhmä oli niitä etsinytkin mutta ainakaan vielä mitään ei ollut löydetty eli AMD:n varautuminen sivukanavahyökkäyksiin käsittää muutakin kuin tuon yksinkertaisen microtagin hashauksen.
Ja samaan aikaan Inteleistä löytynyt hieman vakavampi ongelma, jota ei voida korjata.
https://arstechnica.com/information-technology/2020/03/5-years-of-intel-cpus-and-chipsets-have-a-concerning-flaw-thats-unfixable/
Sille on ihan oma uutisensa ja ketjunsa: Intelin piirien tietoturvasta vastuussa olevasta CSME:stä löytyi ongelma jota ei voida korjata – io-tech.fi / Intelin piirien tietoturvasta vastuussa olevasta CSME:stä löytyi ongelma jota ei voida korjata
Onneksi ei tullut hommattua AMD prossua
Höpöhöpö. Olet näköjään edelleenkin pihalla siitä, miten välimuistin kirjanpito toimii.
Edelleenkään; se, että välimuisti tagattaisiin millään muulla kuin täysikokoisella tagillä johtaisi siihen, että ei tiedettäisi, mitä dataa siellä välimuistissa on, ja luettaisiin sieltä väärän osoitteen dataa. Siellä on pakko olla jossain ihan täysimittainen tag jotta tiedetään varmuudella, että data jota välimuistista ladataan on varmasti se oikea data.
Yritin tätä selittää sinulle jo joskus kauan sitten, mutta ei tunnu uppoavan sitten millään.
Tuon microtagin merkitys on nimenomaan toimia way predictionina; Ensin ladataan kaikkein kahdeksan wayn microtagit oikeasta indeksistä (indeksi on osoitebitit 6-11, eli ollaan neljän kilotavun sisällä, eli siihen riittää virtuaaliosoite) , ja niiden perusteella tarkastetaan osuma (verrataan microtagia hashiin koko virtuaaliosoitteesta).
Mikäli löytyy osuma jostain waystä, valitaan se way, ladataan rinnakkain siitä waystä data sekä että varsinainen tagi. Ja siinä vaiheessa kun nämä on saatu ladattua, on myös virtuaaliosoitteen muunnos fyysiseksi osoitteeksi valmis, ja voidaan tehtä tarkastus täyteen fyysisillä osoitteilla toimivaan tagiin.
Tässä nyt menee välillä jotain oikein, tosin syy on ymmärretty väärin.
Zenin L1:n rakenne tosiaankin on sellainen, että mikäli siinä tulee way prediction-huti, niin sitten mennään kerralla L2een asti, ja ladataan data sieltä. Ja syy tähän on se, että tilanteet joissa se data löytyisi jostain muusta L1-waystä ovat äärimmäisen harvinaisia, johtuen mm. seuraavasta rajoitteesta:
[quote="AMD optimization manual]
It is also possible for two different linear addresses that are NOT aliased to the same physical address to conflict in the utag, if they have the same linear hash. At a given L1 DC index (11:6), only one cacheline with a given linear hash is accessible at any time; any cachelines with matching linear hashes are marked invalid in the utag and are not accessible
[/quote]
Eli siis, meillä on neljä mahdollista skenaariota:
1) Halutun osoitteen data on L1-välimuistissa siinä wayssä mikä ennustettiin. Kaikki hyvin ja nopeaa. Hyvin yleinen tilanne.
2) Halutun osoitteen dataa ei ole ollenkaan L1-välimuistissa ja way prediction sanoo että sitä ei siellä ole. Tällöin pitää ladata se L2-välimuistista (seuraavaksi yleisin tilanne). Kaikki hyvin mutta tulee se ~8 kellojakson hidastus kun data ladataan L2-välimuistista (tai vielä pidempi, jos sitä ei ole sielläkään). Seuraavaksi yleisin tilanne.
3) Halutun osoitteen dataa ei ole ollenkaan L1-välimuistissa, mutta way prediction ennustaa väärin, ja sanoo että se löytyy waystä, jossa tosiasiassa on jotain muuta(false positive). Tämä tilanne huomataan siinä vaiheessa, kun ne oikeat täysikokoiset TAGit tarkastetaan, ja ne ei matchääkään sen fyysisen osoitteen kanssa, minkä osoitteenmuunnos virtuaalisesta fyysiseksi antoi antoi, ja tässä vaiheessa käynnistetään L2-access datan hakemiseksi sieltä. Jos niitä täysikokoisia TAGejä ei olisi ja tarkastettaisi, tässä tapauksessa ladattaisiin kiltisti mitään tajuamatta väärä data
4) Softassa on mappaus samalle samaan fyysiseen osoitteeseen useammalla eri virtuaaliosoitteella, mikä mahdollistaa eri hashin samaan fyysiseen osoitteeseen. Tällöin way prediction voi antaa false negativen; Sanoa että dataa ei löydy L1-välimuistista, vaikka se tosiasiassa on siellä Tällöin se ladataan L2-välimuistista, mikä on teoriassa epäoptimaalista.
Tämä tilanne on kuitenkin hyvin harvinainen; Usealla virtuaaliosoitteella on tyypillisesti mappays samaan fyysiseen osoitteeseen lähinnä vain kun kyse on jostain nollasivuista (käyttiksen optimointi muistinkulutuksen vähentämiseksi). Ja koska tämä tilanne on hyvin harvinainen, tuo "aina kun way prediction sanoo että data ei löydy L1stä, mennään suoraan L2een" on järkevä rajoite; Se, että ruvettaisiin välissä katsomaan niitä muita L1-waytä olisi ihan turhaa haaskausta niissä yleisissä tilanteissa tämän hyvin harvinaisen tilanteen nopeuttamiseksi.
OOO-prossussa se välimuistin tägi ei ole ensimmäinen arvaus joka suorituksessa tehdää, varmaan 90% todennäköisyydellä käsky joka sitä dataa lukee ei tässä vaiheessa tiedetä oikeaksi. Kuitenkin haluat olla 100% varma tägin oikeellisuudesta tasan heti tässä vaiheessa.
Juu, kyllä se välimuistin osuman oikeellisuuskin tarvitsee tarkistaa, mutta sen viimeinen tarkistusvaihe on kun siihen liittyvä data on siirtymässä store-queuesta välimuistiin. Siihen asti kaikki on peruttavissa. Näin tiedämme esimerkiksi Intelin prosessoreiden toimivan, Intel ei tätä tietysti ole kertonut mutta store-queuesta pääsee bugin takia microtagattu eri osoiteavaruudesta peräisin oleva data karkaamaan kun prosessori vaihtaa store-queuen moodia kahdesta threadista yhteen ja yhdistää puskurin. Ja aikaa store-queuen ronkkimiseen saadaan kun mukaan ujutetaan käsky jonka fyysisen osoitteen määrittäminen kestää kauan jonka ajan puskurin tarkistukset on jumissa.
Mikrotaggays on kuitenkin jo aika vanha asia, jos jaksaisit asiaa tutkia löytäisit paljon vaihtoehtoja asian toteuttamiseksi.
…
Tämänkin AMD on dokumentoinut. L1:stä tulee huti koska L1:n tageissa tulee huti. L2:sta tulee osuma mutta koska data on jo L1:ssä dataa ei lueta L2:sta vaan L2 korjaa L1:n tagin oikeaksi ja data luetaan L1:stä. Osuman nopeus on vastaava kuin L2:n osumalla.
Et ole ymmärtänyt koko täggäystä. Eli kaikki L1-wayt tarkastetaan, L1:ssä ei vain ole muuta kuin se microtag. L2 on inklusiivinen joten L2:ssa on myös L1:n data josta L2 voi löytää L1:ssäkin sijaitsevan datan vaikka microtag ei sitä löytäisi. Ja data on L1:n microtagin osuessa jo luettu ja käytössä L2:n tarkastaessa fyysisiä tageja.
Skenaario: L2-Välimuistiin on talletettu kaksi välimuistilinjaa, joiden fyysiset osoitteet ovat vaikka 4096 ja 8192.
Molemmat osoitteet osuvat välimusitissa indeksiin 0, mutta ne on L2-välimuistissa tallennettu eri way:hin.
Oletetaan että meiltä löytyy sellaiset virtuaalimuistimappaykset, että meillä on kaksi eri virtuaaliosoitetta, ja toinen niistä on mapatty fyysiseen osoitteeseen 4096 ja toinen fyysiseen osoitteeseen 8192, ja nämä molemmat virtuaaliosoitteet tuottavat saman hajautusarvon microtagille.
Jompi kumpi näistä on ladattu myös L1-välimuistiin.
Sinulla ei olemitään keinoa tietää, kumman osoitteen data L1-välimuistissa on.
Aivan hirmuinen ongelma siis ratkaista insinöörille. Sama bitti kertoo sille L2:lle että data on jo L1:ssä eikä sitä tarvitse uudestaan sinne ladata.
Microtageissä on paljon muutakin ratkaistavaa, nekun siis ovat virtuaalisia eivät lineraarisia ne on pidettävä prosessikohtaisina, todennäköisesti jopa threadikohtaisina ja tuhottava näiden vaihdoissa. Näitähän tässä on testattu ja AMD saanut toistaiseksi puhtaat paperit.
… ja sitten aina kun jotain ladataan L1-välimuistista, pitäisi käydä kelaamassa kaikkien L2-wayiden tagit läpi että jostain niistä löytyy sekä oikea tagi että vielä sen lisäksi "tämä löytyy L1-välimuistista" bitti ennen kuin latausta saa retirettää.
Välttääksesi lataamasta n. 32 bitin verran L1-tagia tasan yhdestä waystä haluat ladata n. 8 * 28 = yhteensä n. 224 bitin verran tagia (kaikista kahdeksasta L2-waystä), jotka vielä on selvästi kauempana siltä ytimeltä. Aika moninkertainen virrankulutus.
Jopa on loistava vaihtokauppa.
AMDn insinöörit eivät ole näin typeriä.
Kerrran siitä L2:sta on täytynyt tehdä inklusiivinen pitää siinä myös pitää yllä tietoa mitä dataa ei voi hävittää. Joten luulisin että samantien on tehty L1:n täydellinen varjokuva eli L1:n duplikaatit L2:ssa ovat vakiopaikoilla, samalla voidaan järjestää L2:n sisälle VIPT-tarkistus L1:n tageille jos halutaan.
Microtagit invalidoidaan jokatauksesssa -> L1 ei ole käytettävissä context switchissä. Paskan väliä kun muutaman kellojakson menettää kun data on L2:ssa. SMT:ssä kumpikin threadi omaa oman cache-id:nsä eli eivät jaa L1:n cachea vaikka ajavat samaa threadia.
Niin jos homma toimisi kuten luulet. Data luetaan sen microtagin perusteella ja siirretään eteenpäin, jos sallitaan toisen prosessin lukevan toisen dataa pystytään sivukanavahyökkäyksellä saamaan esille tietoa jonka pitäisi pysyä salassa.
Lisäksi dataa ei voi siirtää L2:sta L1:een ilman että kaikki L1:n tagit on tarkastettu. Eli joko tarkastetaan L1:n kaikki tagit tai L2 tekee sen, ja AMD:n L1:n microtagien tapauksessa on hyvinkin dokumentoitu että L2 suorittaa sen.
katso liitettä 356405
Paha sanoa mutta itse huomasin ainakin selkeän eron spectre -päivityksen jälkeen. Eräässä pelaamassani pelissä yksi raidi alkoi tökkimään melko ratkaisevasti, joten fps lasku oli ainakin hyvin huomattavissa. Kaikista selkein ongelma oli kuitenkin se, että jos Chromen jätti taustalle päälle, niin pelissä laski huimasti fps. Discordissa alkoi myös äänet pätkimään jos chrome oli taustalla päällä pelin pyöriessä.
Tätä ongelmaa ei ollut koskaan ennen spectre päivitystä.
Paperia lukiessa tuli vaan mieleen että ilmeisesti pitäisi olla muokattu kerneli että tätä pystyy edes tekemään ja tarvitsee myös fyysisen pääsyn koneeseen admin oikeuksin. Vai ymmärsinkö väärin?
Onko tälläkään siis mitään merkitystä mihinkään suuntaan vai onko tämä van keino kehittäjillä varmistaa että saavat kehitysrahansa myös jatkossa, johon myös Intel on lyönyt rahaansa jo pari vuotta.
19.2.2020 AMD osakkeen hinta ollut 58,90dolania, nyt 43,27dolans. Konkkaa kohti vääjäämättömästi.
Omalla kotikoneella skylake-s:llä en huomannut mitään vaikutusta, vaikka patchit on biosissa ja windowsissa. Tehonmenetyksen pitikin olla luokkaa 1-2%, mikä ei ole havaittavissa juuri missään kotikäytössä.
Palvelimissa sen sijaan olen nähnyt kaverien painivan reilusti yli 10% tehonpudotuksen kanssa. Tunnen ainakin kaksi tapausta jossa on jouduttu patchien jälkeen hankkimaan lisää palvelinkapasiteettia. Eli intel on siis saanut enemmän myyntiä noilla haavoittuvuuksilla. Tyhmää mutta totta.
Tietoturvatutkimuksella on aina merkitystä, varsinkin raudan kanssa kun sitä ei voida noin vain korjailla päivityksillä vaan homman pitäisi olla kerralla oikein. Se että kenen rahalla tutkimusta tehdään lienee toissijaista kunhan tulokset on julkisia ja todenmukaisia.
Ja jos Intel maksaisikin nimenomaan AMD:n raudan syynäystä (mistä ei siis tässä keississä ole kyse vaikka monet heti halusivat kun intelin nimi mainittiin tukijoissa) niin kyllä AMD silloin varmaan vaan kiittää Inteliä Zen4:n tietoturvan kehitystyöhön osallistumisesta. Mikäs sen kivempaa kuin saada joku muu maksamaan tuollaista testausta jota prossuvalmistajan soisi itsekin harrastavan?
Artikkeli techin linkkasi tomsin uutiseen jossa sanotaan:
"The researchers exploited the vulnerability via JavaScript run on Chrome and Firefox browsers, and also gained access to AES encryption keys. The exploit can also purportedly be used to penetrate cloud deployments in the data center. "
En itse ymmärtänyt mitenkään että tarvisi admin oikeuksia.
Papereissa taisi lukea jotenkin että tarvitsee paikallisen pääsyn, mutta ei tosiaan vaadi adminoikeuksia (unprivileged access).
En ole edelleenkään samaa mieltä. Nyt kun et uskonut tuota tompan uutista, niin avasin itsekin paperin.
Proof of concept hyökkäykset kappaleissa 5.2.1 ja 5.2.2. vaatii paikallista accessia, mutta proof of concept javascriptillä kappaleessa 5.2.3. ei vaadi mitään paikallista accessia.
Tuota paperia on muutenkin hankala lukea ja aiemmin tosiaan kommentoin puhelimella, niin en päässyt sitä uudelleen vilkaisemaan.
5.2.3 kohdassa mainitaan että sitä selaimissa tuokin on estetty ja siihen on jouduttu käyttämään javascriptissä high precision timeria. Viittaa vissiin tähän lähteissä (69): https://gruss.cc/files/fantastictimers.pdf eli 2017 vuoden vulnerabilityyn. Tuossa taas puhutaan että vaikka se olisi paikattu selaimista tuon julkaisun aikaan, niin se paikkaus ei olisi kuitenkaan riittänyt. Onko tuo sama javascript ongelma edelleen siis olemassa vielä vuonna 2020 selaimissa? Sitä en nyt jaksanut ottaa selvää, mutta aika vaikeaksi menee.
Intelille taas tuli uusi ja paha tälläkertaa, eli Meltdown-prossuista löytyi LVI-nimellä tunnettu haavoittuvuus jonka paikkaaminen vaatii ohjelmien käännöksen uusiksi ja potentiaalinen hidastus 2-19x…….
Lukasin tuota paperia. Jäin siihen käsitykseen, että nuo aiemmat paikkaukset eivät vaikuta tähän. Paitsi kotikäyttäjien selaimet voivat ilmeisesti olla turvassa patchien kanssa (mutu).
Näkisin että nyt on AMD:nkin prossut korkattu ja Intel on korkannut meltdownista/spectrestä asti kylmässä olleen samppanja pullon. Intel tukenut tutkijoita ruhtinaallisesti kuten paperissaan mainitsivat. Aika kovan työn tehneet selvittäessään dokumentoimattoman "cache-way prediction" -funkkarin toimintaa. Tosin en usko tutkijoiden olevan puolueellisia vaikka kohteena olikin vain AMD:n prossuja. Ne olivat vain hyvä haaste, kun muut ei niitä ole onnistuneet saamaan vuotamaan tietoa. Mutulla veikkaan että tämä sama haavoittuvuus on myös Intelin prossuissa, jos vain tutkisivat.
AMD:n kannattaisi muuttaa vastaustaan. Kyllä tää siellä pilvipalvelujen konesaleissa ainakin vähän vaikuttaa.
Siis onhan AMD:n prossuissakin sivukanavahaavoittuvuuksia ja mitä tällä saadaan ulos, joitakin bittejä osoitetietoja jotka todennäköisesti saadaan ulos ihan jo sillä jos prosessorissa on x-way associated cache – samoja osoitebittejä omaavat linjat ajavat toisiaan cachesta ulos. Tuo demo vuotaa kernel dataa oli ihan perus spectre jonka sivukanava oli vaihdettu tuohon AMD:n microtagiin perustuvaan – prossuihin voi nyt tehdä vaikka minkälaisia sivukanavia mutta salaisen datan vuotaminen on se varsinainen ongelma.
Tosin ei varmasti AMD:n osaltakaan ole kaikkea vielä nähty, esimerkiksi käskypuolen microtaggaus voi käyttää eri hashiä ja se on vielä avaamatta, datapuoli on paljon helpommin murrettavissa mutta käskypuoli on haavoittuvaisempi, ei välttämättä olisi typerää pistää käskypuolelle sopivasti erilainen häshäys. Mutta kohtuullisen vahva esitys AMD:llä toistaiseksi, tai oikeastaan toisinpäin – Intelin esitys on aika heikko, suurinpiirtein mitä ikinä kukaan keksiikään niin tuntuu aina toimivan Intelin raudalla.
Niin ja siis L1-osumat tarkistetaan tottakai täysin virtuaalisesti. L2 hoitaa vain L1-microtagin missit ja muiden ytimien coherenssipyynnöt fyysisten tagien mukaan, threadi lukiessaan virtuaalisesti tagattua L1:tä ei tarvii fyysisiä tageja mihinkään.
Microtagihan on vain sen takia että L1-haut täyden 48-bittisen tagin avulla olisi täysin turhaa tuhlaamista. Microtagin osuman varmistaminen 100% varmaksi ei tarvitse osoitteen kääntämistä vaan ainoastaan loppujenkin virtuaalibittien tarkistamista. Tätä kait voisi nimittää vaikka L0-tlb:ksi kun ko. tlb ei käännä osoitetta mutta yhdessä L1:n linjojen fyysisten tagien kanssa(jotka siis sijaitsevat vain L2:ssa) L1:eeen tulevien osumat myös kääntyvät 100% varmasti eli L1-cache hit ei voi missata TLB:tä. Näin nimetyn L0:n tlb::n käännöspasiteetti olisi siis L1:n koko ilman muita rajoituksia. Toimiiko piiri näin olisi ihan testattavissakin, en ole ikinä tosin kenenkään nähnyt asiaa tutkivan.
L1 siis luetaan täysin virtuaalisesti ilman TLB-käännöksiä, ja mitään virtuaalisen cachen ongelmia pois luettuna mitätön alennus hit-ratessa ei tule koska L1 on myös fyysisesti tagattu L2:ssa ja L2 hoitaa L1:n muistihaut. Ja tämähän on varsin simppeli systeemi, enköhän tätä ole koittanut vaihtelevalla menestyksellä selitellä vuosia sittenkin. AMD:n dokumentointi Zenin L1-cachen microtageista ja niiden käyttäytymisestä viittaa aika vahvasti että olisivat käyttäneet prossuissaan sattumalta juuri tätä schemeä – tosin esimerkiksi L0-tlb:tä ei ole dokumentoitu toimimaan em. tavalla mutta eipä noista ole muutenkaan kaikkea sielunelämää paljastettu kovinkaan tarkasti.