[DISC]Drivers in Kernel of userspace (was: Kernel panic...)

[DieterVDW]

Ik zou voor testdoeleinden eens een kernel panic willen veroorzaken.
Weet er iemand een makkelijke manier om dit te doen?
Liefst zonder al te ingrijpende wijzigingen aan m'n systeem, en zonder een kernel recompile of zo... En zonder blijvende schade ook liefst .
Misschien door een ongeldige waarde mee te geven aan een bepaalde kernel parameter? Ik zie echter niet onmiddellijk een parameter die me daarvoor geschikt lijkt...
Iemand met veel ervaring ivm kernel panic's ?

Bedankt!

[ Voor 16% gewijzigd door DieterVDW op 24-08-2004 19:15 ]

[Verwijderd]

Niet-bestaande partitie als / mounten. Pas hiertoe lilo of grub of welke bootloader je ook gebruikt aan.

[4VAlien]

Als je een andere root partitie opgeeft dan normaal dan kan de kernel niet verder booten -> panic, maar ja je ziet er verder weinig aan af. Met brak geheugen ziet het er al een stuk leuker uit maar dat corrumpeert wel je data.

[DieterVDW]

Verwijderd schreef op 24 augustus 2004 @ 19:17:
Niet-bestaande partitie als / mounten. Pas hiertoe lilo of grub of welke bootloader je ook gebruikt aan.

Aha even proberen...

Edit: eerst nog even die 2.4.27 gecompiled krijgen grr ...

[ Voor 12% gewijzigd door DieterVDW op 24-08-2004 19:29 ]

[Verwijderd]

als je nou gewoon omgaat met je systeem, dan krijg je vanzelf vroeg of laat wel een kernel panic.

[DieterVDW]

Verwijderd schreef op 24 augustus 2004 @ 19:19:
als je nou gewoon omgaat met je systeem, dan krijg je vanzelf vroeg of laat wel een kernel panic.

Je dat weet ik ook wel, maar dat helpt mij niet echt hé...

[ Voor 11% gewijzigd door DieterVDW op 24-08-2004 19:24 ]

[Verwijderd]

Verwijderd schreef op 24 augustus 2004 @ 19:19:
als je nou gewoon omgaat met je systeem, dan krijg je vanzelf vroeg of laat wel een kernel panic.

Ligt eraan... ik heb in iets van 5 jaar dat ik Linux gebruik nog nooit een Kernel panic gehad

[Broer]

Probeer eens een kill:
op FreeBSD gaat het als volgt:

code:

dilithium# kill -SEGV 1
dilithium# 
Message from syslogd@dilithium at Tue Aug 24 20:27:42 2004 ...
dilithium init: fatal signal: Segmentation fault

Na een paar seconden zakt het systeem dan onderuit met een panic.

zal onder linux niet veel anders gaan, kijk anders in de manual page van kill hoe je signals naar het init proces kunt schieten.

[Wirf]

- Floppy mounten (mount /dev/fd0 /floppy ofzoiets)
- floppy eruit halen
- "iets" doen op de floppy (cd /floppy; ls)

volgens mij krijg je zo ook nog steeds een panic

[AlterEgo]

Wirf schreef op 24 augustus 2004 @ 20:43:
- Floppy mounten (mount /dev/fd0 /floppy ofzoiets)
- floppy eruit halen
- "iets" doen op de floppy (cd /floppy; ls)

volgens mij krijg je zo ook nog steeds een panic

echnie

[Wirf]

AlterEgo schreef op 24 augustus 2004 @ 20:55:
echnie

Niet? Oh, kun je nagaan hoe lang ik al geen floppies meer gebruik

[Mac_Cain13]

Wirf schreef op 24 augustus 2004 @ 20:43:
- Floppy mounten (mount /dev/fd0 /floppy ofzoiets)
- floppy eruit halen
- "iets" doen op de floppy (cd /floppy; ls)

volgens mij krijg je zo ook nog steeds een panic

Hmm, bij mij hingen net alle progjes die de floppy nodig hadden. Die bleven wachten op een reactie van de floppydrive en waren ook niet meer te killen, maar het systeem bleef netjes overeind hoor.

Mss dat je met bepaalde acties wel een mooie panic krijgt. Dat zou ik zo niet weten. ArchLinux 0.7 met kernel 2.6.8.1 overgens.

edit:
Grmbl Spuit 11, maar ik had lekker een langer verhaal

[ Voor 7% gewijzigd door Mac_Cain13 op 24-08-2004 20:57 ]

[Verwijderd]

Broer schreef op 24 augustus 2004 @ 20:32:
Probeer eens een kill:
op FreeBSD gaat het als volgt:

code:

dilithium# kill -SEGV 1
dilithium# 
Message from syslogd@dilithium at Tue Aug 24 20:27:42 2004 ...
dilithium init: fatal signal: Segmentation fault

Na een paar seconden zakt het systeem dan onderuit met een panic.

zal onder linux niet veel anders gaan, kijk anders in de manual page van kill hoe je signals naar het init proces kunt schieten.

[root@pluto ~]# kill -SEGV 1
INIT: PANIC: segmentation violation at 0x56f782! sleeping for 30 seconds.

[root@pluto ~]#

Verder geen panic ofzo

[ Voor 3% gewijzigd door Verwijderd op 24-08-2004 21:09 ]

[ajvdvegt]

Misschien kan je alle combinaties van SysRq eens proberen? Zie /usr/src/linux/Documentation/sysrq.txt voor meer info. SysRq-L lijkt een leuke kandidaat:

'l' - Send a SIGKILL to all processes, INCLUDING init. (Your system will be non-functional after this.)

Of is dit nog net ietsje minder erg dan een kernel panic? Ik ga het niet testen iig

[DieterVDW]

Heh, ironisch genoeg krijg ik nu ongewild een kernel panic als ik probeer kernel 2.4.27 te booten . Heb er al meer dan genoeg gezien nu!

Maar 'k ga wel es testen welke van de voorstellen hier werkt...

[kenneth]

AlterEgo schreef op 24 augustus 2004 @ 20:55:

echnie

Niet bij floppies die VFAT-formatted zijn nee, maar bij ext2 wel. Of ook allang niet meer?

[PowerSp00n]

Ok ik heb hier al allemaal mogelijkheden gezien. Maar je maakt me wel nieuwschierig waarvoor je een panic wil veroorzaken?

[Kees]

booten met root=/dev/hdx1 oid werkt ook niet

[DieterVDW]

PowerSp00n schreef op 25 augustus 2004 @ 01:39:
Ok ik heb hier al allemaal mogelijkheden gezien. Maar je maakt me wel nieuwschierig waarvoor je een panic wil veroorzaken?

