Apple siirtyy Mac-tietokoneissa Arm-prosessoreiden myötä omiin näytönohjaimiinsa

Liittynyt
17.10.2016
Viestejä
11 941
Nvidiallahan käytti TBR:ää Maxwellissa ja Pascalissa ja sen arvioitiin olevan osasyy hyvään hyötysuhteeseen.

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.
 

Kaotik

Banhammer
Ylläpidon jäsen
Liittynyt
14.10.2016
Viestejä
21 449
Nvidiallahan käytti TBR:ää Maxwellissa ja Pascalissa ja sen arvioitiin olevan osasyy hyvään hyötysuhteeseen.
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ä
 
Liittynyt
01.01.2017
Viestejä
398
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?
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.
 

Kaotik

Banhammer
Ylläpidon jäsen
Liittynyt
14.10.2016
Viestejä
21 449
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 :beye:
 

finWeazel

Chief Karpfen
Liittynyt
15.12.2019
Viestejä
7 811
Hyvä tuore podcasti missä patterson kertoilee cpu:n suunnittelemisesta. Melko laadukas pätkä, tosin sisältö on enemmänkin introduction to ... kuin deep dive.



Otti myös kantaa appleen ja arm:iin.

 

VmH

Liittynyt
06.02.2020
Viestejä
906
Mistähän "jämähtäneestä arkkitehtuurista" nyt oikein puhut? Kertoisitko lisää?
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.
 

VmH

Liittynyt
06.02.2020
Viestejä
906
Ei Intelin arkkitehtuuri mihinkään jumahtanut. Intelillä on ollut vuosia useita arkkitehtuureita valmiina, mutta ei ole ollut tehtaita missä niitä valmistaa kun 10nm prosessin kehitys failasi.
Kuulostaa siis siltä, että kehitys jumahti jos kerta 10nm kehitys failasi. Sillä aikaa AMD:ltä pukkaa jo seuraavaa iteraatiota 7nm zenistä...
 
Viimeksi muokattu:
Liittynyt
22.10.2016
Viestejä
11 030
Esim. Viimeisimmässä Intelin suorittimessa edelleen samat tietoturva -bugit, joista intel on vain ilmoittanut tylysti että eivät korjaa.
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ä.

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.
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?
 
Viimeksi muokattu:

VmH

Liittynyt
06.02.2020
Viestejä
906
Mistähän tietoturvabugeista nyt oikein 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.



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.
 
Liittynyt
22.10.2016
Viestejä
11 030
Kuulostaa siis siltä, että kehitys jumahti jos kerta 10nm kehitys failasi. Sillä aikaa AMD pukkaa jo seuraavaa iteraatiota 7nm zenistä...
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.
 

Kaotik

Banhammer
Ylläpidon jäsen
Liittynyt
14.10.2016
Viestejä
21 449
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.
 
Liittynyt
22.10.2016
Viestejä
11 030
Meltdown (security vulnerability) - Wikipedia

Jaa että muistin lukeminen lennosta ei ole tietoturva bugi?

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.

Voisit muutenkin vähän rauhoittua etkä ottaa näitä asioita niin henkilökohtaisesti.
Voisitko sinä ensin lopettaa näiden valheiden postaamisen?
 

VmH

Liittynyt
06.02.2020
Viestejä
906
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 ymä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ä yritetään suorittaa käskyä, joka lukee osoitetta, jota ei ole oikeutta 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.
 
Liittynyt
22.10.2018
Viestejä
9 544
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 ymä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?
Miksi sitten jotain patchejä on tehty kiireellä kaikkialle jos kyse on vaan kaikkien tiedossa olleesta speksien mukaisesta toiminnasta?
 
Liittynyt
17.10.2016
Viestejä
11 941
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.
 
Liittynyt
22.10.2016
Viestejä
11 030
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.
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.
 

Kaotik

Banhammer
Ylläpidon jäsen
Liittynyt
14.10.2016
Viestejä
21 449
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.
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.
 
Liittynyt
22.10.2016
Viestejä
11 030
Miksi sitten jotain patchejä on tehty kiireellä kaikkialle jos kyse on vaan kaikkien tiedossa olleesta speksien mukaisesta toiminnasta?
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).

Ja sitten tosiaan (vasta) alle 3 vuotta sitten pandoran lipas kunnolla avattiin sen suhteen, että sivukanavahyökkäyksiä voi tehdä spekulatiivista suoritusta hyödyntäen
 
Viimeksi muokattu:

VmH

Liittynyt
06.02.2020
Viestejä
906
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.
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ä.
 
Liittynyt
22.10.2018
Viestejä
9 544
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).

Ja sitten tosiaan (vasta) alle 3 vuotta sitten pandoran lipas kunnolla avattiin sen suhteen, että sivukanavahyökkäyksiä voi tehdä spekulatiivista suoritusta hyödyntäen
Okei, eli virhe/bugi oli suunnittelussa eikä toteutuksessa.
 

moukula

Team AMD
Liittynyt
17.10.2016
Viestejä
2 468

an unexpected defect, fault, flaw, or imperfection

Tämän perusteella voisi kyllä sanoa että kyllä nuo haavoittuvuudet ovat bugeja.
 

VmH

Liittynyt
06.02.2020
Viestejä
906

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.
 

