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

[aiwan]

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.

 

[Tege]

Helpompi tapa käyttää näitä reikiä https://gizmodo.com/researchers-find-new-ways-to-exploit-meltdown-and-spect-1823020029

 

[Griffin]

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ä..

 

[Nerkoon]

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

 

[Griffin]

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ä.

 

[Sami Riitaoja]

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).

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.

 

[Sami Riitaoja]

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ä.

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.

 

[Sami Riitaoja]

Vaikuttaa edelleen hyvin hitaalta ja epävarmalta nyhräämiseltä..

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.

 

[hkultala]

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.

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.

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.

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.

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.

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.

 

[hkultala]

Meltdown-attack onnistuu melkein keltä tahansa joka saa hello worldin koodattua.

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ä,

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.

... 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 vaihtaa perus-pentiumiin , 1. sukupolven Atomiin tai johonkin ARM Cortex A53/A55een. KAIKKI spekulatiivista suoritusta tekevät prosessorit ovat tasan yhtä lailla alttiita Spectren 1. variantille.

Ja KAIKKI suorituskykyiset CPUt tekevät spekulatiivista suoritusta.

 

[hkultala]

Intelin prosessorit tekevät täysin uskomattoman typeriä juttua MMU:n ja spekulatiivisten lukujen suhteen. KPTI korjaa vain kernelin suorat muistiosoitukset pois,

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.

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.

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.

 

[halcyon]

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.

 

[jsa]

Tätä keskustelua on ollut hauska seurata Kieltämättä muutamassa kohtaa on meinannut kahvit tulla ulos nenästä.

 

[Sami Riitaoja]

ps. yhdessä suunnittelemistani prosessoriytimistä on ollut myös välimuisti.

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.

Ja mitä tulee tuohon VIPT-indexsointiin, VIPT-indeksihalu voidaan tehdä yhdessä TLB:n dekoodaamisen kanssa, eli saadaan selville mikä osa x-way assosiactivesta cachesta tarvitsee tarkistaa. Tottakai varsinaiseen cachen tarkistukseen tarvitaan fyysinen osoitetieto jos data on fyysisesti mapattu cacheen eli TLB-muunnos.

 

[Sami Riitaoja]

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.

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

 

[Sami Riitaoja]

... ja niiden userspace-sandboksien murtamisessa se Spectre toimii tasan yhtä hyvin KAIKILLA superskalaarisilla prosessoreilla kuin intelin prosessoreilla; Userspace-sandboksit ei perustu virtuaalimuistin oikeusbitteihin.

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 tulee läpi josta sillä tehty toinen operaatio aiheuttaa cacheen muutoksen jolla voidaan tulkita datan sisältö. 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.

 

[Sami Riitaoja]

(ja millä ihmeen laskuopilla saat jotain 128 välimuistilinjaa johonkin?)

No väärällä mutta onhan tuossa kirjoituksessakin lähtötiedot väärin, 64 tavun cachelinjat on tietysti 9 bitin osoituksella eikä 8:n.

 

[hkultala]

No se on ollut paljon yksinkertaisempi kuin mistä nyt yrität vääntää juttua. Täähän ei ole edes mikään monimutkainen asia.

Missään ei ole välimuisteja, jotka olisivat yksinkertaisempia kuin read-only-suorasijoittava välimuisti, jonka toiminnan selitin edellisessä viestissäni.

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.

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

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).

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.

Jokainen TLB muunnos pitää kuitenkin suorittaa ennen muistiin viittaamista

Mitähän nyt oikein tarkoit sanalla "viitata" tässä....

joten L1-tlb haussa voidaan hyvin tinkiä kuinka monta bittiä TLB:stä tarkistetaan

... 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

, 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.

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.

 

[hkultala]

No väärällä mutta onhan tuossa kirjoituksessakin lähtötiedot väärin, 64 tavun cachelinjat on tietysti 9 bitin osoituksella eikä 8:n.