Ik ga binnenkort een kernel upgrade moeten doen op een colocated server,
en daarom moet ik er zeker van zijn dat de server altijd bereikbaar blijft,
zélfs als de nieuwe kernel niet werkt (panic of zo) .
Ik ben dit nu aan het proberen op mijn linux bak hier lokaal...
Het makkelijkste is trouwens om de -R optie van lilo te gebruiken om éénmalig naar de nieuwe kernel te booten, en dan de kernel parameter panic=10 mee te geven zodat de kernel na 10 seconden reboot bij een panic.
Op die manier kom je terug bij je oude kernel terecht als de nieuwe kernel een panic geeft. Het enigste probleem is dan wel dat je niet weet waaróm je nieuwe kernel een panic geeft .

[PowerSp00n]

DieterVDW schreef op 25 augustus 2004 @ 02:55:
[...]


Ik ga binnenkort een kernel upgrade moeten doen op een colocated server,
en daarom moet ik er zeker van zijn dat de server altijd bereikbaar blijft,
zélfs als de nieuwe kernel niet werkt (panic of zo) .
Ik ben dit nu aan het proberen op mijn linux bak hier lokaal...
Het makkelijkste is trouwens om de -R optie van lilo te gebruiken om éénmalig naar de nieuwe kernel te booten, en dan de kernel parameter panic=10 mee te geven zodat de kernel na 10 seconden reboot bij een panic.
Op die manier kom je terug bij je oude kernel terecht als de nieuwe kernel een panic geeft. Het enigste probleem is dan wel dat je niet weet waaróm je nieuwe kernel een panic geeft .

Ik had het kunnen weten . Zelf heb ik alleen de ervaring dat het booten van een kernel juist op niet kernel panics fout loopt, dan heb je er nog niet veel aan . Problemen met de netwerk drivers enzo (vooral met de nog iets oudere kernels dan) wat weer een leuk ritje colocatie ruimte opleverde. 2.6 Kernels gaan tegenwoordig eigenlijk allemaal goed (op domme fouten na, zoals het vergeten van make modules_install enzo ).

[DieterVDW]

PowerSp00n schreef op 25 augustus 2004 @ 03:01:
[...]


Ik had het kunnen weten . Zelf heb ik alleen de ervaring dat het booten van een kernel juist op niet kernel panics fout loopt, dan heb je er nog niet veel aan . Problemen met de netwerk drivers enzo (vooral met de nog iets oudere kernels dan) wat weer een leuk ritje colocatie ruimte opleverde. 2.6 Kernels gaan tegenwoordig eigenlijk allemaal goed (op domme fouten na, zoals het vergeten van make modules_install enzo ).

Ja ik heb ook wel een flauw vermoeden dat er wel eens een ritje datacenter zal inzitten... Maar 't helpt toch al een beetje .

[Verwijderd]

C:

#include <linux/config.h>
#include <linux/types.h>
#include <linux/kernel.h>
#include <linux/module.h>
#include <linux/init.h>

static int __init
init_me (void)
{
  memset (NULL, 0, 100);
}

static void __exit
exit_me (void)
{
}

module_init(init_me);
module_exit(exit_me);

Compilen, insmod'en en have fun.

[ Voor 26% gewijzigd door Verwijderd op 25-08-2004 11:00 ]

[RickN]

Verwijderd schreef op 25 augustus 2004 @ 10:59:
[..code..]

Compilen, insmod'en en have fun.

Blijft toch lomp dat een willekeurig drivertje zomaar overal bij mag.

[ Voor 44% gewijzigd door RickN op 25-08-2004 11:05 ]

[blaataaps]

RickN schreef op 25 augustus 2004 @ 11:05:
[...]


Blijft toch lomp dat een willekeurig drivertje zomaar overal bij mag.

Ja gek heh, je laadt als root een stuk code in de kernel, schande dat dat ergens bij mag.

[igmar]

RickN schreef op 25 augustus 2004 @ 11:05:
Blijft toch lomp dat een willekeurig drivertje zomaar overal bij mag.

Drivers zijn onderdeel van de kernel, draaien in kernelspace en mogen dus per definitie overal bij. Daar is niks lomp aan, zo werkt een OS nu eenmaal.

[ Voor 13% gewijzigd door igmar op 25-08-2004 11:15 ]

[Kippenijzer]

Met een seriele console kun je op zich het hele boot process volgen, dus ook als een kernel panic-t en na 10 seconden reboot, kun je dan de foutmelding zien. Serieel console icm SysRq, en je zult niet snel meer naar de colocatieruimte hoeven.

[Sir Isaac]

edit:
Dit is een reactie op RickN en Blaataaps

Dat is nu de reden dat Tanenbaum (maker van Minix en voormalig docent van Linus), zegt dat Linus geen goed cijfer van hem zou krijgen voor het ontwerp van een operating system. Bij de mach kernel van gnu/hurd kan dit
niet: dat is een microkernel drivers die los van de microkernel staan.

[ Voor 10% gewijzigd door Sir Isaac op 25-08-2004 11:17 . Reden: beetje verdwaalde reactie ]

[RickN]

blaataaps schreef op 25 augustus 2004 @ 11:06:
[...]

Ja gek heh, je laadt als root een stuk code in de kernel, schande dat dat ergens bij mag.

Idd, dat is een schande, waarom jezelf beperken tot slechts twee "ringen": kernel en user? Er is _geen enkele_ reden dat een willekeurige driver zomaar overal in het geheugen kan gaan zitten klooien en in een goed design zou dat ook worden voorkomen.

igmar schreef op 25 augustus 2004 @ 11:07:
[...]


Drivers zijn onderdeel van de kernel, draaien in kernelspace en mogen dus per definitie overal bij. Daar is niks lomp aan, zo werkt een OS nu eenmaal.

Onzin, dat is helemaal niet noodzakelijk.

Ik vind het prachtig werk hoor, wat die jongens daar met de linux kernel doen, super veel respect voor. Maar dat neemt niet weg dat er in hindsight best het één en ander op het design valt aan te merken. En een kut drivertje dat het volledige systeem naar beneden trekt is zéker wel één van die dingen, als je dat niet ziet hebt je kennelijk zelf niet al te veel verstand van zaken...

[blaataaps]

Het is dus raar dat iemand met root- dan wel administratorprivileges een stuk code aan de kernel kan geven dat het eventueel kan laten crashen?

[RickN]

blaataaps schreef op 25 augustus 2004 @ 11:34:
Het is dus raar dat iemand met root- dan wel administratorprivileges een stuk code aan de kernel kan geven dat het eventueel kan laten crashen?

