Mei 2018 - Basic Memory Management

  • Onderwerp starter Onderwerp starter Verwijderd lid 59
  • Startdatum Startdatum
  • Reacties 4
  • Weergaven 769
Basic memory management werkt! Een grote stap voorwaarts voor Vireo. Hiermee kunnen we enkele PCI-drivers maken en ondersteunen, kunnen we drive management maken en kunnen we later programma's en bestanden uitvoeren/openen. Maar dit is pas het begin. Na deze inleiding volgt zo’n 600 woorden uitleg over wat memory management nou eigenlijk inhoudt, als je dit wilt skippen kan je verder lezen bij ‘Dan nu eindelijk de update’.

Wat is (of gebeurd er met) memory management? Ik ben niet heel erg solid met uitleggen dus ik hoop dat dit goed komt… Memory, een verkorte aanduiding van RAM (Random Access Memory) is eigenlijk gewoon tijdelijke opslag. Je kan er letterlijk mee doen wat de naam zegt. Random Access (willekeurige toegang) betekent dat je op elk gewenst adres (<-- komen we later nog op terug) data kan lezen en schrijven. RAM houdt alleen gegevens ‘vast’ als er stroom op staat, in andere woorden: alleen als je computer aan staat. Daarna, is alles weg.

De simpele uitleg van wat memory management nou eigenlijk is, met behulp van een voorbeeld: Het besturingssysteem krijgt de vraag van een programma om een plek te zoeken voor bepaalde data, laten we als voorbeeld de tekst “Hello, world!” nemen (elk karakter is 1 byte). In dit voorbeeld hoeft de tekst alleen tijdelijk opgeslagen te worden en kan dus prima in RAM opgeslagen worden. Het zijn 13 karakters (spaties tellen mee) dus dat zijn 13 bytes. Het besturingssysteem moet vervolgens een plekje van 13 bytes zien te vinden die nog niet gebruikt wordt door een ander programma. Als het besturingssysteem die vindt dan moet hij het op die plek neerzetten, deze plek heeft een adres in een getal. Aangezien dit een 32-bits besturingssysteem is kan dat een adres zijn van 0 tot 2^32. Het adres wordt meestal afgebeeld in een hexadecimaal getal dus het minst is 0x00000000 en het grootste adres is 0xFFFFFFFF. Maar aan de andere kant, als het besturingssysteem dit niet vindt moet het dat programma stoppen en een error geven.

Dan, waarom dit slechts het begin is: Vireo ondersteund nu alleen physical memory management, terwijl virtual management veiliger is. Voor het physical/virtual gedeelte moeten we terug naar het vorige voorbeeld. Stel het besturingssysteem heeft een plek gevonden, in physical memory management zou je het adres gelijk terug geven aan het programma. Het programma kan vervolgens ermee doen wat het wil, maar aangezien het systeem er geen limieten voor kan opstellen kan het door schrijven en ook de ruimte van een ander programma overnemen. Natuurlijk ideaal voor een virus: Het enige wat het hoeft te doen is overal een 0 zetten vanaf het adres wat het kreeg en je systeem is onbruikbaar. Zeker aangezien het systeem moet bijhouden waar adressen zijn, dus alle adressen na dat adres wat het systeem aan het virus gegeven heeft wijzen nu naar de data van het virus, het systeem zal nooit weten dat het virus dat gedaan heeft want volgens het systeem is dat van een ander programma. Virtual memory management, paging, werkt anders. Terug naar het originele voorbeeld, het adres dat het systeem gevonden heeft hoeft niet het adres te zijn die het programma krijgt. Het programma krijgt dan een ander adres, maar het systeem houdt een soort tabel bij met welk physical adres bij welk virtuele adres hoort. Het programma kan ook alleen dingen lezen en schrijven in zijn eigen stukje land. Het zal nooit verder kunnen schrijven dan zichzelf dus een virus zoals hierboven beschreven heeft weinig nut.
 
Laatst bewerkt door een moderator:
Dan nu eindelijk de update

Het systeem kan het totale aantal RAM berekenen en niet alleen low en high.
Het systeem heeft een nieuw error systeem. Voorheen had het er geen, maar nu wel.

d01bacbdfbab95d0a2b5c3edff676d82.png


De huidige ondersteunde errors zijn:
- Unkown error (code 0)
- Couldn’t detect memory (code 55)
- Illegal operation (code 56)
- Failed allocating memory (code 57)

Aangezien ik geen idee had over standaard error codes, heb ik me laten inspireren door POST codes (van de BIOS), waarbij 55 gebruikt wordt voor ongevonden RAM. Hierna heb ik gewoon doorgeteld waarbij unkown error een uitzondering is.

Memory map wordt niet ondersteund omdat GRUB 64-bit adressen gebruikt. In plaats daarvan zeggen we gewoon, “alles na 10 MiB is van ons, afblijven!”. Deze oplossing wordt wel vaker gebruikt, al zou ik het niet de beste noemen. Maar, dit is meer dan genoeg en geen probleem zijn. Het systeem bijvoorbeeld zit nog steeds onder de 1 MiB, en zal er ook niet boven komen (hij is nu ~26 KB en GRUB is 5 MB, dit betekent dat er zo‘n 5 MiB, in het ergste geval 4 MiB, overblijft voor andere BIOS en kernel data).

