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
:facepalm:
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.
:facepalm:
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?
Ei, kyse oli aivan eri asiasta. Sinä et vaan ymmärtänyt, mistä niissä puhuttiin.
Suurin asia, mikä tässä kusee on sinun ymmärryksesi ihan yksinkertaisista asioista liittyen ihan perusasioihin muistiin liittyen.
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).
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.
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.
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.
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. 🙂
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.
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).
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.
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.
-> 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.
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.
@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.
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ä.
Mielenkiinnolla olen seurannut myös tätä keskustelua ja mielellään näkisin sen jatkuvan.
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.
Eikai sitä kukaan viitsi YV:nä vääntää mitään 😉
@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.
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.
jep. korjasin jo
Sovitaanko että molemmat osapuolet ovat nyt esittäneet argumenttinsa ja yleisö saa äänestää voittajasta? 😀
Ä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.
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ä.
No niistähän on tehty ja tehdään, ne uutisten kommenttiosiot vain yhdistetään tähän ketjuun.
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.
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 tahdilla ja koitetaan muistaa pistää tänne aina linkki kun tulee uutta
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. 🙂
Eikös tämä asia tullut jo käsiteltyä? Ja lisäksi ei ole oikein hyvä tapa pistää nimimerkkiä ja "ei ymmärrä" kommenttia peräkkäin. Se tietäväisempi vänkääjä tähän myös syyllistyi.
Itse aiheeseen, niin sehän on vielä kesken, kun ei tiedetä miten nuo Intelin tulevat mikrokoodipäivitykset toimivat. Kauan kestää kuitenkin korjaus vaikka kesästä 2017 asti ollut tiedossa.
Mieti nyt vähän miten esimerkiksi cache toimii. Eli voimme lukea osan datasta nopeammin kuin koko muistista vaikka kuitenkin tarvitsemme sen koko muistin. Osoiteavaruuden voi optimoida aivan samalla tavalla, ei meidän tarvitse mapata koko osoiteavaruutta että saamme sataprosenttisen varmuuden missille ja 99.9+% todennäköisyyden osumalle.
Löysin tälläisen paperin jossa asiaa on yhdistetty itse datacachen tutkailuun:
https://pdfs.semanticscholar.org/20f5/3808fcf89391c0172674d97d9163c7a140ed.pdf
Tuosta nyt selvisi että idea/tutkimus on Lishing Liun vuodelta -94.
Ja jos cache on fyysisesti mapattu tarvitaan aina TLB-muunnos cachen tagin vertailuun, ja TLB:hen tuon käyttäminen soveltuu paljon paremmin kuin virtuaalimuistiin, TLB:n osoiteavaruus on aina ohjelmakoodin osalta lineaarinen, fyysinen muisti voi olla mapattu miten vain. Aikanaan tuota sovelluttu mahdollisesti Alpha EV45:ssa tms. TLB:ssä josta joku tekninen juttu jossain lehdessä josta asia jäänyt päähän. Ja tää oli vain teoriaa, monia muitakin vaihtoehtoja tietty on.
Ja ohjelmointi ei ole mun homma, eikä sen puoleen piirisuunnittelukaan, kai sitä saa silti jostain yrittää keskustella ilman että kaikki mitä itse ei ihan hiffaa tuomitaan vääräksi.
Joo ja pahoittelen että mun kirjallinen ulosanti on aika perseestä, mutta eipä tuo oma tyylisikään kaikkein vähiten provokatiivistä ole.
Ensinnäkin, tuo "99.9+%" lukusi on ihan hatusta vedetty eikä vastaa todellista.
Toisekseen, mikään "99.9% varmuus" ei ole riittävä, ei riitä että 999 muististalukua luetaan oikein jos se tuhannes luetaan väärin.
Tarvitaan 100% varmuus ennen kuin voidaan julistaa välimuistiosuma.
(tai sitten jos se 100% varma osumatieto tulee jotenkin myöhässä, vaaditaan siitä myöhäisestä missistä selviämiseen helposti jotain todella monimutkaista ja hidasta replay-härväystä tai liukuhihnan flushausta jonka haitat on ziljoona kertaa suurempia kuin se hyöty, mikä voidaan jossain kriittisessä polussa saada joidenkin bittien vertailemisesta jotenkin myöhemmin)
Tuossa otettiin HUTEJA pois aikaisin vertaamalla vain alimpia bittejä. Tuossa tehtiin edelleen ihan täysi vertailu ennen kuin voitiin julistaa OSUMA.
Oleellinen pointti tuossa on virransäästö, että kun ekassa vaiheessa luetaan vain ne 2 alinta bittiä, sillä saadaan melkein neljäsosa välimuistin "teistä" pelattua pois ennen täysilevää tag-accessia. Jos välimuistissa on 8 tietä, joissa yhdessä on se data, muissa 7ssä kussakin on 25% todennäköisyydellä samat alimmat tag-bitit, eli tarvii tehdä täysi luku vain keskimäärin 2.75 tielle. Ja jos 8-teisessä välimuistissa sitä dataa ei ole, tarvii tehdä täysi luku vain keskimäärin 2 tielle.
Järkevä keskustelu on sitä, että tiedostetaan se, mitä tiedetään ja ymmärretään, ja mitä ei tiedetä tai ymmärretä, eikä aleta väittää varmaksi omaa tulkintaa asioista, joita ei ymmärrä.
Jaahas herrat ovat lähellä asian ydintä.
Luulen että se osaavin taho ei huutele vaan tekee ja toimii (toivottavasti).
Jätänpä tämän tähän 13 Major Vulnerabilities Discovered in AMD Zen Architecture, Including Backdoors
Tähän voi myös jättää tämän
Virallinen: AMD vs Intel keskustelu- ja väittelyketju
Jätä vaan, oli vaan enemmän related suoraan tähän ketjuun, oli totta tai ei.
Kommentoidaan nyt tännekin sen verran että ilmeisesti kyse on firman markkinamanipulointiyeityksestä. Ja ko. Firma on ilmeisesti matkalla jostain vastaavasta jo oikeuteen Saksassa.
Ilmeisesti haavoittuvuudet sinänsä ovat "todellisia", että ne on olemassa JOS koneeseen asennetaan tarkoituksella haitallinen BIOS, firmis piirisarjalle jne. Sellaisenaan koneissa ei ole noita haavoittuvuuksia.
Lisäksi huomionarvoista on että "löydökset" julkistettiin alle 24h sen jälkeen kun niistä oli ilmoitettu AMDlle joka ei ehtinyt vastaamaan tai ottamaan kantaa väitteisiin ennen julkaisua
Mutta tutkitaan tietenkin vielä asiaa
Tutkinnoissa voisi lähteä liikkeelle vaikkapa siitä, että kuka tämän CTS-Labsin toimintaa rahoittaa. Ajoitus viittaa kyllä aika vahvasti yhteen suuntaan.
Alleged AMD Zen Security Flaws Megathread • r/Amd
Tuolla on hyviä linkkejä. "Bugit löytänyt" firma mm. ilmeisesti on feikannut pääkonttorinsa green screenin ja muutaman kuvapankkiotoksen avulla. Ellei muuta todisteta, niin kuulostaa suuren luokan kusetus / markkinamanipulaatioyritykseltä
EDIT: Ja ilmeisesti kaikki noista tarvitsevat admin oikeudet toimiakseen. Jos hyökkääjä saa admin oikeudet, niin peli on joka tapauksessa menetetty oli haavoittuvuuksia tai ei, joten koko homma kuulostaa todella liioitellulta
Tietoturvayhtiö kertoo löytäneensä 13 haavoittuvuutta AMD:n Zen-alustoista – io-tech.fi tuonne jatkot
Gigabyte GA-H270N-WIFI emoon on näköjään ilmestynyt uusi bios F8d (2018/03/09)
Reilu kuukausi sitten ilmestyi aikaisempi F8b, joka korjasi samaa. Itsellä ei ole ollut tuon vanhan kanssa mitään ongelmia. Kone pfSense palomuurina niin ongelmat olisi kyllä huomannut.
Täähän oli liittyen Meltdowniin, eli Meltdownin selittää hyvin se että TLB:t käsitellään jäljessä. Jo jäljessä käsittely antaa paljon aikaa optimoida homman virrankulutusta, ja voidaan esimerkiksi koota kaikki tietylle linjalle osuvat hitit yhdessä.
Intel on ollut hipihiljaa iät ja ajat L1-taggauksestaan, mutta AMD on dokumentoinut Zenin L1-taggauksen ja TLB-käsittelyn oikein hyvin. Eli Zenin L1 on täysin virtuaalisesti accessoitu osittaiseisen lineaarisen tagin mukaan. Väärintulkintamahdollisuudet ja muut konfliktit on hoidettu L2:ssa.
https://support.amd.com/TechDocs/55723_SOG_Fam_17h_Processors_3.00.pdf
Toki AMD puhuu itse way predictionista mutta dokumennoinin mukaan on ihan selvää että fyysistä tagia ei ikinä L1:ssä käsitellä. Eikä ole uusi tekniikka, samaa on käytetty jo 80-luvulla direct mapped kakkujen kanssakin.
:facepalm:
"Jäljessä" ei ole "jäljessä" vaan sen data- ja tag-accessin kanssa rinnakkain, VIPT jonka olen jo vähintään kahteen kertaan selittänyt.
Ja osumaa ei edelleenkään voi julistaa ilman sitä oikeaa fyysistä osoitetta, jolla se L1-kakku on tagettu.
Ja muuten alkaa mennä taas "not even wrong"-osastolle. Pienen L1-TLBn acessoiminen ei vie paljoa virtaa, eikä sen venyttäminen moneen kellojaksooon säästäsisi sitä mitenkään merkittävästi. Ja joku ziljoonan eri accessin yhdistämislogiikka olisi paljon monimutkaisempi ja hankalampi kuin mitkään sen hyödyt.
AMD on dokumentoinut L1-tagauksensa ja TLB-käsittelynsä oikein hyvin ja sen sijaan että uskot sitä AMDn dokumentaatiota keksit omasta päästäsi että sen täytyy kuitenkin toimiahiukan eri tavalla kuin miten AMD sen dokumentoi toimivan.
(ja keksit siihen omasta päästäsi tavaksi sellaisen, missä ei ole mitään järkeä, koska se aiheuttaisi hyvin pahoja ongelmia)
:facepalm:
Jos ei mahdu päähän niin ei mahdu. Eli siis jos vaikka AGU:n laitetaan tieto kuinka suurelle alueelle L1-cachen data on levittäytynyt virtuaalisen tagin osumaksi riittää bittimäärä joka kattaa tuon alueen. Fyysinen osoite on oltava kokonainen, virtuaalisen lineaarisen ei. Esimerkiksi Zenin L1-latenssi on 4 kellojaksoa lyhyellä osoitteella ja 5 pidemmillä.
Yhden cachelinjan tarvittava data on yleensä 64 bittiä. TLB:n kautta haettuna ensin pitää hakea 36 bittinen virtuaalinen vastaavuus, sen jälkeen lukea 36 bittinen fyysinen käännös ja verrata tätä cachelinjojen 36 bittiseen tageihin. Etkö edelleenkään näe tässä mitään mahdollisuutta säästää mitään?
No just luin sen tuosta 17h optimointiopuksesta. L1:n ollessa L2:n subset jokainen cachelinja on tagätty fyysisesti L2:ssa, suurin osa virtuaalisen L1:n taggauksen ongelmista poistui siinä. Ja AMD kertoo tuossa linkitetyssä oppaassaan kaikki virtuaalisen L1-cachen taggauksen mahdolliset haittapuolet, todennäköisesti implementaatio ei edes kaikista niistä kärsi. Selvästi käy kuitenkin selväksi että L1:stä accesssoidaan vain virtuaalisen tagin mukaan, fyysisen ollessa oikein mutta virtuaalisen väärin(prosessin vaihto) osuma tulee L2:sta eikä L1:stä, L1:n tagi päivitetään.
Kuten ennakoitiin niin Spectre oli vasta alkua. Uutta pukkaa.
As predicted, more branch prediction processor attacks are discovered
Super-GAU für Intel: Weitere Spectre-Lücken im Anflug
Kahdeksan uutta spectre-haavoittuvuutta löydetty. Näiden on vahvistettu koskevan Intelin prosessoreita ja joitakin ARM prosessoreita. AMD:n mahdollinen haavoittuvuus on vielä tutkinnassa.
Jokainen näistä saa Spectren ja Meltdownin tapaan oman nimen ja haavoittuvuusnumeron (Common Vulnerability Enumerator, CVE). Toistaiseksi näitä haavoittuvuuksia kutsutaan nimellä 'Spectre Next-Generation'.
Puolet haavoittuvuuksista on vakavia:
"Intel classifies four of the Specter NG vulnerabilities as "high-risk"; the danger of the other four is only rated as medium."
Päivityksiä näihin on tulossa mahdollisesti jo tässä kuussa ja lisää myöhemmin kesällä. Odotettavissa on lisää hidastuksia edellisten päivitysten päälle.
Nää on Meltdown-haavoittuvuuksia vaikka ovatkin nimetty Spectreksi. Eli Intelin prossut ja ARM:t jotka Meltdownista kärsivät ovat potentiaalisia kohteita. KPTI erottaa muistiavaruudet mutta Meltdownista kärsivät prosessori on täysin rikki muistinsuojauksen osalta, nyt nähtävästi on sitten löydetty mahdollisuudet ronkkia cachesta dataa ulos – korjaus lienee cachen tyhjentäminen aina osoiteavauuren muutoksien yhteydessä ellei keksitä jotain vähemmän hittiä aiheuttavaa suojausta. Alkaa olemaan Intelin prossut aika turhia serveripuolella…..
Jos tuo pitää paikkansa ja osoittautuu, että AMD on immuuni koko tälle Spectre-NG -haavoittuvuusjoukolle, niin laitan kyllä AM4-lankun, 2700X:n, ja muistit tilaukseen. Ehkäpä suhtaudun asiaan liian epärationaalisesti ja tunteella, mutta en vain voi sille mitään että Intelin reikäjuustoprosessorin käyttäminen alkaa tässä vaiheessa tuntua suorastaan vastenmieliseltä.
No aika tietysti näyttää osuuko näistä mitään/mikään Ryzeneille, mutta joka tapauksessa ei voi kuin ihmetellä. Aivan vitun käsittämätöntä. Miten voi olla että miljaardien R&D budjetilla ei näitä pystytä löytämään ja vuosikaudet tehdään rikkinäisiä tuotteita.. Huoh.
Akateemiset tutkijat, googlen inssit ja ketä näitä nyt löytääkään… Kuinka kauan vaikka NSA:lla on ollut työkalut näiden exploittaamiseen…
No ei nää nyt löydetyt haavoittuvuudet tavallista työpöytäkäyttäjää haittaa millään tavalla. Serveripuolella varmaan alkaa kohta olla tarve pistää Meltdown-prossut kierrätykseen, tuskin nää haavoittuvuudet vielä tähänkään tulee jäämään ja jos joka fiksi syö suorituskykyä niin….
Aika rohkeaa väittää näillä tiedoilla ettei nämä peruskäyttäjää haittaa. En ehkä ole peruskäyttäjä, mutta ajelen juurikin virtuaalikoneita tekemään asioita, joissa mahdollisuus törmätä vihamieliseen ohjelmakoodiin on normaalia suurempi.
Eiköhän nyt vaan odotella rauhassa että viralliset advisoryt tulee pihalle ja sitten hutkitaan lisää. Peace out.
Ei, et todellakaan ole peruskäyttäjä. Peruskäyttäjä on tuskin edes kuullut ikinä sanaa "virtuaalikone".
Veikkaisin itse ihan mutupohjalta että jos näistä ei olisi koskaan raportoitu, niin harva olisi tuskin mitään huomannut edes.
Perkules kun ei ollut mahdollisuutta testata tällä 7700K:lla ennen ja jälkeen esim. Cinebenchiä, oli vielä 7600K kun noita päivityksiä alkoi sadella.