Je denkt teveel in termen van hoe het nu eenmaal is. Als je root defineert als iemand die alles, maar dan ook echt alles kan en mag, dan is het niet raar nee. Maar geef mij één goede reden voor een dergelijke sadomasochistische definitie? Als je tot doel hebt een in de eerste plaats stabiel en robuust systeem te maken dan design je je systeem gewoon anders. Een driver hóeft niet overal bij te kunnen en zou zelfs niet als root hoeven draaien.
Dát het zo gebeurt in de linux kernel verklaart niet waaróm het zo gebeurt en we kunnen er lang over lullen, maar het is geen ideale situatie.
Als jij vind dat een driver overal bij mag, vraag ik me af waarom een gebruiker dat dan niet zou mogen. Net als bij de driver is het nergens voor nodig, maar als we dan toch onnodige rechten aan het uitdelen zijn...

Waarom denk je dat er überhaupt drivers, api's en abstraction layers zijn? Natuurlijk om te abstraheren van het onderliggende systeem, maar _ook_ om het systeem te beschermen tegen destructief gebruik van de onderliggende resources.

[ Voor 14% gewijzigd door RickN op 25-08-2004 11:54 ]

[blaataaps]

RickN schreef op 25 augustus 2004 @ 11:49:
[...]


Je denkt teveel in termen van hoe het nu eenmaal is. Als je root defineert als iemand die alles, maar dan ook echt alles kan en mag, dan is het niet raar nee. Maar geef mij één goede reden voor een dergelijke sadomasochistische definitie? Als je tot doel hebt een in de eerste plaats stabiel en robuust systeem te maken dan design je je systeem gewoon anders. Een driver hoeft niet overal bij te kunnen en zou zelfs niet als root hoeven draaien.
Dat het zo gebeurt in de linux kernel verklaart niet waarom het zo gebeurt en we kunnen er lang over lullen, maar het is geen ideale situatie.
Als jij vind dat een driver overal bij mag, vraag ik me af waarom een gebruiker dat niet zou mogen. Net als bij de driver is het nergens voor nodig, maar als we dan toch onnodige rechten aan het uitdelen zijn...

Ik zeg niet dat de huidige situate de theoretische perfecte is, maar op dit moment wel een van de meest practisch bruikbare
Een driver hoeft van mij niet overal bij te kunnen nee, dat zeker niet, maar een bepaalde vorm van oppermachtigheid als superuser vind ik zeker wel prettig. Het is niet op elk moment nodig, maar als ik op een bepaald moment een stuk code met bepaalde macht wil laten draaien vind ik dat dat moet kunnen als superuser. Dat dat niet op elke willekeurige manier en moment moet kunnen vind ik ook niet, bepaalde patches voor linux limiteren de toegang voor root tot bepaalde dingen, bij de bsd's heb je securelevels die alleen opgehoogd kunnen worden, waardoor bepaalde functionaliteit ook niet meer beschikbaar is voor root, maar al die restricties zijn door de superuser gemaakt.
Dat iemand die vindt dat een driver overal bij moet kunnen ook vindt dat een gebruiker overal bij moet kunnen is natuurlijk onzin lijkt mij, de gebruiker is meestal met een reden geen superuser, root is dat wel.
Ik ben ook niet van mening dat /elke/ driver /overal/ toegang toe moet hebben, ik ben wel van mening dat als ik als beheerder vindt dat iets moet gebeuren, dat een bepaald stuk code een bepaalde toegang moet hebben op een bepaald moment, dat dat moet gebeuren

[RickN]

blaataaps schreef op 25 augustus 2004 @ 11:59:
[...]

Ik zeg niet dat de huidige situate de theoretische perfecte is, maar op dit moment wel een van de meest practisch bruikbare

Daarmee ben ik heb vanaf het begin van deze discussie al eens, en mijn eerste opmerking was dan ook meer een meimerende gedachte van: "Tssk, toch jammer."

Een driver hoeft van mij niet overal bij te kunnen nee, dat zeker niet, maar een bepaalde vorm van oppermachtigheid als superuser vind ik zeker wel prettig. Het is niet op elk moment nodig, maar als ik op een bepaald moment een stuk code met bepaalde macht wil laten draaien vind ik dat dat moet kunnen als superuser. Dat dat niet op elke willekeurige manier en moment moet kunnen vind ik ook niet, bepaalde patches voor linux limiteren de toegang voor root tot bepaalde dingen, bij de bsd's heb je securelevels die alleen opgehoogd kunnen worden, waardoor bepaalde functionaliteit ook niet meer beschikbaar is voor root, maar al die restricties zijn door de superuser gemaakt.

En als je goed over dergelijke concepten gaat nadenken en je je systeem van de grond af erop baseert kun je tot een beter design komen dan de huidige kernel.

Dat iemand die vindt dat een driver overal bij moet kunnen ook vindt dat een gebruiker overal bij moet kunnen is natuurlijk onzin lijkt mij, de gebruiker is meestal met een reden geen superuser, root is dat wel.

De vergelijking was wat overtrokken natuurlijk, maar die driver is wel geschreven door een niet perfect mens, dat bovendien ook geen root rechten op jouw systeem heeft....

Ik ben ook niet van mening dat /elke/ driver /overal/ toegang toe moet hebben, ik ben wel van mening dat als ik als beheerder vindt dat iets moet gebeuren, dat een bepaald stuk code een bepaalde toegang moet hebben op een bepaald moment, dat dat moet gebeuren

Wellicht, al betwijfel ik of het nodig is een mens de macht te geven het systeem op een destructieve manier naar beneden te trekken, daar heb je shutdown commando's voor. Ik vind sowieso dat als er een opergod-account bestaat dat dit dan niet het standaard admin account moet zijn.
En wat betreft een drivertje, ik vind dat een drivertje een beetje geheugen zou moeten krijgen en verder alleen naar een paar predefined poorten en symbolen in de kernel zou moeten mogen schrijven. En wat mij betreft hoeft zelfs het opergod account dat niet te kunnen overriden, omdat zo'n actie haast per definitie de stabiliteit van de rest van het systeem in gevaar brengt.

[blaataaps]

RickN schreef op 25 augustus 2004 @ 12:14:

[...]

De vergelijking was wat overtrokken natuurlijk, maar die driver is wel geschreven door een niet perfect mens, dat bovendien ook geen root rechten op jouw systeem heeft....

De kernel (micro dan wel monolithic) is dat meestal ook (ten minste, ik geef eerlijk toe dat ik weinig werk op systemen met een eigengeschreven kernel)

Wellicht, al betwijfel ik of het nodig is een mens de macht te geven het systeem op een destructieve manier naar beneden te trekken, daar heb je shutdown commando's voor. Ik vind sowieso dat als er een opergod-account bestaat dat dit dan niet het standaard admin account moet zijn.

Dan verschillen we hier gewoon van mening denk ik, ik vind dat dat wel moet kunnen (hoewel niet op elk moment, maar de bescherming moet wmb optioneel zijn). Ik kan de binary die op de schijf staat veranderen, daar gaat het stuk van, waarom zou ik dan niet in de draaiende binary mogen harken tot het stukgaat bij wijze van spreken.

