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:
This document contains the following: Volume 1: Describes the architecture and programming environment of processors supporting IA-32 and Intel® 64 architectures. Volume 2: Includes the full instruction set reference, A-Z. Describes the format of the instruction and provides reference pages for...
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.
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