Miten saat 64 tavun välimuistilinjoista 9 osoitebittiä?

Ei sen vapaavalintaisen 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?

 

[Sami Riitaoja]

miten saat 64 tavun välimuistilinjoista 9 osoitebittiä?

Ai näin korkealle tasolle pitää nousta? 2^9=512 bittia = 64tavua.

 

[Sami Riitaoja]

... 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

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.

 

[L2K2]

Ai näin korkealle tasolle pitää nousta? 2^9=512 bittia = 64tavua.

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...

 

[Stephen Elop]

Ai näin korkealle tasolle pitää nousta? 2^9=512 bittia = 64tavua.

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.

 

[hkultala]

Ai näin korkealle tasolle pitää nousta? 2^9=512 bittia = 64tavua.

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ä C-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)

 

[hkultala]

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.

Perun sanani suosituksistani alkaa opettelemaan ohjelmointia.

On ehkä maailman kannalta parempi, että missään ei tulla koskaan ajamaan sinun kirjoittamaasi ohjelmakoodia.


Sinun mielestäsi prosessorin pitäisi vain luottaa siihen, että koodi nyt sattuu kerralla käyttämään vain n. miljardisosaansa koko muistiavaruudestaan.



Kerrotko mielipiteesi siihen, mihin 48-bittisiä virtuaaliosoitteita mielestäsi tarvitaan, jos ohjelmat mielestäsi käyttävät vain n. 21 bittiä muistia kerrallaan?, eikä prosessorin tarvitse toimia oikein, jos ohjelma käyttää yli 21-bitin verran muistia?

Tästä oli polemiikkiä aikanaan software vs hardware TLB toteutuksissa kun tosiaan TLB:n osittainen dekoodaus avaa mahdollisuuksia side-channel vakoilulle

Ei, kyse oli aivan eri asiasta. Sinä et vaan ymmärtänyt, mistä niissä puhuttiin.

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.

Suurin asia, mikä tässä kusee on sinun ymmärryksesi ihan yksinkertaisista asioista liittyen ihan perusasioihin muistiin liittyen.

Käyttöoikeuden tarkastus olisi yksi bitti

x86-64-tilassa tai PAE-päällä käyttöoikeuksille on kolme bittiä, vanhassa 386-moodissa 2 bittiä.

Siellä on erikseen lukuoikeus-bitti, kirjoitusoikeus-bitti ja execute-oikeus-bitti (joka puuttuu 386-tilasta, siinä se on yhdistetty lukuoikeusbittiin).

- tämänkin Intel on optimoinut pois, kertoneeko jotain siitä kuinka kriittinen TLB:n optimointi on.

Väärin. Se bitti luetaan sieltä ja käskyyn merkataan pystyyn flagi, että tämä luku on osoitteeseen, josta ei saa lukea. Se käsitellään kerralla siinä vaiheessa kun sen siitä lentävän poikkeuksen saa heittää aiheuttamatta väärään aikaan lentävää poikkeusta.

AMD joutuu käsittelemään tämän kahdessa osassa, ensin vain keskeyttää sen loadin ja myöhemmin heittää poikkeuksen.

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.

Ei sieltä TLBstä tarvita yhtään bittiä että se cacheaccess voidaan aloittaa, koska siihen accessin aloittamiseen tarvitaan vain niitä muistiosoitteen alimpia 12 bittiä, joita ei TLBstä tarvitse katsoa, koska ne eivät muutu osoitteenmuunnoksessa virtuaaliosoitteesta fyysiseksi.

Ja siinä vaiheessa kun tarkastetaan, tuliko osuma, ei voida luottaa yhtään mitään siihen mille alueelle accessi osuu, vaan pitää tarkastaa osoiteteen kaikki bitit, koska se voi tulla mihin tahansa osoitteeseen koko fyysisen muistin alueella.

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.

Sekoitat nyt TLBn ja datakakun toimintaa todella pahasti keskenään.

TLBn nopeusoptimoinneilla ei ole mitään tekemistä sen kanssa, miten L1D-välimuisti toimii.