En wat betreft een drivertje, ik vind dat een drivertje een beetje geheugen zou moeten krijgen en verder alleen naar een paar poorten en symbolen in de kernel zou moeten mogen schrijven. En wat mij betreft hoeft zelfs het opergod account dat niet te kunnen overriden, omdat zo'n actie haast per definitie de stabiliteit van de rest van het systeem in gevaar brengt.

Zit ook wel wat in, maar ik ben op zich graag oppermachtig op mijn eigen systeem
Volgens mij zijn we het technisch inmiddels met elkaar eens op een klein meningsverschil na of niet? Theoretisch zijn er veel betere en mooiere dingen te bedenken, jammer dat ze allemaal zo theoretisch zijn en (nog) niet werkbaar.

[RickN]

blaataaps schreef op 25 augustus 2004 @ 12:25:
[...]

Volgens mij zijn we het technisch inmiddels met elkaar eens op een klein meningsverschil na of niet? Theoretisch zijn er veel betere en mooiere dingen te bedenken, jammer dat ze allemaal zo theoretisch zijn en (nog) niet werkbaar.

Yep

[igmar]

RickN schreef op 25 augustus 2004 @ 11:31:
Idd, dat is een schande, waarom jezelf beperken tot slechts twee "ringen": kernel en user? Er is _geen enkele_ reden dat een willekeurige driver zomaar overal in het geheugen kan gaan zitten klooien en in een goed design zou dat ook worden voorkomen.

Omdat de MMU van de CPU nu eenmaal zo werkt ? Indien je aan pages zit die niet gemapped zijn krijg je een oops, en als je aan page 0 zit ook, en dat was met het stuk voorbeeld code het geval. Er is geen enkele manier om onderscheid te maken tussen legale en niet legale access op een pagina, iig niet zonder extreem veel overhead.

Onzin, dat is helemaal niet noodzakelijk.

Ik vind het prachtig werk hoor, wat die jongens daar met de linux kernel doen, super veel respect voor. Maar dat neemt niet weg dat er in hindsight best het één en ander op het design valt aan te merken. En een kut drivertje dat het volledige systeem naar beneden trekt is zéker wel één van die dingen, als je dat niet ziet hebt je kennelijk zelf niet al te veel verstand van zaken...

Misschien moet je je toch maar eens gaan verdiepen in hoe een MMU van een CPU werkt, dan kom je er ook achter waarom het niet anders kan.

[igmar]

[b][message=21506996,noline]RickN schreef op 25 augustus 2004 @ 12:14En wat betreft een drivertje, ik vind dat een drivertje een beetje geheugen zou moeten krijgen en verder alleen naar een paar predefined poorten en symbolen in de kernel zou moeten mogen schrijven.

En hoe wou je dat gaan regelen ? dat betekend dat je elke vorm van toegang tot elke locatie moet gaan controleren, nog afgezien van het feit dat het niet kan zit je met beperkingen in de MMU, en het feit dat alle CPU's met pages werken.

[Guru Evi]

Je kunt ook de lkm (loadable kernel modules) uitschakelen als je je kernel hercompileert, SELinux gebruiken, je root gebruiker geen rechten geven. Het valt te bezien hoe je het wilt.

[RickN]

igmar schreef op 25 augustus 2004 @ 14:04:
[...]


Omdat de MMU van de CPU nu eenmaal zo werkt ? Indien je aan pages zit die niet gemapped zijn krijg je een oops, en als je aan page 0 zit ook, en dat was met het stuk voorbeeld code het geval. Er is geen enkele manier om onderscheid te maken tussen legale en niet legale access op een pagina, iig niet zonder extreem veel overhead.


[...]


Misschien moet je je toch maar eens gaan verdiepen in hoe een MMU van een CPU werkt, dan kom je er ook achter waarom het niet anders kan.

igmar schreef op 25 augustus 2004 @ 14:07:
[...]


En hoe wou je dat gaan regelen ? dat betekend dat je elke vorm van toegang tot elke locatie moet gaan controleren, nog afgezien van het feit dat het niet kan zit je met beperkingen in de MMU, en het feit dat alle CPU's met pages werken.

Als je dat geweldige stukje code als gewone user uitvoert, knalt dan ook je hele systeem eruit? Nee? Joh, misschien is dat dan ook wel een goed idee voor drivers. Of om als generiek concept te gebruiken. En dan hoef je echt niet met de MMU aan te komen, want daar abstraheer je al in één van de eerste lagen van je OS van. Gescheiden geheugen regions doe je dan maar in software, net zoals je nu ook al kernel en user mem hebt.

Je moet een misschien een beetje out of the box denken, er zijn meer manieren om een OS te ontwerpen dan hoe ze het in linux hebben gedaan hoor. En er zijn ook meer cpu's als x86, met betere, maar ook zonder MMU waar linux op draait.

[ Voor 5% gewijzigd door RickN op 25-08-2004 15:30 ]

[TGEN]

igmar schreef op 25 augustus 2004 @ 14:07:
[...]


En hoe wou je dat gaan regelen ? dat betekend dat je elke vorm van toegang tot elke locatie moet gaan controleren, nog afgezien van het feit dat het niet kan zit je met beperkingen in de MMU, en het feit dat alle CPU's met pages werken.

Drivers kan je best in userspace implementeren, waarbij je de echte kernelspace commando's via gates kan doorlinken, met de nodige checks. En die checks leveren echt niet zoveel overhead op hoor, als je lightweight processes hebt kan je safetychecks met hashes in gemiddeld minder dan 20 instructies onder een CISC arch afhandelen, en rond de 40 in RISC archs. Dat noem ik geen grote penalty voor een veilig systeem.

[igmar]

RickN schreef op 25 augustus 2004 @ 15:06:
Als je dat geweldige stukje code als gewone user uitvoert, knalt dan ook je hele systeem eruit? Nee? Joh, misschien is dat dan ook wel een goed idee voor drivers.

Nee, omdat het betreffende adres 0 gewoon een ander adres is, en kernel code in een andere ring draait.

Of om als generiek concept te gebruiken. En dan hoef je echt niet met de MMU aan te komen, want daar abstraheer je al in één van de eerste lagen van je OS van. Gescheiden geheugen regions doe je dan maar in software, net zoals je nu ook al kernel en user mem hebt.

Dat wordt door de MMU geregeld. Blijft de vraag over : Hoe wou je controleren dat drivers niet aan adressen komen waar ze niet aan mogen komen ?

Het idee is leuk, maar gezien het feit dat geen enkel OS het nog implementeert doet mij denken dat er toch wat problemen zijn.