VmH

Liittynyt
06.02.2020
Viestejä
906
Haavoittuvuus ja bugi eivät ole sama asia. Lisäksi kyseinen haavoittuvuus on korjattu jo Coffee Lake Refresheissä (9. sukupolvi) rautatasolla
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ä.
 
Viimeksi muokattu:
Liittynyt
22.10.2016
Viestejä
11 030

Vastattu tälle paremmin sopivassa säikeessä, tällä säikeellä ei ole mitään tekemistä AMDn kanssa.

 
Liittynyt
03.01.2018
Viestejä
576
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.
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.
 
Liittynyt
22.10.2016
Viestejä
11 030
Huomautus - jätä tämä toistuva facepalmien viljeleminen pois viesteistä, ei kuulu asialliseen keskusteluun
No onhan meillä MMU speksattu varmaan jo 70-luvulla ellei aikaisemmin.
:facepalm:

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.

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

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ä.
 
Viimeksi muokattu:
Liittynyt
03.01.2018
Viestejä
576
:facepalm:

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.
Puolet 286:n pinta-alasta on sen MMU:ta. Ja MMU ei ollut mikään Intelin keksintö.



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 oikeatsi ole olemassa.
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:
 
Liittynyt
22.10.2016
Viestejä
11 030
Puolet 286:n pinta-alasta on sen MMU:ta.
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.

Ja MMU ei ollut mikään Intelin keksintö.
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.

Yleisesti lienee speksattu että TLB tarkistaa käyttöoikeuden ennen datan luovuttamista eteenpäin.
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:


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.

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

INtel sanoi:
The processor may cache translations required for prefetches and for accesses that are a result of speculative execution that would never actually occur in the executed code path.
vol 3a 4-43:

Intel sanoi:
The processor may create entries in paging-structure caches for translations required for prefetches and for accesses that are a result of speculative execution that would never actually occur in the executed code path.

vol 3a 4-50:
Intel sanoi:
Software must be prepared to deal with reads, instruction fetches, and prefetch requests to the affected linear address range that are a result of speculative execution that would never actually occur in the executed code path.
vol 3a-65

Intel sanoi:
The ability of a P6 family processor to speculatively execute instructions does not affect the taking of interrupts by the processor. Interrupts are taken at instruction boundaries located during the retirement phase of instruction execution; so they are always taken in the “in-order” instruction stream. See Chapter 2, “Intel® 64 and IA-32 Architectures,” in the Intel® 64 and IA-32 Architectures Software Developer’s Manual, Volume 1, for more information about the P6 family processors’ microarchitecture and its support for out-of-order instruction execution. Note that the Pentium processor and earlier IA-32 processors also perform varying amounts of prefetching and preliminary decoding. With these processors as well, exceptions and interrupts are not signaled until actual “inorder” execution of the instructions. For a given code sample, the signaling of exceptions occurs uniformly when the code is executed on any family of IA-32 processors (except where new exceptions or new opcodes have been defined)
Ja samaan liittyen lisää:

vol 3a 6-31 puhuu invalid opcode exceptionista:

Intel sanoi:
In Intel 64 and IA-32 processors that implement out-of-order execution microarchitectures, this exception is not generated until an attempt is made to retire the result of executing an invalid instruction; that is, decoding and speculatively attempting to execute an invalid opcode does not generate this exception. Likewise, in the Pentium processor and earlier IA-32 processors, this exception is not generated as the result of prefetching and preliminary decoding of an invalid instruction. (See Section 6.5, “Exception Classifications,” for general rules for taking of interrupts and exceptions.) The opcodes D6 and F1 are undefined opcodes reserved by the Intel 64 and IA-32 architectures. These opcodes, even though undefined, do not generate an invalid opcode exception.
vol 3a -11-19:
Intel sanoi:
Implicit caching occurs when a memory element is made potentially cacheable, although the element may never have been accessed in the normal von Neumann sequence. Implicit caching occurs on the P6 and more recent processor families due to aggressive prefetching, branch prediction, and TLB miss handling. Implicit caching is an extension of the behavior of existing Intel386, Intel486, and Pentium processor systems, since software running on these processor families also has not been able to deterministically predict the behavior of instruction prefetch.
Kappale 19 sitten puhuu suorituskykylaskureista , osa näistä liittyy spekulatiiviseen suoritukseen
 
Liittynyt
17.10.2016
Viestejä
21 885
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ä.
Tuon uutisen jälkeen on paikattu ainakin Bloomfield. Tätä ei ole laajasti uutisoitu, mutta tässä esim. linkki HP:n uusiin BIOS-versioihin:

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).
 
  • Tykkää
Reactions: VmH
Liittynyt
03.01.2018
Viestejä
576
Huomautus (Offtopicin jatko)
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.
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.


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).
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.
 
  • Tykkää
Reactions: VmH
Liittynyt
03.01.2018
Viestejä
576
Offtopicin jatko jo annetusta huomautuksesta huolimatta
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.
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.
 
  • Tykkää
Reactions: VmH
Toggle Sidebar

Statistiikka

Viestiketjut
237 473
Viestejä
4 163 431
Jäsenet
70 414
Uusin jäsen
O&G

Hinta.fi

Ylös Bottom