Olet lukenut joskus jostain jonka olet ymmärtänyt väärin. Höpinästäsi ei kuitenkaan saa selvää, mitä olet oikeasti joskus jostain lukenut.

 

[TenderBeef]

Oliskohan oma topikki paikallaan tälle vääntämiselle? Jos tosiaan haluatte jatkaa vielä..

 

[tyson]

Oliskohan oma topikki paikallaan tälle vääntämiselle? Jos tosiaan haluatte jatkaa vielä..

Äläs nyt. Tämä on jo erään toisen foorumin ajoilta hyvin tuttua vänkäämistä näille kahdelle käyttäjälle. Napataan me muut popcornit esiin, otetaan hyvä asento ja luetaan mielenkiintoista teknistä väittelyä - vaikka itse olen jutuista pihalla kuin lumiukko.

 

[hkultala]

Niin kuka on pihalla. Kaikki ohjelmistotko on erotettu erillisiin muistiavaruuksiin?

Jos se koostuu monesta erillisestä prosessista, niin kyllä, tämä on juuri prosessin määritelmä.

Se, mikä on säikeen ja prosessin ero.
Saman prosessin eri säikeet näkee saman muistin, eri prosessit näkee eri muistin.

Eri prosessitkin kuitenkin pystyvät mappaamaan joitain yksittäisiä muistialueita niille yhteiseen jaettuun muistiin/allokoimaan muistia, joka on yhteistä toisen prosessin kanssa. Tämän kautta ei kuitenkaan näe toisen prosessin muuta muistia.

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

Silloin, kun ne pyörii samassa prosessissa, niitä ei suojata millään virtuaalimuistin lukuoikeusbiteillä, vaan sillä että sen tulkaten suoritettavan javascriptin tai javasciriptistä jitatun koodin muistiaccessit tarkastetaan ihan softalla, jokaisen taulukkoaccessin (jonka indeksejä ei pystytä kännösaikana tarkistamaan) eteen siihen JITattuun koodiin lisätään haarautuminen joka varmistaa että se ei accessoi muistia jota sen ei pitäisi accessoida.. (paitsi spekulatiivisesti

Tässä on kyse spectrestä, ei meltdownista, ja kaikki spekulatiivista suoritusta tekevät prosessorit ovat tälle aivan yhtä haavoittuvaisia.



Yleisesti ottaen: Muistinsuojauksessa ei suurimmasssa osassa tapauksista ole kyse siitä, että muistisivulle olisi laitettu lukukieltonitti päälle, vaan siitä, niitä sivuja, joita softan ei pidä pystyä lukemaan ei ole edes koskaan mäpätty sen muistiin.

Ihan turhaa tuhlata muistiakin sivutauluihin, joiden kautta ei koskaan voida accessoida mitään.

Vain siinä tilanteessa, että jotain dataa pitää jakaa joidenkin välillä, nuo kieltobitit nousee yleisessä tilanteessa merkitykselliseen asemaan.


Suorituskykysyistä (jotta kernel-kutsut olisivat nopeampia) tätä periaatetta oli kuitenkin aiemmin rikottu siinä, että kernelin oma data on userspace-ohjelmille näkyvissä (mutta laitettu käyttökieltoiseksi kaikilla kolmella tavalla).

Nyt tämä osoittautui vaaralliseksi optimoinniksi intelin prosessoreilla. (meltdown).

 

[Sami Riitaoja]

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ä C-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)

Kerrankos sitä pyörittelee lähtöarvot pieleen, sen takia on hyvä että tekijät on selvillä niin muut huomaa helposti missä meni mehtään.

 

[Sami Riitaoja]

.

Olet lukenut joskus jostain jonka olet ymmärtänyt väärin. Höpinästäsi ei kuitenkaan saa selvää, mitä olet oikeasti joskus jostain lukenut.

Saatat olla täysin oikeassa. Pitäis panostaa itse asiaan ja jättää ylimääräiset höpinät pois.