Je moet een misschien een beetje out of the box denken, er zijn meer manieren om een OS te ontwerpen dan hoe ze het in linux hebben gedaan hoor. En er zijn ook meer cpu's als x86, met betere, maar ook zonder MMU waar linux op draait.

Linux, BSD, SOlaris, etc, etc, etc. Allemaal een soortgelijk design. Niemand die het op jouw manier doet, waarom ?

[igmar]

TGEN schreef op 25 augustus 2004 @ 15:15:
Drivers kan je best in userspace implementeren, waarbij je de echte kernelspace commando's via gates kan doorlinken, met de nodige checks.

Ah, en hoe wou je 5000 interrupts per seconde gaan afhandelen ? Per interrupt een context switch als je pech hebt. Driver in userspace zijn d'r al, en waarom gebruikt niemand ze (op ontwikkelen na) ? Precies, omdat het gewoonweg te traag is.

En die checks leveren echt niet zoveel overhead op hoor, als je lightweight processes hebt kan je safetychecks met hashes in gemiddeld minder dan 20 instructies onder een CISC arch afhandelen, en rond de 40 in RISC archs. Dat noem ik geen grote penalty voor een veilig systeem.

De checks niet, de overige overhead wel. Deze discussie is op lkml al een paar keer gevoerd, en de uitkomst : Drivers in userspace zijn niet haalbaar.

[RickN]

Zucht, je reageert telkens alsof ik voorstel om eventjes een patchje voor linux te schrijven dat alle problemen oplost. We lullen gewoon langs elkaar heen zo.

Mijn observatie was dat een 10 regelig drivertje linux de benen kan breken en dat dat een kwalijke situatie is. Dan kun je vervolgens wel gaan uitleggen waarom het zo is, maar die, al dan niet fundamentele, argumenten veranderen niets aan de situatie.

User processen in linux kunnen ook niet zomaar in elkaars geheugen gaan rommelen. Dus alles wat je in user space kunt duwen maakt het systeem er in theorie stabieler en robuuster op. Dat is wat een OS als Minix en de Mach micro kernel ook proberen. Dat dat dat ten koste gaat van performance valt moeilijk te ontkennen, maar multitasking gaat ook ten koste van performance. Een statisch gescheduled systeem is sneller, maar ook iets minder flexibel. Dat zijn gewoon afwegingen die je moet maken en misschien wordt het wel tijd om de extra performance die intel ons elk jaar geeft om te zetten in wat extra stabiliteit.

Hoe dan ook, het micro kernel concept is bepaald niet nieuw en wordt in academische kringen toch echt wel gezien als hoe een OS design zou moeten zijn. Wat ook niet nieuw is zijn de practische problemen die de implementatie van zo'n design nou niet direct eenvoudig maken. Zo heeft ook minix z'n drivers in kernel space draaien, omdat de beperkte MMU van x86 procs een andere implementatie erg moeilijk zou maken. Inmiddels is er natuurlijk het één en ander verbetert en misschien zijn er nu meer mogelijkheden voor user space drivers, een googletje geeft in elk geval voldoende resultaten van projecten die het proberen. Het concept van het strikter scheiden van de subsystemen van een OS staat of valt ook niet met user space drivers, er is voldoende te verbeteren zelfs als de drivers in de kernel blijven. Bovendien zijn architecturele beperkingen er om verwijderd te worden. Als er voor veiligheid en stabiliteit vraag ontstaat naar een bepaalde feature, dan komt die er (NX bit).

[ Voor 10% gewijzigd door RickN op 26-08-2004 12:51 ]

[Verwijderd]

RickN schreef op 25 augustus 2004 @ 11:05:
Blijft toch lomp dat een willekeurig drivertje zomaar overal bij mag.

Even buiten de algemene lompheid van deze opmerking wil ik nog even opmerken dat het zo ongelofelijk veel bloat zou toevoegen aan de kernel als er een aparte sandbox space voor drivers zou komen, dat niemand Linux meer zou willen gebruiken. Ken je feiten.

Een driver hoort nou eenmaal niet als doel te hebben de kernel te crashen. Als je computer al zo ver gekraakt was, dan ligt dat echt niet aan de kernel; je security lek ligt dan ergens anders.

[igmar]

RickN schreef op 26 augustus 2004 @ 12:38:
Zucht, je reageert telkens alsof ik voorstel om eventjes een patchje voor linux te schrijven dat alle problemen oplost. We lullen gewoon langs elkaar heen zo.

Je doet voorkomen of degene die Linux ontwerpen hebben een stelletje achterlijke gladiolen zijn. Als je ideeen doet voorkomen als een oplossing voor een probleem moet het wel reeel zijn, en met alle respect, dat zijn ze met de huidige hardware niet.

Mijn observatie was dat een 10 regelig drivertje linux de benen kan breken en dat dat een kwalijke situatie is. Dan kun je vervolgens wel gaan uitleggen waarom het zo is, maar die, al dan niet fundamentele, argumenten veranderen niets aan de situatie.

Helaas is het niet anders.

User processen in linux kunnen ook niet zomaar in elkaars geheugen gaan rommelen. Dus alles wat je in user space kunt duwen maakt het systeem er in theorie stabieler en robuuster op. Dat is wat een OS als Minix en de Mach micro kernel ook proberen.

Met Minux heeft het andere redenen, niet om het stabiel te krijgen. Minix is bedoeld om van te leren, en het in userspace draaien van het FS had daar mede mee te maken.

Dat dat dat ten koste gaat van performance valt moeilijk te ontkennen, maar multitasking gaat ook ten koste van performance. Een statisch gescheduled systeem is sneller, maar ook iets minder flexibel. Dat zijn gewoon afwegingen die je moet maken en misschien wordt het wel tijd om de extra performance die intel ons elk jaar geeft om te zetten in wat extra stabiliteit.

In de kernel wordt in het geheel niet gescheduled, dat is ook de reden waarom kernelspace voor zowat alle toepassingen sneller is.

Hoe dan ook, het micro kernel concept is bepaald niet nieuw en wordt in academische kringen toch echt wel gezien als hoe een OS design zou moeten zijn. Wat ook niet nieuw is zijn de practische problemen die de implementatie van zo'n design nou niet direct eenvoudig maken. Zo heeft ook minix z'n drivers in kernel space draaien, omdat de beperkte MMU van x86 procs een andere implementatie erg moeilijk zou maken. Inmiddels is er natuurlijk het één en ander verbetert en misschien zijn er nu meer mogelijkheden voor user space drivers, een googletje geeft in elk geval voldoende resultaten van projecten die het proberen. Het concept van het strikter scheiden van de subsystemen van een OS staat of valt ook niet met user space drivers, er is voldoende te verbeteren zelfs als de drivers in de kernel blijven. Bovendien zijn architecturele beperkingen er om verwijderd te worden. Als er voor veiligheid en stabiliteit vraag ontstaat naar een bepaalde feature, dan komt die er (NX bit).

