Apple ilmoitti viime kuussa hylkäävänsä x86-arkkitehtuurin seuraavan noin kahden vuoden kuluessa ja korvaavan sen omilla Arm-arkkitehtuuriin perustuvilla järjestelmäpiireillään. Yhtiö on paljastanut nyt myös näytönohjainpuolen kokevan saman uudistuksen.
Applen x86-arkkitehtuuriin perustuvat Mac-tietokoneet ovat käyttäneet AMD:n, Intelin ja NVIDIAn näytönohjaimia, joskin NVIDIAn kohdalla kyse on lähinnä historiasta ja ajurituki on lopetettu viimeisillekin tuotteille jo viime vuoden puolella. Apple tulee jatkamaan AMD:n ja Intelin näytönohjainten käyttöä myös tulevaisuudessa Intel-pohjaisissa Mac-tietokoneissa, mutta Arm-pohjaisissa tilanne on toinen.
Applen WWDC20-konferenssin tiimoilta julkaistiin kehittäjille video, jossa sen näytönohjainajuripuolen johtaja kertoo yhtiön suunnitelmista näytönohjainpuolelle lähitulevaisuudessa. Videon mukaan Arm-arkkitehtuuriin perustuvissa Mac-tietokoneissa tullaan käyttämään yksinomaan Applen omia näytönohjaimia, jotka hyödyntävät mobiilipuolelta tuttua TBDR-arkkitehtuuria (Tile-Based Deferred Rendering). Käytännössä tämä tarkoittanee Imaginationin PowerVR:n suunnittelemaa arkkitehtuuria, minkä pohjalta joko Apple itse tai PowerVR Applen toimeksiannosta suunnittelee varsinaiset grafiikkapiirit tai IP-blokit integroitavaksi osaksi järjestelmäpiiriä. Valitettavasti videolla ei paljasteta tarkempia tietoja itse arkkitehtuurista tai miten sen suorituskyky tulee vertautumaan PC-puolen kilpailijoihin.
Lähde: Apple
Osaako joku oikeasti sanoa jotain Imaginationin GPU-techistä? Ainakin mobiilipuolella se on aika kovatasoista verrattuna kilpailijoihin, mutta miten se mahtaa skaalautua kun laitetaan shadereita ja muistikaistaa enemmän?
Applella on se etu puolellaan, että kun venytetään stäkkiä mobiilista ylöspäin, niin energiatehokkuus ja muistikaistatehokkuusaspektit tulevat mukana automaattisesti. Siinä missä PC:llä hukataan usein sähköä ja suorituskykyä laskemalla kaikki FP32:sella, niin Apple on tunkenut FP16:sta kaikkialle mihin se suinkin käy + optimoinut GPU:nsa suorittamaan sitä.
Sen lisäksi se suorituskyky mitä Apple saa ulos simppelistä erittäin energiatehokkaasta LPDDR4x-väylästä on kyllä aika huimaavaa verrattuna kymmenkertaisella kaistalla toimiviin pc-gpu:ihin.
PoverVr-arkkitehtuuri oli aikanaan PC-puolellakin, perustuu tile-pohjaiseen renderöintiin eli piirretty frame on jaettu pieniin osiin jotka on helppo cacheta kokonaan jolloin muistikaistan käytön tehokkuus paranee oleellisesti. Tile-renderöinnistä on vaan haittojakin jonka takia se muualla kuin mobiilipuolella hylätty jo kokonaan, ja esimerkiksi Samsung siirtynee AMD:n ei tile-pohjaiseen RDNA2:een kohtapuoliin. Applen kehityssuunnasta ei ole vielä tietoa jatkavatko tile-pohjaisena vai luovutaanko siitä siirryttäessä desktop-puolelle jossa äärimmäinen energiatehokkuus ei ole välttämättömyys-
Turingiin liittyen en ole nähnyt mainintoja.
–
Läppärit, jotka ovat luokkaa 90% Applen tietokonemyynnistä, ovat vähintään osin TDP-rajoitteisia GPU:iden suhteen, joten ymmärrän hyvin jos Applen optimointitargetit ovat erilaiset kuin muiden valmistajien.
TBR != TBDR
PowerVR:n setit on TBDR eli Tile-based Deferred Rendering, AMD:n ja NVIDIAn sirut hyödyntää TBR:ää eli Tile-based renderingiä, mutta ovat edelleen Immediate mode renderöijiä
Imaginationin viime vuonna julkaistu A-Series, josta muuten @Kaotik io-tech unohti uutisoida, skaalautuu 2 TFLOPSiin asti. Anandtechilla tuosta oli pidempi juttu, jonka perusteella vaikutti kyllä lupaavalta, mutta en mää siitä enää yksityiskohtia muista.
Roadmapissa on myös vähemmän mielikuvituksellisesti nimetyt vuosittaiset päivitykset B-Series, C-Series ja D-Series.
Joskus näitä menee ohi
Otti myös kantaa appleen ja arm:iin.
Esim. Viimeisimmässä Intelin suorittimessa edelleen samat tietoturva -bugit, joista intel on vain ilmoittanut tylysti että eivät korjaa. Ja onhan tuo ison viivanleveyden ongelmat ollut tässä tapetilla koko vuoden throttlaamisen sun muun osalta, etenkin kun verrataan AMD:n. Mitä enempi ytimiä, sitä enempi ongelmia. Intel.
Kuulostaa siis siltä, että kehitys jumahti jos kerta 10nm kehitys failasi. Sillä aikaa AMD pukkaa jo seuraavaa iteraatiota 7nm zenistä…
Mistähän tietoturvabugeista nyt oikein tarkkaanottaen puhut?
Jotain konkretiaa näihin syytöksiin, kiitos.
Esim. Meldown ei edes ole bugi ja silti sen toiminta on estetty myös uusimmissa skylake-johdannaisissa.
Jos taas halutaan estää 100%sti kaikki spekulatiiviseen suoritukseen perustuvat sivukanavahyökkäykset (joissa siis ei ole kyse bugeista) niin sitten pitää vaihtaa kokonaan prossuun jossa spekulatiivista suoritusta ei ole, eli esim. itaniumiin, perus-pentiumiin, ekan sukupolven atomiin, tai Cortex A55een. AMDllä pitäisi mennä niinkin kauas kuin 486een, koska jo K5 teki nämä temput eikä halpisydin Bobcattikään jättänyt niitä tekemättä.
Enemmän niitä ongelmia on intelillä tullut siitä kun yritettiin tehdä liian PIENTÄ viivanleveyttä (36nm MMP), ei liian isosta.
Voisitko nyt vaan suoraan sanoa mitä ongelmia tarkoitat sen sijaan että vedät hatusta tuollaista epämääräistä mutua?
Meltdown (security vulnerability) – Wikipedia
Jaa että muistin lukeminen lennosta ei ole tietoturva bugi? Voisit muutenkin vähän rauhoittua etkä ottaa näitä asioita niin henkilökohtaisesti.
Haavoittuvuus ja bugi eivät ole sama asia. Lisäksi kyseinen haavoittuvuus on korjattu jo Coffee Lake Refresheissä (9. sukupolvi) rautatasolla
Ne "7nm" ja "10nm" on ihan puhtaita markkinointinumeroita.
Ja taitaa inteliltä ehtiä toisen sukupolven Cove-Ydin (joka on aika paljon zen3sta järeämpi) ulos ennen AMDn zen3sta.
Jos nyt tarkkoja ollaan niin eihän me vielä tiedetä miten järeitä Zen 3:t tulee olemaan, mutta Zen 2:ta tai Skylake-pohjaisia selvästi järeämpi kyllä, 1. sukupolven Coveen verrattuna välimuistipuoli ja parantunut prosessi (selvästi korkeammat maksimikellot) avainasemassa suorituskyvyn parantumisessa.
Ja siis onhan näitä. Zombieleak, Spectre jne. Sen lisäksi kun näitä "korjattiin" niin samalla etenkin hieman vanhempien suorittimien suorituskyky heikkeni selvästi. Intel ei todellakaan ole händlännyt tietoturva -puolta mitenkään kehuttavasti.
bugi == toiminta eri tavalla kuin speksi sanoo.
Jospa tuon mutuilun sijaan ottaisit vaikka sen käskykantaspeksin esille ja lukisit, mitä siellä sanotaan muistinsuojauksesta, tai yrittäisit edes muuten ymmärtää miten se toimii.
Ja sen jälkeen yrittäisit keksiä, mitä sen speksin kohtaa nämä intelin monta vuotta vanhat (ei enää uudet) prosssorit vastaan rikkoo.
Intelin kaikki x86-prosessorit heittävät tasan speksinmukaisen virtuaalimuistipoikkeuksen, jos niillä suoritetaan käsky, joka lukee osoitetta, jota ei ole oikeutta lukea, eikä laittomasta osoitteesta luettu data koskaan päädy prosessorin arkkitehtuurillisessa tilassa siihen kohderekisteriin tms. minne se yritetään lukea.
Voisitko sinä ensin lopettaa näiden valheiden postaamisen?
Voit vaikka kirjoittaa romaanin ja selittää erikseen miksi Spectre ei ole mielestäsi tietoturva haavoittuvuus ja samalla selittää zombie leakit sun muut parhain päin, mutta se ei poista sitä tosiasiaa että Intelillä on tietoturvaongelmia liikaa.
Miksi sitten jotain patchejä on tehty kiireellä kaikkialle jos kyse on vaan kaikkien tiedossa olleesta speksien mukaisesta toiminnasta?
Koska speksin mukainen toiminta onkin osoittautunut ongelmaksi? Se ei silti tarkoita, että se olisi bugi.
VOISITKO NYT OIKEASTI LOPETTAA TÄMÄN OLKIUKKOILUN ja sanojen tunkemisen suuhuni ja opetella lukemaan, mitä olen sanonut! Tai edes YRITTÄÄ ymmärtää, mitä sanon.
En ole koskaan väittänyt, että Spectre ei ole HAAVOITTUVUUS vaan että se ei ole bugi.
Nämä ovat kaksi täysin eri asiaa. Ja sitä sinä et tunnu tajuavan.
Nyt voisi olla syytä korjata sitä asennettasi. Lisäksi henkilökohtaisuuksiin menon on syytä loppua heti.
Kyllä, Intelillä on löytynyt haavoittuvuuksia runsaasti kilpailijoihin nähden viime vuosina. Niitä on kuitenkin myös korjattu hyvää tahtia sekä ohjelmisto-, firmware- että rautatason korjauksilla, minkä jätät täysin huomioitta.
@hkultala väännä myös sinä pienemmäksi tuota capsien käyttöä, pistä raporttia olkiukkoilusta ja keskustelun paskomisesta mieluummin.
Koska paljastui, että speksi ei ole riittävä, täysin speksin mukaan tehty toiminnallisuus on haavoittuva täysin uudentyyppiselle hyökkäkselle. Sivukanavahyökkäyksiä ei yhtään ajateltu, kun speksi on aikoinaan kirjoitettu.
Spekulatiivista suoritusta on tehty n. 25 vuotta, ensimmäiset sivukanavat huomioon ottavat käskykantaspeksit tuli (vasta) joskus viitisen vuotta sitten (ARMin joku käskykantalaajennos).
Saivartelu on toki taitolaji, mutta taisit varmaankin alunperin ymmärtää mistä oli kyse ? Ei nyt kumminkaan kukaan ole täällä täysin pää pusikossa sen suhteen, että AMD:llä ei nykyisessä tilanteessa ole ainuttakaan tietoturva-aukkoa omassa prosessori -arkkitehtuurissaa, toisin kuin intelillä.
Okei, eli virhe/bugi oli suunnittelussa eikä toteutuksessa.
Definition of BUG
http://www.merriam-webster.com
an unexpected defect, fault, flaw, or imperfection
Tämän perusteella voisi kyllä sanoa että kyllä nuo haavoittuvuudet ovat bugeja.
Näin minäkin sen ymmärsin, mutta kaipa se sanamuoto on joillekin tärkeämpi kuin itse asia.
Vanhempi prosessorisukupolvi sen sijaan taas kärsii ongelmasta edelleen. Spectre -haavoittuvuus sen sijaan hidasti etenkin vanhempaa sukupolvea sen verta huomattavasti että itse lopulta päädyin AMD:n leiriin. Tiedä sitten miten tulevaisuudessa… Toistaiseksi vaikuttaa ainakin siltä, että AMD:n arkkitehtuuri on estänyt tietoturva -haavoittuvuuksien/bugien ilmenemisen yhtä isossa skaalassa kuin Intelillä.
Intel Will Not Patch Spectre in Some CPUs | SecurityWeek.Com
ps. Oman käsityksen mukaan suunnitteluvirhe on bugi. Oli se sitten arkkitehtuurissa tai koodissa. Haavoittuvuus on vain seuraus siitä.
Vastattu tälle paremmin sopivassa säikeessä, tällä säikeellä ei ole mitään tekemistä AMDn kanssa.
Virallinen: AMD vs Intel keskustelu- ja väittelyketju
bbs.io-tech.fi
No onhan meillä MMU speksattu varmaan jo 70-luvulla ellei aikaisemmin. Meltdown ei ole mahdollinen jos prosessori noudattaa MMU:n speksejä, eli data luetaan vasta käyttöoikeuksien tarkistuksen jälkeen. Aivan selvä speksien vastainen toiminta Intelin prosessorissa MMU:n osalta.
Ensinnäkin, MMU tuli vasta 386ssa(joka julkaistiin vuonna 1985), ja sekä Pentium Pron (PAE, 1995) että x64-64n (NX, ~2003?) myötä sen speksi muuttui selvästi.
Siinä speksissä ei lue mitään lähimaillekaan tuollaista.
Vaan siinä lukee jotain tyyliin, että käsky aiheuttaa page fault-poikkeuksen, jos se yrittää accessoida muistia, jota ei saa accessoida.
(ja poikkeuksen heittäminen tarkoittaa aina sitä, että käsky ei tee loppuun sitä mitä se aikoo tehdä, tulos ei päädy rekisteriin).
Ja Meltdownin tapauksessa mitään suoritettavaa käskyä ei edes varsinaisesti ole olemassa. On vain spekulatiivisesti suoritettava ei-suoritettavaksi kuuluva käsky, jonka tulosta ei tallenneta mihinkään arkkitehtuurilliseen tilaan, koska koko käskyä ei oikeasti ole olemassa.
Sen tietokoneen arkkitehtuurillisen sisäisen tilan kannalta ne spekulatiivisesti suoritettavat asiat on henkiolentoja.
Prosessorilla on vapaus tehdä ihan mitä tahansa joka ei vaikuta sen arkkitehtuurilliseen tilaan, ellei sitä erikseen jossain kielletä. Ja x86lla mitään tällaista ei missään erikseen kielletä.
Puolet 286:n pinta-alasta on sen MMU:ta. Ja MMU ei ollut mikään Intelin keksintö.
Yleisesti lienee speksattu että TLB tarkistaa käyttöoikeuden ennen datan luovuttamista eteenpäin. Edes Intel ei ole tainnut suoraan speksata että asia ei koske spekulatiivisesti suoritettuja käskyjä. Meltdown-prosessorissa on siis prosessorin primäärikanavan vuoto, ydin saa käsiinsä dataa jonka käytön MMU:n pitäisi estää ihan speksiensä mukaisesti.
AMD64-yhteensopivahan Intelin prossujenkin pitäisi olla joten lainataan AMD:n page-protection selitystä:
5.6 Page-Protection Checks The AMD64 architecture provides five forms of page-level memory protection. The first form of protection prevents non-privileged (user) code from accessing privileged (supervisor) code and data. The second form of protection prevents writes into read-only address spaces. Two forms of page-level memory protection prevent the processor from fetching instructions from pages that are either known to contain non-executable data or that are accessible by user-mode code. The remaining form (Memory Protection Keys) allows an application to manage page-based data access protections from user mode. Access protection checks are performed when a virtual address is translated into a physical address. For those checks, the processor examines the page-level memory-protection bits in the translation tables to determine if the access is allowed. The page table bits involved in these checks are:
Jotain lähdettä tälle väitteelle että 286n "MMU" oli puolet sen pinta-alasta?
286n "MMU" toimi aivan täysin eri periaatteella kuin 386n, Pentium Pro:n ja x86-64n MMU ja on niihin verrattuna todella alkeellinen ja kämäinen.
286n "MMUssa" esim. ei ollut mitään TLBtä. SIinä ei ollut mitään sivuja.
Siellä oli ainoastaan yhteenlaskuyksikkö joko osasi laskea yhteen lopullisen osoitteen segmentin osoitteesta sekä segmentin sisäisestä offsetista, ja vertailija, jolla voitiin verrata osoitetta segmetin loppuun.
OS/2 oli ainoa käyttis josta oli versio joka edes tuki kunnolla 286n "MMU"ta.
Ei, mutta jos puhutaan intelin MMUn speksistä niin silloin relevanttia on se mitne Intel sen on speksannut. Se, miten esim. IBM on sen jossain parikymmentä vuotta aiemmin tulleessa aivan eri käskykantaa ajavassa mainframessaanspeksannut on tämän kannsalta täysin irrelevantti asia.
Ensinnäkin, TLB ei luovuta dataa yhtään minnekään, se vaan muuttaa osoitteita. Toisekseen, se käyttöoikeus intelilläkin tarkastetaan aina ennen kuin se latauskäsky julistetaan virallsiesti suoritetuksi (retire).
Tuossa on intelin 64-bittisen arkkitehtuurin dokumentti:
Intel® 64 and IA-32 Architectures Software Developer’s Manual…
software.intel.com
vol3a – Kappale 4 käsittelee sivutusta ja muistinsuojausta.
Ekat n sivua on sivutaulujen rakennetta.
vol 3a – 4.6 on se mielenkiintoinen kappale (alkaa sivulta vol 3a – 4-31)
4.6.1 käsittelee sitä, miten tulkitaan onko joku access laillinen.
ainoa, mitä koko 4-kappaleessa sanotaan että tapahtuu jos "laitonta" muistia yritetään käyttää on että tapahtuu page fault-poikkeus
Ja 4.7 (3A sivut 4-34 .. 4-36) käsittelee page fault-poikkeusta. Selittää mitkä tarkkaanottaen ne tilanteet missä se lentää.
Sivut 6-44 … 6-46 vol3A selittää lisä page faulteista
Sielläkään ei mainita yhtään mitään mitä saa tehdä ja mitä ei saa tehdä ja minne ja koska data saa mennä. Siellä kerrotaan ainoastaan että tapahtuu page fault-poikkeus.
Jospa nyt lukisit sitä speksiä etkä keksisi omasta päästä satuja siitä, mitä kuvittelet siellä lukevan.
Spekulatiivisesta suorituksesta siellä puhutaan lähinnä:
Kieltäen:
1) ldfence-käskyn yli ei tehdä spekulatiivista suoritusta. Ja tässä nimenomaan todetaan, että spekulatiivisia muistiaccesseja saa vapaasti tehdä mikäli välissä ei ole lfence-käskyä.
2) far callien yli ei saa tehdä spekulatiivista suoritusta (3-136 vol 2a). Ja tämän yhteydessä taas muistutetaan LFENCE-käskystä keinona estää spekulatiivista suoritusta.
3) keskeytysten yli ei tehdä spekulatiivista suoritusta (2A 3-483)
4) far returnien yli (4-556 vol 2B)
5) syscallien yli (4-680 vol 2B)
6) sysenter-käskyjen yli (4-684 vol 2B)
7) sysexit-käsyjen yli (vol 2B 4-687)
8) sysret-käskyjen yli (4-690 vol 2B)
9) WRPKRU-käskylle missään tilanteessa
10) spekulatiiviset loadit on kielletty ainoastaan strong uncacheable-tyyppisille muistialueille (11-6 vol 3A)
Muuten
* puhutaan non-temporal-storejen yhteydessä spekulatiivisesta suorituksesta vanhoilla prosessoreilla. (vol1 10-13).
* Kappale 18 on uusi, kirjoitettu pandoran lippaan avaamisen jälkeen. Tämä koskee uusia ominaisuuksia jota uusiin prosessoreihin on lisätty näiltä suojautumiseksi, ja tuo on kirjoitettu nimenomaan että tämä kappale koskee vain prossessoreita joissa tämä suojausominaisuus on tuettu
* CLdemote-käskyn yhteydessä todetaan että spekulatiivista datanhakua(käytännössä cache prefetch) voi tapahtua koska vaan eikä koskaan voi luottaa siihen että sitä ei tapahtuisi (vol 2a, 3-143)
* CLFLUSH-käskyn yhteydessä sanotaan sama (vol2a, 3-145)
* CLFLUSHOPT-käskyn yhteydessä sanotaan sama (vol 2a, 147)
* mfence- ja prefetch-käskyjen ytheydessä sama (4-22 vol 2B, 4-406 vol 2B, 4-408 vol 2b, 7-2 vol 2D)
* Sivulla 3-204 vol2a puhutaan CPUID-bitistä joka kertoo, onko speculative store bypass disable tuettu ominaisuus
* Vol 2A-3-519 on selvästi lisätty pandoran lippaan avautumisen jälkeen. Selittää miten lfence-käskyä kannattaa käyttää, jotta tietyt sivukanavahyökkäykset voidaan estää
* Kappaleessa 8-4 vol 3a puhutaan siitä miten voidaan varmistua että itsemodifioiva koodi toimii oikein spekulatiivisen suorituksen kanssa
* Kappaleessa vol 33 – 8.2.2 (sivu 8-7) puhutaan muistin konsistenttiussäännöistä. Mainitaan että spekulatiivista suoritusta saa tehdä kunhan kappaleessa aiemmin mianitut säännöt pitävät paikkansa
Melko oleellisia juttu tulee näissä keskeytysten ja exceptioneiden ja spekulatiivisen suorituksen suhteesta:
vol 3a- 4-40:
vol 3a 4-43:
vol 3a 4-50:
vol 3a-65
Ja samaan liittyen lisää:
vol 3a 6-31 puhuu invalid opcode exceptionista:
vol 3a -11-19:
Kappale 19 sitten puhuu suorituskykylaskureista , osa näistä liittyy spekulatiiviseen suoritukseen
Tuon uutisen jälkeen on paikattu ainakin Bloomfield. Tätä ei ole laajasti uutisoitu, mutta tässä esim. linkki HP:n uusiin BIOS-versioihin:
New Microcode for Bloomfield and Gulftown
http://www.techpowerup.com
Muistaakseni TechYesCityn kaveri huomasi tämän joskus 2019 ja kun hän myy käytettyjä tietokoneita noilla Xeoneilla, niin kävi manuaalisesti poistamassa ne paikat, että sai suorituskykyä paremmaksi. Tai se oli 2nd gen core.
Joka tapauksessa, kaikessa hiljaisuudessa noita on päivitetty muualtakin kuin HP:n toimesta.
—
edit: jaha, tämä oli Apple-ketjussa. No Windows-puolella on päivitetty ja noita prosessoreja oli PowerMaceissä (Xeon).
286:n MMU ei toimi eri periaatteella kuin myöhemissäkään kun aivan yhteensopiva MMU löytyy kaikista x86-prosessoreista. 386:een vain lisättiin segmentin koon muuttaminen ja sivutusyksikkö segmentointiyksikön perään. No 64-bittisessä moodissa segmentointi ei ole enää tuettuna mutta kaikki x86-prosessorit on naimisissa tuon 286:n segmentointiarkkitehtuurin kanssa.
Ja aika ronskisti sanottu että se on alkeellinen ja kämäinen, segmentointi on vain erilainen tapa hoitaa muistinsuojaus ja ei se missään tapauksessa ole yksiselitteisesti huonompi vaihtoehto, etenkin nyt kun nämä samoihin lineaarisiin osoitteisiin kohdistuneet sivukanavahyökkäyksetkin ovat osoittaneet. Hankalampihan se on kooderille mikä lienee se suurin syy lineaarisen virtuaalimuistiavaruuden suosimiselle. Selkeät edut muistinsuojauksessa kuitenkin segmentoinnilla.
Intelin 286 oli ensimmäinen integroidulla MMU:lla varustettu cpu, kilpailijoiden MMU:t olivat samaan aikaan yhtä suuria piirejä kuin itse cpu:kin. Heitto että MMU 286:ssa vie suurinpiirtein puolet ytimen pinta-alasta ei ole kaukaa haettu.
Ja muistinsuojaushan se tärkein MMU:n tehtävä on virtuaalimuistin ohella, ja MMU:n toiminnan kuvaus sivutuksesssa on että osoite muunnetaan, käyttöoikeudet tarkistetaan jonka jälkeen osoitemuunnoksen data luovutetaan, ellei oikeudet riitä suorittava käsky perutaan ja nostetaan poikkeus. Meltdown-prossuissa on tämän suhteen aivan periaatteellinen virhe, data luovutetaan ilman käyttöoikeutta. Mä en ymmärrä miten jaksat saivarrella että Meltdown-prossut toimivat speksiensä mukaisesti, jos MMU:n toiminta speksataan nin päin että data luovutetaan ensin ja käyttöoikeudet tarkistetaan myöhemmin sillehän nauraa kaikki. Meltdown olisi löydetty hiukan aikaisemmin jos Intel olisi rehellisesti dokumentoinut muistinsuojauksensa teknisen toteutuksen.
Ja mistä pääseekin siihen että miksi? Nythän näyttää vahvasti siltä että se oli ihan vain puhtaasti bugi eikä hallittu riski – Skylake saatiin korjattua tuon MMU:n toiminnan osalta eikä sen puoleen suorituskyky kuin tehonkulutus ottanut mitään merkittävää takapakkia puhumattakaan siitä että koko ydin olisi jouduttu suunnittelemaan uusiksi.
Meltdown ei ole mikään sivukanavahyökkäys, siinähän vain luetaan osoitetta johon ei ole oikeutta ja käytetään saatua tietoa seuraavissa käskyissä cachen tilan muutttamiseen josta se sivukanavahyökkäysellä voidaan tulkita. Eli käskyt koodissa eivät ole spekulatiivisiä vaan suoritettavaksi tarkoitettuja joiden datan lukuoikeudet muistinsuojauksen pitäisi evätä. Nimenomaan muistinsuojaus pettää -> selkeä vika MMU:n toiminnassa.