Les 1: wat is kernelspace?
Kernelspace is de benaming voor toestand van de computer waar processen elkaars geheugen kunnen sharen en elkaars memory kunnen overschrijven, kortweg: daar is geen memory protection. (ook wel Ring 0 genoemd op x86 processoren). Onder Win2k, NT en XP draait de kernel met alle kernelspace modules en kernelspace drivers (dat zijn: alle hardware aansprekende drivers) in 'kernelspace' en kunnen dus elkaars memory sharen en overschrijven.
In 'userspace' kan dat niet. Daar kunnen processen niet elkaars memory overschrijven, en wanneer dat wel gebeurt krijg je vrolijk een GPF, of wel een general protection fault.
Welnu: als je op je XP, NT of Win2k een driver installeert die buggy is, of beter: niet goed getest (bv een Creative Labs driver, een ATi driver, een Matrox driver, een kernel space component voor Easy CD creator...) dan kan het gebeuren dat wanneer dat onderdeel de CPU even krijgt, hij een stuk geheugen wil gaan vullen, bv een buffertje. Echter, de verwijzing naar dat buffertje staat niet goed, bv door een bug in de software (kan gebeuren, niet waar?). Hierdoor overschrijft het drivertje of het kernelspace componentje vrolijk een stukje geheugen wat eigenlijk niet had gemoeten. Bijvoorbeeld waar een deel van de NT/win2k/XP kernelcode staat, of waar kernel variables zijn opgeslagen.
Als dan de kernel weer de CPU krijgt en de code wil executeren wat juist is overschreven, dan staat daar niet de gewenste code, maar de data die eigenlijk in dat buffertje had gemoeten. Met als gevolg de executie van random bytes, wat veelal tot gevolg heeft dat het crasht.
Wanneer de XP/NT/win2k kernelcode niet erg is overschreven of bv wanneer kernelvariables zijn overschreven en de kernel merkt zelf dat er iets niet goed is, dan gaat hij een bugtraq sequence in. Deze sequence is ervoor dat alles weer goed komt. Veelal lukt dat (bij bv variables die overschreven zijn). Soms echter ook niet, en dan rest de kernel maar 1 ding en dat is een BSOD vermelden met de status van het systeem.
Draad kwijt? Dat kan goed. Je hoeft dit ook niet te weten. Wat je wel moet weten is dat je wilt dat t.a.t. je systeem blijft doordraaien. Maar dat dat ALLEEN kan wanneer ALLE componenten die op dat moment draaien (en dat zijn EN os componenten EN 3rd party componenten) goed getest zijn en elkaar niet overschrijven bij bugs.
Wanneer weet je of dat zo is? Wanneer je alleen componenten KUNT draaien die getest zijn. Wanneer is dat? wanneer je verplicht stelt dat die componenten getest worden alvorens ze uberhaupt geinstalleerd kunnen worden.
"Ja maar ik wil zo graag zelf bepalen wat ik installeer *jank jank*". Nee dat wil je niet. Jij wilt nl. echt niet dat jouw systeem in een STOP 0x1e knalt omdat je videodriver het op zn heupen heeft gekregen en ntoskrnl.dll heeft overschreven met bagger, zodat je je pas ingetikte verslag voor school of werk kwijt bent.
Of wil je dat wel? Indien je dat wel wilt: stel dat je systeem crasht op een moment dat je dat niet wilt (meerendeel van de gevallen

): wie ga je dan de schuld geven van de crash en je instabiele systeem? Jezelf, omdat je zo intens debiel dom hebt gedaan door kreupele troep te installeren tegen beter weten in? of Microsoft omdat ze een crap OS hebben geleverd? Ik weet het antwoord. Microsoft ook. Vandaar deze protection.
Voor de Linux mensen: daar is het precies eender: een kernel driver komt pas in de kernel als daar toestemming voor is gegeven. Tuurlijk kun je zelf proberen die driver in de kernel te compileren, maar een distributie van de kernel die iedereen normaliter zal draaien zal jouw driver niet in zich hebben TOTDAT is bewezen dat jouw driver goed is en geen crashes veroorzaakt.