Het NX bit is zeker een goede stap, maar op Intel zit je altijd met backwards compatibility. Sparc heeft al dit soort problemen namelijk totaal niet, maar de enige reden voor Intel hardware is de kostprijs en het feit dat 95% van de wereld Windows draait.

Verder is monolithic vs microkernel een lopende discussie, en aan een microkernel kleven ook nadelen, en drivers halen dan net zo makkelijk een OS onderuit. Ik zie dit voorlopig niet veranderen.

Maar goed, deze discussie hoort hier inderdaad niet thuis

[Zwerver]

offtopic:
Van mij mag deze discussie wel hier hoor Maak er alleen ff geen flamewar van Doe ik direct een titlechange

[Confusion]

RickN schreef op 25 augustus 2004 @ 11:49:
Een driver hóeft niet overal bij te kunnen en zou zelfs niet als root hoeven draaien.

Dat klopt, maar een driver moet theoretisch wel overal bij kunnen, omdat de kernel niet weet waar een willekeurige driver bij moet kunnen: een driver moet zelf eerst aangeven waar het toegang toe moet hebben en alle drivers tezamen moeten overal bij kunnen. Vervolgens kan twee dingen doen: de kernel laten controleren of de drivers zich aan de gevraagde rechten houden en de toegang ontzeggen wanneer een driver buiten zijn boekje wil gaan, of er gewoon vanuit gaan dat de drivers zich aan de gevraagde rechten houden. Aangezien drivers het laatste altijd zullen doen, omdat anders niemand, inclusief de schrijver, ze gebruikt, is het eerste toch overbodig? Als een driver de toegang zouden worden geweigerd, gebeurt precies hetzelfde: de driver gaat naar zijn exit-procedure wegens een failure en dat sloopt in veel gevallen ook je systeem. De drivers worden gedwongen te deugen, met of zonder de kernel die de rechten controleert.

[RickN]

Verwijderd schreef op 26 augustus 2004 @ 16:45:
[...]


Even buiten de algemene lompheid van deze opmerking wil ik nog even opmerken dat het zo ongelofelijk veel bloat zou toevoegen aan de kernel als er een aparte sandbox space voor drivers zou komen, dat niemand Linux meer zou willen gebruiken. Ken je feiten.

Een driver hoort nou eenmaal niet als doel te hebben de kernel te crashen. Als je computer al zo ver gekraakt was, dan ligt dat echt niet aan de kernel; je security lek ligt dan ergens anders.

Voor alle mensen die wél de hele draad hebben gelezen moet het inmiddels wel duidelijk zijn dan ik níet voorstel de linux kernel aan te passen, aangezien ik me heel goed realiseer dat het huidige design zich daar niet voor leent.

We hebben het helemaal niet over security, we hebben het over stabiliteit. Ik las laatst dat de linux kernel voor 50% uit driver code bestaat, en dat daar 85% van de bugs in wordt gevonden. Een driver heeft óók niet als doel bij alle kritieke resources van je systeem te kunnen. Een driver heeft tot doel een generieke interface naar een onderliggend stuk hardware aan te bieden. Aangezien daar slechts een beetje geheugen, wat processor tijd en een dunne interface naar wat kritieke system-resources en -calls voor nodig is zie ik het als een stabiliteits risico als een OS een hoop ongerelateerde processen bij elkaar in het priviliged geheugen flikkert en zegt: "doe maar wat je wilt.". En tenzij je nu beweert dat de linux aanpak zaligmakend is vind ik dat ik dat kan zeggen zonder daarmee blijk te geven van een gebrek aan respect voor de ontwerpers van linux.

Feit blijft gewoon dat veel drivers geschreven worden door b.v. hardware designers of de toch iets minder goden onder de kernel hackers. Ook nog steeds veel respect voor hoor, maar dat is toch geen code die ik graag naast een scheduler, virtual memory manager of filesystem zie staan in priveliged geheugen. Bovendien zijn drivers ook stukken code die je haast alleen door vallen en opstaan stabiel krijgt omdat er vaak vrijwel geen algoritmiek in zit, maar alleen het op de juiste momenten schrijven van de juiste magic numbers naar de juiste poorten; een verificatie nachtmerrie.

Een micro kernel lost in theorie dat soort problemen op door afgezien van een hele dunne abstractielaag alles in user space te doen. Natuurlijk krijg je daar een ander stel problemen voor terug en één ervan is een performance penalty. In research omgevingen wordt er nog steeds vrij veel aandacht aan microkernels gegeven en dat heeft erin geresulteerd dat er best heel wat vooruitgang is geboekt sinds de legendarische discussie tussen Torvalds en Tannenbaum. Er is nog steeds wel een een verschil in performance, maar als je b.v. naar L4 kijkt, dan is daar toch een knap staaltje werk geleverd.

Zo'n microkernel is eigenlijk puur overhead, omdat alle echte functionaliteit gestript en naar userspace verbannen is. Je moet dus zorgen dat die dunne abstractie laag erg efficient is, want daarnaast verlies je ook nog het één en ander op de interface tussen kernel en user space. Aan de ander kant, hoeveel tijd spendeert een gemiddeld systeem nou in systemcalls, een paar procent hooguit. Als een GUI ineens 5 keer zoveel resources vereist zonder significante functionaliteit toe te voegen zie je iedereen kwijlen over de eyecandy, maar een fundamenteel stabieler systeem dat niet een paar maar b.v 10% processor tijd gebruikt wordt als niet realistisch gezien. En dat terwijl die 10% over een paar jaar ook weer een paar procent is.

Helaas maakt zo'n inspanning in de huidige OS markt vrijwel geen kans omdat het al moeilijk genoeg is om één alternatief voor Windows een beetje aan de man te krijgen. Maar ik geloof persoonlijk niet dat over nog eens 10 - 15 jaar kernels nog steeds geschreven worden met dit soort, toch gehoorlijk grote, inherente stabiliteits risico's.

Anyway, deze monolitic vs micro discussie is al zó vaak gevoerd en wij gaan daar net als onze illustere voorgangers niet uitkomen. Maar dat geeft niks.

[RickN]

Confusion schreef op 26 augustus 2004 @ 22:27:
[...]