Eli cachen toiminnastahan olet täysin oikeassa, itsellä oli vain vähän ongelmia sisäistää kun ei peruslaskuista lähtien onnistunut.

Mutta yritetään siis uudestaan kun lähtöarvot on saanut päähän oikein.


Eli 8 way set cachessa tarvitsee vertailla 8 kpl 12 bitin offsettiä yhdessä TLB:n dekoodauksen kanssa -> TLB:stä taas tarvitsee verrata 4kpl 36:ta sivunumerobittiä(jos siis 4-way TLB). Käsittääkseni kaikki nämä eri vertailut voi laittaa yhtäaikaa liikkeelle. 36 bitin comparaattori on vain huomattavasti hitaampi kuin 12 bitin -> meillä on mahdollisesti kellotaajuutta rajoittava hidas polku.

Edit: korjataas, siis kun offsetin 6 alinta bittiä muodostaa cachelinjan ja seuraavat 6 niputetaan samaan settiin offsetissä ei ole enää mitään tarkistettavaa eikä valikoitavaa-> ainoastaan setti voidaan valita TLB-muunnoksen aikana. TLB muunnoksen jälkeenvoidaan vertailla noiden 8:n mahdollisen osuman 36:ta tag-bittiä ja nähdä tuliko osuma vai ei.

-> jos dekoodaamme tässä vaiheessa vain samat 12 bittiä sivunumerobiteistä saamme varmaankin tulokset valmiiksi likipitäen samassa ajassa - ja meillä on 24bittiä(16MB jos nyt laskut menee oikein) lineaarista muistiavaruutta dekoodattuna. Eli siis ajettavan koodinpätkän osat jos ovat tuolla alueella löydetyt TLB-hitit ovat oikeita. Ja kun otetaan huomioon että TLB range sivuista laskettuna on 128*4KiB=512KiB(1/32 osa alueesta) ja itse cachea on 32KiB noita väärin tulkittuja osittain dekoodattuja TLB-tuloksia on hyvin pieni prosentti verrattuna normaaleihin TLB-misseihin. Ja tässä siis kyse L1 DTLB:stä, hudin vaikutus ei ole suuren suuri kun L2 TLB:kin löytyy. Mun muistikuvat asiasta on kuitenkin ajalta jolloin missään prosessorissa ei ollut useampitasoista TLB:tä.

Ja nykyprosessorilla kyse ei optimoinneissa taida enää olla niinkään nopeudesta kuin tehonkulutuksen optimoinnista, eihän esimerkiksi se pois tässä vaiheessa jätetty yhden bitin käyttöoikeustarkistus voi nopeutta rajoittaa mutta tehonkulutukseen voi olla pieni vaikutus.

Edit: kerran 8-way cachessa pitää kuitenkin verrata 8kpl 36 bittisiä tageja(ellen missannut jotain niputusta) tuo TLB-osuman hakemisen optimointi bittimäärää tiputtamalla ei suuren suuria hyötyjä toisi.

 

[Sami Riitaoja]