Basic memory management is een groot onderdeel van deze versie. Het systeem kan meerdere stukken memory toewijzen (physical), natuurlijk zijn er nog geen programma’s dus dit is alleen voor eigen gebruik. Hierna kan het ook blokken weer weghalen als ze niet meer nodig zijn en daarna weer opnieuw toewijzen zonder problemen aan andere dingen. Ook kan het een grotere plek toewijzen dan de 1024 bytes, deze blokken worden dan gewoon simpelweg groter gemaakt.

8c02719dff456ea72d2c1bf27e353e4d.png


Builds zullen nu anders aangegeven worden. Voorheen deden we het nummer van een build, maar om het duidelijk te maken en te houden zullen we deze voortaan aanduiden als een versie nummer. Als voorbeeld nemen we een van de builds deze maand: build 412 revision 2. We gebruiken altijd [major.minor.build.revision] als aanduiding dus hier gaat ‘ie… Deze build zou versie 0.4.12.2 zijn. Major zal altijd een duizendtal zijn dus wanneer we de duizend halen zal het pas versie 1.0.0.0 zijn. Hondertallen zijn minor en dan is dit dus build 12 van versie 0.4.x.x, revisions zijn revisions en zullen gebruikt worden als er bijvoorbeeld een klein dingetje verbeterd moet worden of terwijl er aan hetzelfde onderwerp gewerkt wordt. Zo was 0.4.11 voor basic memory management en v0.4.12 de verbetering en uitbreiding van memory management.

De laatste versie van deze update is 0.4.12.21, deze probeert paging aan te zetten maar faalt, vervolgens kan het systeem niet verder en blijft dus hangen. De belangrijkste versies deze update op een rijtje:
- v0.4.11.1 eerste build met functionele memory allocation
- v0.4.11.7 eerste build met functionele memory deallocation en reallocation
- v0.4.12.2 eerste build die in staat is grotere plekken dan 1024 bytes toe te wijzen
- v0.4.12.14 eerste build die paging probeert aan te zetten, maar faalt
- v0.4.12.21 de build die ons de huidige informatie heeft gegeven
 
Diagnostische info paging

Wanneer Vireo paging probeert in te schakelen, ontstaat er een DOUBLE_FAULT. Een DOUBLE_FAULT onstaat doordat er naast een onafgehandelde FAULT nog een FAULT ontstaat. Voor het volgende deel, weer een beetje uitleg. De CPU heeft registers deze worden gebruikt om te rekenen of om bepaalde informatie toe te passen of op te slaan. Alles met een 'e' ervoor (bijv. eax, edx, esi, edi en esp) zijn 32-bits adressen waar je bijna alles mee kan doen wat je wilt zoals rekenen en adressen tijdelijk op slaan. Daarnaast heb je nog CR registers, deze bevatten informatie die de CPU gebruikt waarvan je als besturingssysteem bij sommigen read/write access hebt. In geval van paging worden CR0, CR2 en CR3 gebruikt.

CR3 wordt gebruikt om het adres van de page directory (beetje info voor paging) in te stoppen. Op het moment dat we dat doen en paging aan zetten (bit 31 in CR0) ontstaat er een PAGE_FAULT. Dit is af te leiden aan (als we de logs van de virtuele machine gebruiken) CR2 een adres in zich heeft dit is het adres waar de PAGE_FAULT plaats heeft gevonden. Hierna heeft CR0 het nummer 0x60000010 (cache disable, not-write through en numeric error), belangrijk om te weten is dat het net daarvoor 0x80000011 was. 0x80000011 staat voor Protected mode enabled, numeric error en paging enabled. Misschien zie je het al ontstaan... Er ontstaat ergens een numeric error, we doen paging aan, dat veroorzaakt een PAGE_FAULT (fault #1) en tegelijkertijd zet de CPU (waarschijnlijk door de numeric error) Protected Mode uit wat nooit zomaar kan zonder een fault te creëren, dat is dus fault #2. Dus wat uitgezocht moet worden is wat de numeric error veroorzaakt en of dit inderdaad de oorzaak is voor 0x60000010 (of dat dit toch de PAGE_FAULT is) en waarom er een PAGE_FAULT onstaat.


Next up

Eerst gaan we aan de gang met Driveman (waar we weer ietsje verder mee zijn) en daarna komt ooit een keer paging, dus het huidige probleem wordt niet verholpen maar wordt weggestopt tot een andere keer. De rede dat ik hiervoor kies is zodat we het eerst allemaal functioneel maken en dan pas veiliger. Dus eerst nog wat andere milestonetjes pakken en dan komen we bij de rest.
 
Laatst bewerkt door een moderator:
feedback vraagje... Is dit te lang of is dit okay?
 
alle data tables gebruikt door AHCI staan in de kernel, binnenkort komt dus de functionaliteit van AHCI.
 
Terug
Bovenaan Onderaan