Dat klopt, maar een driver moet theoretisch wel overal bij kunnen, omdat de kernel niet weet waar een willekeurige driver bij moet kunnen: een driver moet zelf eerst aangeven waar het toegang toe moet hebben en alle drivers tezamen moeten overal bij kunnen. Vervolgens kan twee dingen doen: de kernel laten controleren of de drivers zich aan de gevraagde rechten houden en de toegang ontzeggen wanneer een driver buiten zijn boekje wil gaan, of er gewoon vanuit gaan dat de drivers zich aan de gevraagde rechten houden. Aangezien drivers het laatste altijd zullen doen, omdat anders niemand, inclusief de schrijver, ze gebruikt, is het eerste toch overbodig? Als een driver de toegang zouden worden geweigerd, gebeurt precies hetzelfde: de driver gaat naar zijn exit-procedure wegens een failure en dat sloopt in veel gevallen ook je systeem. De drivers worden gedwongen te deugen, met of zonder de kernel die de rechten controleert.

Ben ik het toch niet helemaal mee eens. Natuurlijk moet je driver tot op zekere hoogte vertrouwen, en je zult een soort van aanmeld procedure moet hebben waarin de driver aangeeft welke resources hij nodig heeft en de kernel die al dan niet toekent. Maar een driver hoeft m.i. nooit in het geheugen van b.v het init process te schrijven natuurlijk of in dat van een willekeurig ander ongerelateerd process. En als processen wel moeten communiceren kun je daar hele mooie communicatie primitieven voor aanbieden. De kernel exporteert nu al een hoop symbolen en calls die processen in userspace nodig zouden kunnen hebben. Voor drivers moet je daar natuurlijk het één en ander aan toevoegen maar ik denk dat je echt wel kunt afbakenen wat een driver redelijkerwijs aan resources zou kunnen gebruiken.

Waar het me om gaat is dat er geen reden is om drivers zo'n vrijheid te geven. Dat userspace processen niet in elkaars geheugen kunnen schrijven komt de stabiliteit van het systeem enorm ten goede, ondanks dat zo'n userspace process doorgaans toch ook het beste met het systeem voor heeft. Datzelfde zou dan toch ook gelden als drivers beperkt worden in hun rechten. Het is misschien een ongelukje als een driver per ongeluk zooi op adres 0 gaat schrijven, maar je systeem gaat wel onderuit, terwijl dat niet zou hoeven...

[Confusion]

RickN schreef op 26 augustus 2004 @ 23:13:
Het is misschien een ongelukje als een driver per ongeluk zooi op adres 0 gaat schrijven, maar je systeem gaat wel onderuit, terwijl dat niet zou hoeven...

De meeste drivers zijn zo kritisch dat ze zich toch geen fouten kunnen permitteren: als een actie door de kernel afgewezen wordt, dan houdt de driver ermee op en daarmee houdt je systeem ermee op. Of het nu een kernel panic of pakweg een IDE-driver panic is, het resultaat is gelijk: reboot.

De overhead die je introduceert weegt gewoon niet op tegen die ene crash van een niet-kritische driver per dag ergens ter wereld die je voorkomt. Zolang niemand dom genoeg is om een onvoldoende geteste en ge-auditte driver voor pakweg een chemische fabriek te gebruiken en bovendien erop te vertrouwen dat het systeem niet crashed, dan is er niets aan de hand en zijn zelfs de economische verliezen door de paar crashes te overzien.

De nette oplossing heeft geen praktische waarde.

[ Voor 7% gewijzigd door Confusion op 26-08-2004 23:55 ]

[RickN]

Dit is me allemaal véél te kort door de bocht, daar je er de waarde van alle stabiliteits verhogende features mee in twijfel trekt.
In software, anything that can't happen will happen. Dan kun je je code nog zo goed auditen en testen, als je er geen hard wiskundig bewijs bij levert heb je bugs. Als je er wel een bewijs bij levert, heb je misschien bugs. Was het niet zo'n Ariane 5 raket die enkele jaren geleden neerstorte door een software fout? Terwijl je niet wil wéten wat een QA de ESA er op na houdt... En alles is natuurlijk "niet kritisch" als je het gaat vergelijken met een chemische fabriek, maar ik als gebruiker vind het toch vrij kritisch dat mijn systeem niet crashed.
Een argument dat puur gebaseert is op performance kan onmogelijk stand houden gezien de vrijwel gegarandeerde performance increase die we jaarlijks aangereikt krijgen. Sterker nog, dat argument stamt uit begin jaren negentig toen de micro vs mono discussie op een hoogtepunt was. Aan het principe van micro is sinds toen weinig veranderd, terwijl de performance van moderene pc's misschien wel een honderdvoud is van wat het toen was.

[ Voor 10% gewijzigd door RickN op 27-08-2004 10:02 ]

[Squee]

Hmm ik wilde nog even een antwoord geven op de vraag van de topicstarter... (als dat nog mag tussen deze discussie door )

Het makkelijkste om je kernel te laten Panic'en is volgens mij door wat random data naar /dev/mem te sturen als root, dus pak een of andere random binary file en cat hem naar /dev/mem en je systeem ligt zo op zijn bek... (alhoewel je ook de kans hebt dat ie al meteen spontaan reboot en niet eerst nog panict viel me net op toen ik het ff probeerde op een testbak)

[Confusion]

RickN schreef op 27 augustus 2004 @ 10:00:
Dit is me allemaal véél te kort door de bocht, daar je er de waarde van alle stabiliteits verhogende features mee in twijfel trekt.

Nee, alleen de toegevoegde waarden van stabiliteitsverhogende features voor toch al kritische onderdelen van je systeemonderdelen. Die zijn namelijk niet stabiliteitsverhogend .

Was het niet zo'n Ariane 5 raket die enkele jaren geleden neerstorte door een software fout?

Dat was een fout in de afronding; een slordigheid van de ingenieurs. Daar hielp geen stabiliteitsverhogende feature tegen. Het ding wist gewoon niet meer waar het was, resetten of alleen een driver laten crashen heeft dan geen zin.

En alles is natuurlijk "niet kritisch" als je het gaat vergelijken met een chemische fabriek, maar ik als gebruiker vind het toch vrij kritisch dat mijn systeem niet crashed.

Maar mijn punt was nu juist dat je systeem toch al crashed.

Een argument dat puur gebaseert is op performance kan onmogelijk stand houden gezien de vrijwel gegarandeerde performance increase die we jaarlijks aangereikt krijgen.

Het wordt juist alleen maar beter. Jouw stabiliteitsverhogende maatregelen zorgen voor overhead over elke operatie van een driver: het schaalt vrijwel lineair mee met het aantal operaties. Computers doen tegenwoordig meer operaties, maar ze zouden allemaal gecontroleerd moeten worden. Juist voor een supercomputer zou een dergelijke maatregel desastreus zijn, als elke memory access gecontroleerd diende te worden met een extra check.

[Squee]

Ik heb nog even wat lopen proberen op een testbak van me, en volgens mij is dit nog wel de meest effectieve:

code:

# dd if=/dev/zero of=/dev/mem

[RickN]

Confusion schreef op 27 augustus 2004 @ 10:40:
Nee, alleen de toegevoegde waarden van stabiliteitsverhogende features voor toch al kritische onderdelen van je systeemonderdelen. Die zijn namelijk niet stabiliteitsverhogend .

Maar drivers zijn geen kritische onderdelen van je systeem. Als je netwerk driver crasht in userspace, blijft je systeem overeind, en heb je geen netwerk tot je de driver restart. Hetzelfde geldt ook voor andere drivers, en zelfs voor filesystem code, schedulers, memory managers e.d. zoals als verschillende microkernels al hebben aangetoond. Het enige wat kritisch is en wat altijd moet blijven draaien is de kernel zelf, dus die strip je dan van alle functionaliteit om em zo stabiel mogelijk te houden.

Dat was een fout in de afronding; een slordigheid van de ingenieurs. Daar hielp geen stabiliteitsverhogende feature tegen. Het ding wist gewoon niet meer waar het was, resetten of alleen een driver laten crashen heeft dan geen zin.

Het punt was dat zelfs met de meest extreme maatregelen bugs niet te voorkomen zijn, maar het aantal bugs dat het systeem laat crashen kun je ontzettend beperken door functionaliteit van je systeem in aparte processen te laten draaien.

Maar mijn punt was nu juist dat je systeem toch al crashed.

Alleen als je micro kernel crashed, anders raak je alleen bepaalde functionaliteit kwijt waar je in heel veel gevallen van kunt herstellen.

Het wordt juist alleen maar beter. Jouw stabiliteitsverhogende maatregelen zorgen voor overhead over elke operatie van een driver: het schaalt vrijwel lineair mee met het aantal operaties. Computers doen tegenwoordig meer operaties, maar ze zouden allemaal gecontroleerd moeten worden. Juist voor een supercomputer zou een dergelijke maatregel desastreus zijn, als elke memory access gecontroleerd diende te worden met een extra check.

Zelfs als alle processen op je systeem op een lineare manier meer operaties gaan gebruiken naarmate de performance van cpu's stijgt betekent dat dat absoluut gezien veruit de meeste extra operaties toch al in userspace worden gespendeert. Daarmee wordt de fractie van cpu tijd die in kernelspace wordt gespendeert al automatisch kleiner. Bovendien beweer ik dat er ook relatief meer van de extra performance richting userspace gaat, omdat de kernel veel minder gebloat wordt dan veel userspace processen waardoor de kernel frationeel alleen maar minder cpu tijd gaat gebruiken. Als je nu alle niet kritische functionaliteit uit de kernel naar userspace verhuist reduceer je (misschien best ingrijpend) de efficientie van een erg kleine fractie van de code die je systeem executeert, en dat lijkt me wel haalbaar.
Kortom, een increase in performance van cpu's reduceert dus zeker wél de overhead die een microkernel introduceert.

[ Voor 4% gewijzigd door RickN op 27-08-2004 11:29 ]

[Zwerver]

En omdat de discussie nu meer gaat over drivers in kernel danwel userspace nog ff een title change

De originele titel was:

Kernel panic veroorzaken

[Verwijderd]

RickN, als het je niet om de security maar om de stabiliteit te doen was, had je die kernel driver van mij eens moeten proberen. Je zou dan zien dat hij je systeem niet crasht. De kernel oopst alleen.

Waarom? Omdat de VM binnen de kernel zo werkt. Inderdaad, de gehele kernel zelf bevat ook een VM layer, omdat dat de enige manier is om in protected mode geheugen aan te spreken vanuit software. De hardware kan wel naar busmemory schrijven, maar software schrijft altijd naar virtual memory, en om virtual memory te accessen moet de pointer naar de page valide zijn. Anders kan jouw microprocessor dit niet omzetten in een busmemory adres en wordt er een foutcode naar het OS teruggestuurd. Zo werken alle 32-bit processoren, voor zover ik weet.

Wat dat betreft is de hardware dat gedeelte van de discussie al twee stappen vooruit. Niet dat het bijzonder moeilijk is om vanuit de kernel met opzet je systeem hard te hangen, maar de meeste toevalligheidsfoutjes worden tegenwoordig met een oops goed opgevangen. En ook al is een reboot na een oops over het algemeen een goede keuze (omdat - mogelijkerwijs - je systeem zich ongedefinieerd gaat gedragen met alle negatieve gevolgen en permanente systeemschade als gevolg), kun je na een standaard oops prima doorwerken met je huidige kernel. Ik heb dat al vaak genoeg gedaan als ik drivers aan het debuggen was. . Een oops is - vanuit user perspectief - een codefout. Vanuit kernelperspectief heeft de oops elke vorm van echte schade voorkomen. .

[RickN]

Verwijderd schreef op 27 augustus 2004 @ 15:22:
RickN, als het je niet om de security maar om de stabiliteit te doen was, had je die kernel driver van mij eens moeten proberen. Je zou dan zien dat hij je systeem niet crasht. De kernel oopst alleen.

Waarom? Omdat de VM binnen de kernel zo werkt. Inderdaad, de gehele kernel zelf bevat ook een VM layer, omdat dat de enige manier is om in protected mode geheugen aan te spreken vanuit software. De hardware kan wel naar busmemory schrijven, maar software schrijft altijd naar virtual memory, en om virtual memory te accessen moet de pointer naar de page valide zijn. Anders kan jouw microprocessor dit niet omzetten in een busmemory adres en wordt er een foutcode naar het OS teruggestuurd. Zo werken alle 32-bit processoren, voor zover ik weet.

Wat dat betreft is de hardware dat gedeelte van de discussie al twee stappen vooruit. Niet dat het bijzonder moeilijk is om vanuit de kernel met opzet je systeem hard te hangen, maar de meeste toevalligheidsfoutjes worden tegenwoordig met een oops goed opgevangen. En ook al is een reboot na een oops over het algemeen een goede keuze (omdat - mogelijkerwijs - je systeem zich ongedefinieerd gaat gedragen met alle negatieve gevolgen en permanente systeemschade als gevolg), kun je na een standaard oops prima doorwerken met je huidige kernel. Ik heb dat al vaak genoeg gedaan als ik drivers aan het debuggen was. . Een oops is - vanuit user perspectief - een codefout. Vanuit kernelperspectief heeft de oops elke vorm van echte schade voorkomen. .

Het doet me deugt dit te horen
Maar, ik blijft achter het microkernel en userspace driver concept staan

[Verwijderd]

RickN schreef op 27 augustus 2004 @ 15:55:
Maar, ik blijft achter het microkernel en userspace driver concept staan

Theoretisch gezien wel ja. Praktisch gezien heeft het nogal veel nadelen (performance, implementatietijd) dat het niet echt veel support zal krijgen. Alle grote OS'en (OS X, Linux, Win32) zijn dan ook geen microkernels...