Silloin, kun ne pyörii samassa prosessissa, niitä ei suojata millään virtuaalimuistin lukuoikeusbiteillä, vaan sillä että sen tulkaten suoritettavan javascriptin tai javasciriptistä jitatun koodin muistiaccessit tarkastetaan ihan softalla, jokaisen taulukkoaccessin (jonka indeksejä ei pystytä kännösaikana tarkistamaan) eteen siihen JITattuun koodiin lisätään haarautuminen joka varmistaa että se ei accessoi muistia jota sen ei pitäisi accessoida.. (paitsi spekulatiivisesti

Tässä on kyse spectrestä, ei meltdownista, ja kaikki spekulatiivista suoritusta tekevät prosessorit ovat tälle aivan yhtä haavoittuvaisia.

Nykyäänhän on käytössä Kernel-mode JIT kääntäjiäkin, sellaisen läpi ajettuna Spectrekin pääsee käsiksi kernelimuistiin.

Mutta kaikki prosessorit eivät ole yhtä haavoittuvaisia, Spectre pääsee lukemaan kernelimuistia Intelin prosessoreilla myös userspacessa ajetusta ohjelmasta, ei muilla.

No joo tuokin tosin varmaan on tilanne ennen Meltdown-päivitystä, ei sen jälkeen.

 

[Ville Suvanto]

@hkultala & @Sami Riitaoja

Voitaisiinko pojat sopia, että tätä vääntämistä jatketaan vaikka YV:n puolella. Menee nyt vähän turhan pitkäksi vääntämiseksi täällä.

 

[Cirrus]

@hkultala & @Sami Riitaoja

Voitaisiinko pojat sopia, että tätä vääntämistä jatketaan vaikka YV:n puolella. Menee nyt vähän turhan pitkäksi vääntämiseksi täällä.

Mitä helvettiä? Ymmärrän juuri ja juuri eri ketjun, mutta muuten kyllä en vähääkään.

Tod näk tässä on oppinut enemmän cpu:n toiminnasta kuin missään aiemmin.

 

[Ville Suvanto]

Mitä helvettiä? Ymmärrän juuri ja juuri eri ketjun, mutta muuten kyllä en vähääkään.

Tod näk tässä on oppinut enemmän cpu:n toiminnasta kuin missään aiemmin.

Tämä on mennyt kahden henkilön vääntämiseksi, eikä ainakaan minusta palvele tämän otsikon alla. YV, uusi ketju, mikä se ratkaisu sitten onkaan.

 

[Cirrus]

Tämä on mennyt kahden henkilön vääntämiseksi, eikä ainakaan minusta palvele tämän otsikon alla. YV, uusi ketju, mikä se ratkaisu sitten onkaan.

No hoida sitten hommasi ja siirrä keskustelu sopivaan ketjuun.

Keskustelu on sillä tasolla että ihmisiä ei ole kovin montaa, jotka tunee cput noin hyvin. Mutta ei se voi olla syy rajoittaa keskustelua.

Eikä se myöskään tarkoita sitä että muita ei kiinnostaisi ja keskustelu pitäisi käydä yv:llä.

 

[njake]

Mielenkiinnolla olen seurannut myös tätä keskustelua ja mielellään näkisin sen jatkuvan.

 

[Sami Riitaoja]

N-way set cachet on multa aina mennyt ohi älyn kun asiaa on kuvattu n-määrällä laatikoita joissa cachelinjat. Kultala selitti hyvin että homma lähtee direct-mapped cachesta jonka avulla löysin yhden fiksun sivun joka kuvas asian juuri noin, n tuossa määrittää montako cachelinjaa aina muodostaa setin ja setti on sisäisesti fully assosiactive. Nyt em. asiakin mahtui älyyn, toivottavasti on vielä oikeinkin.

 

[Sami Riitaoja]

@hkultala & @Sami Riitaoja

Voitaisiinko pojat sopia, että tätä vääntämistä jatketaan vaikka YV:n puolella. Menee nyt vähän turhan pitkäksi vääntämiseksi täällä.

Eikai sitä kukaan viitsi YV:nä vääntää mitään

 

[Mechanical Man]

@Ville Suvanto henkilöiden keskustelu on ollut ihan asiallista ja asiassa pysyvää, joskin ei otsikon. Tuollaisen nillittämisen sijaan olisit voinut tehdä sen ketjun uudella otsikolla ja siirtää henkilöiden viestit siihen.

 

[demu]

Intel on saanut Spctreen ja Meltdowniin liittyen (tähän mennessä) 32 (edit.) joukkokannetta.

Intel faces 32 lawsuits over Spectre and Meltdown

 

[edup]

Intel on saanut Spctreen ja Meltdowniin liittyen (tähän mennessä) 32 haastetta.
Joukkokanteita odotellessa...
Intel faces 32 lawsuits over Spectre and Meltdown

Joukkokanteitahan nuo 32 juuri ovat.

The 32 total lawsuits comprise 30 class-action lawsuits and two securities class-action lawsuits.

 

[demu]

Joukkokanteitahan nuo 32 juuri ovat.

jep. korjasin jo

 

[copter]

Sovitaanko että molemmat osapuolet ovat nyt esittäneet argumenttinsa ja yleisö saa äänestää voittajasta?

 

[adder]

Älkää nyt turhaan lähtekö rajoittamaan keskustelua. Niin kauan kun keskustelu sisältää enimmäkseen oleellista tietoa ja keskustelu/väittely ei ole mennyt pelkäksi henkilökohtaisuuksiin menemiseksi, niin tälläiset keskustelut minusta kuuluu olla ihan julkisesti esillä. Joko siirtää omaan ketjuunsa, tai antaa jatkua tässä. Kumminkaan tälle ketjulle ei varsinaisesti muutakaan hyötykäyttöä ole, kun itse alkuperäinen uutinen on jo käsitelty.

 

[TenderBeef]

Kumminkaan tälle ketjulle ei varsinaisesti muutakaan hyötykäyttöä ole, kun itse alkuperäinen uutinen on jo käsitelty.

Ei pidä paikkansa. Tähän ketjuun on liitetty monia asiaan liittyviä iotechin uutisia (ja toivottavasti jatkojututkin yhdistetään tähän) ja itse ainakin seuraan tätä ketjua siitä syystä, että saan lisää tietoa Meltdown+Spectre ongelman etenemisestä. CPU-arkkitehtuurista sivukaupalla käytävä "facepalm"-riitely ei mielestäni ole ihan tänne kuuluvaa.. toiseen topikkiin?

 

[adder]

Ei pidä paikkansa. Tähän ketjuun on liitetty monia asiaan liittyviä iotechin uutisia (ja toivottavasti jatkojututkin yhdistetään tähän) ja itse ainakin seuraan tätä ketjua siitä syystä, että saan lisää tietoa Meltdown+Spectre ongelman etenemisestä. CPU-arkkitehtuurista sivukaupalla käytävä "facepalm"-riitely ei mielestäni ole ihan tänne kuuluvaa.. toiseen topikkiin?

Näistä jatkotutkimuksista ja merkittävistä löydöksistä olisi melkein parempi tehdä suosiolla uusia uutisia, jos ovat niin merkittäviä.

 

[TenderBeef]

No niistähän on tehty ja tehdään, ne uutisten kommenttiosiot vain yhdistetään tähän ketjuun.

 

[Tege]

Ei niitä ehkä enää kannata tänne linkkailla. Tämä ketju toimi ihan hyvin kun tapaus oli tuore, niin saman asian keräykseen. Nyt tilanne on alkanut rauhoittumaan ja jos tulee niitä korjauksia kannattaa ne erottaa omaksi uutiseksi keskusteluineen.

 

[Kaotik]

No niistähän on tehty ja tehdään, ne uutisten kommenttiosiot vain yhdistetään tähän ketjuun.

Ei yhdistetä enää, meni jotain rikki ja rupesi näkymään tuplana viestejä etusivulla niin jatkossa uutiset tulee omiin ketjuihinsa tästäkin aiheesta. Löytyvät etusivulta toki tutuilla samoilla tageilla ja koitetaan muistaa pistää tänne aina linkki kun tulee uutta

edit: myöhäisiä autocorrect-korjauksia

 

[Spaceman]

No väärällä mutta onhan tuossa kirjoituksessakin lähtötiedot väärin, 64 tavun cachelinjat on tietysti 9 bitin osoituksella eikä 8:n.

Hyvä threadi. Riitaoja ei ymmärrä peruskäsitteitä ohjelmoinnista tai edes millä granulateerilla prosessorit toimivat (bitti/tavu), ja siitä huolimatta on saanut pumpattua hkultalalta mielenkiintoista tietoa viihdyttävässä muodossa.