
Prosessorimarkkinat ja etenkin Intel tarpoivat reilu vuosi sitten tietoturvaongelmasta toiseen, kun prosessoreista löytyi lukuisia uusia sivukanavahyökkäyksiä. Sittemmin haavoittuvuuksia ja hyökkäysvariantteja on paljastunut lisää, mutta isommilta kohuilta on vältytty.
Nyt Intelin prosessoreista on löytynyt neljä Microarchitectural Data Sampling -termin (MDS) alle niputettua vakavaa haavoittuvuutta. Haavoittuvuuksien tarkat tunnisteet ovat CVE-2018-11091, -12126, -12127 ja -12130. Hollantilainen Vrijen yliopisto Amsterdamissa on julkaissut tiedot haavoittuvuuksia hyväksikäyttävistä RIDL- ja Fallout-hyökkäyksistä, jonka lisäksi Itävaltalainen Grazin teknillinen yliopisto julkaisi tiedot kolmannesta ZombieLoad-hyökkäyksestä.
Intelin mukaan haavoittuvuudet ovat läheistä sukua aiemmille sivukanavahaavoittuvuuksille ja ne koskevat yhtiön kaikkia Core-arkkitehtuurin prosessoreita 8. ja 9. sukupolven Core – sekä toisen sukupolven Xeon Scalable -prosessoreita lukuun ottamatta. Tutkijoiden mukaan Fallout-hyökkäys toimii kuitenkin uusimmilla Coffee Lake Refresh -prosessoreilla jopa aiempia sukupolvia tehokkaammin. Aiempien sivukanavahyökkäyksien tapaan haavoittuvuudet mahdollistavat datan vuotamisen prosessille, jolla ei ole siihen oikeutta. Uusista haavoittuvuuksista tekee aiempaa vakavampia se, että ne mahdollistavat datan vuotamisen prosessorin puskureista, kun aiemmat haavoittuvuudet vuotivat dataa vain välimuisteista.
Intel tulee julkaisemaan vanhemmille prosessoreilleen korjauksia MDS-haavoittuvuuksiin mikrokoodipäivityksinä. Yhtiön mukaan korjausten ei pitäisi vaikuttaa suorituskykyyn huomattavasti ainakaan useimmissa käyttötilanteissa, kunhan vastaavat päivitykset on ajettu myös käyttöjärjestelmään. Pelkät mikrokoodipäivitykset eivät tule kuitenkaan tuomaan täyttä suojaa, vaan tietyissä tapauksissa suositeltava ratkaisu on poistaa Hyper-threading-teknologia käytöstä. Google onkin ilmoittanut sen Chrome OS:n version 74 tulevan poistamaan HT:n oletuksena käytöstä.
Lähteet: Intel, Kyberturvallisuuskeskus, MDS Attacks, ZombieLoad, Tom’s Hardware, BleepingComputer
Osa välimuistia se store-puskuri on. Ja store-puskuri pitää olla vaikka prosessori suorittaisi käskyt järjestyksessä, store odottaa puskurissa kun muistiosoitteen fyysinen osoite ratkaistaan, cache-linja luetaan välimuistiin ja hankitaan cache-linjalle eksklusiivinen käyttöoikeus, ellei kaikki em. asiat ole jo valmiina. Se Mesi-protokolla…..
Intel patentoi tuon store-forward rakenteen jossa muisti forwardoidaan ennen sen fyysisen osoitteen selvittämistä, josta patentista sitten oli helppo koodata muutama uusi sivukanavahyökkäys.
Löytyy esimerkiksi siitä Fallout pdf:stä hyvin purettuna.
L2:n ollessa inclusiivinen L2:ssa on täydet tagit L1:n joka linjasta. L1:n osoittamiseen ei tarvita täyttä tagia eikä TLB-muunnosta, data haetaan osittaisella tagilla jonka osumatarkkuus on lähes täydellinen ja L2 tarkistaa osuman. AMD on speksannut mikrotaginsa hyvin, mikrotagi voi mennä kumpaankin suuntaan pieleen, Intelin toteutus näyttää että mikrotagin mukaan data haetaan ja se vain invalidoidaan false hitissä. Intelin ratkaisussa taas liian myöhään, AMD:n toteutus on erilainen joko siltä osin että invalidointi saadaan tehtyä aikaisemmin tai sitten vain spekulatiivinenkin koodinajo kunnioittaa käyttöoikeuksia.
RIDL and Fallout: MDS attacks
katso liitettä 231520
Jospa katsoisit itse omaa postamaasi kuvaa.
Tehtävä: Etsi kuvasta "Store & Forward Buffer".
Täsmä on tosiaan yksi käyttötarkoitus store-puskurille myös, mutta:
välimuisti ei pakota siihen, että prosessorissa tarvii olla store-puskuri. Koko prosessorin liukuhihna voisi ihan hyvin stallata tässä tilanteessa, jolloin mitään puskuria ei tarvita. Tämä olisi toki hyvin hidasta.
Se, että A on yksi syy B:n olemassaoloon ei tee B:stä osaa A:ta.
Se, että auton valot tarvii sähköä ei tee auton akusta osaa auton valoja.
:facepalm:
Edelleenkin olet pihalla siitä, miten joukkoassosiatiivinen cache (tai välimuistin kirjanpito ylipäätään) toimii.
Kun siellä (intelin 8-tie-joukoassosiatiivisessa) L1D:ssä voi olla talletettuna kahdeksan sellaisen osoitteen datan, joiden osoitteen alimmat bitit ovat täysin samat. Ja on hyvin yleinen tilanne, että siellä on talletettuna 2-3 sellaisen osoitteen datat, joiden alimmat bitit on täysin volla
Nämä pitää pystyä erottamaan toisistaan. Sinulla ei olisi mitään keinoa tietää, minkä L2-tien tagia pitäisi katsoa, kun siellä L2ssa:kin eri teissä on tällöin kahdeksan sellaisen osoitteen data, jonka alimmat bitit on samat.
Toisekseen; Se, että L1n accessoimiseksi pitäisi aina alkaa lukemaan L2n tageja olisi todella hidasta.
Kyllä, patentoi store-forward-rakenteen. Tällä ei ole mitään tekemistä sen itse L1D-välimuistin rakenteen ja kirjanpidon kanssa.
Sieltä löytyy viittaus viiteen eri patenttiin. Et sitten viitsinyt kertoa, mistä niistä patenteista puhut.
Patentit, mitkä tuossa fallout-paperissa mainitaan:
US5717882A – Method and apparatus for dispatching and executing a load operation to memory – Google Patents
Tämä on vuodelta 1996, 32-bittisten prosessoreiden aikaa.
Täällä puhutaan tageista nimenomaan seuraavaa.
ja
12 alinta bittiä on osoite sivun sisällä, seuraavat 20 sivun osoite.
US6378062B1 – Method and apparatus for performing a store operation – Google Patents
Tässäkin sanotaan:
US7603527B2 – Resolving false dependencies of speculative load instructions – Google Patents
Tässä puhutaan datariippuvuuksien selvittämisestä, ei osoitteen selvittämisestä.
US5680565A – Method and apparatus for performing page table walks in a microprocessor capable of processing speculative instructions – Google Patents
Tämä on muinainen patentti, joka ei puhu yhtään mitään L1D-välimuistin tageista.
Seuraava on ilmeisesti patentti, mistä puhut:
US20140189250A1 – Store Forwarding for Data Caches – Google Patents
Tämä patentti ei puhu yhtään mitään siitä, miten L1Dn tagit on säilötty.
Siellä puhutaan vain, että SAB:tä indeksoidaan virtuaaliosoitteilla. Mutta SAB on eri asia kuin L1D-välimuisti. SAB on sen store-puskurin osoitepuoli (datapuoli on nimenltään SDB).
Että niin, mikään noista fallout-paperin viittaamasta patentista ei puhu yhtään mitään mistään L1D:n tagaamisesta pelkästään osoitteen alimpien bittien mukaan.
Jospa nyt oikeasti opettelisit, mitä VIPT (virtuaally indexed physically tagged) tarkoittaa. Olen sitä sinulle jo moneen kertaan täällä aiemmin yrittänyt selittää, mutta koskaan ei ole uponnut kaaliin.
Sekoitat sen, että pelkkiä alimpia bittejä käytetään cachen indeksointiin siihen, että ne riittäisivät osuman tarkastamiseen ja datan hakemiseen välimuistista.
Se TLB-lookup tehdään rinnakkain sen tag-accessin kanssa ja molemmat valmistuu samaan aikaan jolloin niitä molempia voidaan kätevästi verrata keskenään.
Aahh. hkultala vs Sami Riitaoja väittely käynnissä. Nyt popparit….ai jäivät kauppaan.:-( Huono homma.
Jos nyt katsotaan asian positiivisia puolia, niin erittäin hieno homma että tällaisia väittelyitä käydään. Suuri osa jutuista menee yli hilseen mutta ehkä näistä oppii jotain uutta suorittimista – aka prosesoreista.
8-way store ja load bufferitkin ovat, kahdeksan mahdollista vaihtoehtoa sielläkin on tarjolla. Intel tuon patentin mukaan tekee 8-bitin VA-PA muunnoksen joka tässä tapauksessa tarkoittaa cachelinjojen fyysistä yksilöintiä, AMD käyttää hashia VA biteistä, bittimäärä lienee samaa luokkaa. Ihan vaan matemaattisia malleja, 32 kilotavua jaettuna megan avaruuteen pitää valheelliset osumat harvassa. Ja Fallout näyttää että sataprosenttinen mikrotagin osumatarkkuus ei ole tarpeellinen, valheelliset osumat vain invalidoidaan myöhemmin.
Ja kyse on siitä että L1:n accessoimiseksi ei tarvitse haravoida kuin nuo mikrotagit, koko tagin tarkastus voidaan jakaa useammille kellojaksoille eikä tarvita kuin yksi vertailu – energiaa säästyy.
Ja Zenin toiminta on speksattu että L2 paikkaa L1:n mikrotagit, Intelillä TLB hoitanee tuon kun L2 ei ole inklusiivinen.
Ja näitähän prossuvalmistajat eivät dokumentoi, voi vain spekuloida. Intelin prossuissa on 8-bitin utag store bufferiin, haarautumisenennustus myös toimii parinkymmenen bitin avaruudessa mutta L1 accessit veivattaisiin kuitenkin läpi täydellä osoitemuunnoksella ja täyspitkillä tageilla – AMD:llä taidettiin toimia näin ennen Zeniä…..
Täytyy sanoa, että näistä oppii sivusta seuraavana itsekin paljon. :tup: