Gutes Multitasking fähiges OS
-
genauso wie es dumme leute in real gibt, gibt es flamor im forum, manchmal macht auch jemand nen joke und der andere reagiert total ernst drauf und fühlt sich beleidigt, zu sowas gehören ja beide seiten und wie will man entscheiden ob das bössartig ist oder nicht? wenn ich irgend ein argument lese, was eigentlich keine argument für mich ist schreib ich auch dinge wie "muss mich das jucken" und könnte "wieso sollte mir das wichtig sein" oder "was an der artikulation invalidiert die entscheidung die bisher von meiner position aus vertretten wurde" und sonst was, bloss dann wird man mehr regeln zum kommunizieren haben als gedanken zum mitteilen.
wenn es jemanden stört, dann sollte man einfach ignorieren wenn ein anderer einem zu dumm kommt, immerhin ist es auch niveaulos leuten die "gib mir alles fertig zum compilen" schreiben noch 'ne antwort zu geben.
um beim thema noch weiter zu labern.
soweit ich weiß hatte BeOS eine datenbank als dateisystem... sowas fände ich ziemlich cool für ein OS, datenbanken sind ziemlich fix und durch join kann man doch ne art chierarchy aufbauen... oder?wenn ich ein OS coden würde, dann könnte ich mir vorstellen dass man da erstmal extrem lange daran konzeptionieren würde
und wenn man ein OS codet, dann wäre es doch ziemlich gut, wenn man sich auf etwas spezialisieren würde, weil an sonsten könnte man auch linux nehmen dass man für alles mögliche konfigurieren kann, aber wenn man ein OS machen würde, was etwas speziell kann, wäre man anderen wohl überlegen.
was ich mir gut vorstellen könnte wäre ein OS dass mehrere systeme absolut getrennt voneinander simuliert, also so als hätte man, um einen neuen prozess zu starten, einen bootvorgang ausgelöst, darin läuft dann ein programm ohne zu wissen dass auf dem selben system 100 andere getrennte system existieren. damit könnte man z.B. mehrere server umgebungen haben und wenn mal ein subsystem abkackt, dann würde alles andere noch laufen ohne auch nur einen kratzer, man könnte sogar mit heftigen fehlern im code die normalerweise sogar ne linuxconsole blockieren dann weiter arbeiten... oder denkt ihr sowat ist unnütz oder gibt es schon?
rapso->greets();
-
Billyboy Gates - der alte Pariser hat den DOS Code gekauft, und erweitert! Er hat ihn nicht komplett selbst geschrieben.
Zum Thema - konzipieren ja - allerdings würde ich erstmal den Grundlegenden Stuff schreiben - also Bootloader, und dann Protected Mode, und dann ne kleine Nachricht - "Hi - I´m your system... - Press the >Anykey< Key to reboot..."
Wenn das Funktioniert würde ich mit dem richtigen Konzept anfangen. Gut - vorher sollte man schon wissen, was man machen will. Nur, wenn man bei dem Loader usw. schon versagt, hat man sich die Tagelange Konzeptionierung gespart
So long... Snorre
-
ein datei system in einer datenbank? muss ich dann sql verwenden um eine datei zu finden? *gg* es gibt schon viele coole dateisysteme zb xfs. bin sehr zufrieden damit beim linux. so was ist aber total komplex zb. xfs verwendet btrees so weit ich weiss (sorry, kein scharfes s auf der tastatur).
surkevin hat einen bootenden kernel. noch sehr klein, aber immerhin. eine wichtig frage ist jetz, wie man das speichermanagment machen sollte. der vorschlag ist, segmentierung mit paging zu kombinieren. was meinst ihr?
linux verwendet für alles einen selector, deshalb hat der stack auch ausführrechte. wenn man nun den durch paging erzeugten virtuellen adressraum genau in cs und ss einteilt, könnte man doch bufferoverflows, durch die eingespeisster programmcode ausgeführt werden kann, komplett verhindern indem man dem ss einfach keine ausführrechte und dem cs keine schreibrechte gibt. oder nicht?
björn
-
irgendwie findet man immer einen weg für nen bufferoverflow, da war doch letztens einer im linuxkernel und auf ring 0 hat man doch alle rechte oder kann man da auch bereiche sperren?
ja das dinge hatte ne SQL database, das war mit einer der gründe weshalb das ding so fix war. (das ganze os meine ich)
ich würde das paging mit der aufteilung der platte zusammenlegen. es ist ja gewissermassen bewiesen dass 4KB blöcke für pages das optimale sind, genauso gross dann die segmentierung auf der platte. sowas fände ich cool... und es wäre optimal, denk ich mir, fürs paging weil das einlesen von pages immer ein read auf der platte wäre von hintereinadner liegenden segmenten.
das mit dem stack wie du es vorschlägst würde ich auch machen, code sollte meiner meinung nach bei einem OS das auf sicherheit aus ist immer von daten getrennt sein, nie modifiziert werden können (im ram) und daten dürfte man nicht als code ausführen.
vielleicht müßte man dann auf OS ebene irgendwas mit Stringverwaltung machen, sodass es schon vom OS heraus nicht möglich sein sollte drüberzubügeln... aber ich wüste nicht wie man das realisieren könnte.
ach ja, ein bootloader wäre sicher ok, aber alles was danach kommt muss supergut durchplannt sein denk ich mir, sonst kommt man nicht weit. alleine schon die aufteilung in welcher ebene was läuft (z.B. ob dateisystem mit memorymanagment auf selber ebene oder was höcher liegt) kann ein OS zu dreck werden lassen.
rapso->greets();
-
mastamind: Theoretisch kein Problem, es gibt aber leider Programme, die sog. Trampoline benutzen. Füttere mal Google-Groups mit Message-ID: W5Scnc1GdODTUOajXTWcoA@dls.net
-
Original erstellt von rapso:
das mit dem stack wie du es vorschlägst würde ich auch machen, code sollte meiner meinung nach bei einem OS das auf sicherheit aus ist immer von daten getrennt sein, nie modifiziert werden können (im ram) und daten dürfte man nicht als code ausführen.Währe ich dagegen, weil sonst mein Scriptcompiler nicht mehr funktioniert
Der legt das compilierte Programm im einem Array ab, und springt per__asm call _compiledProgramrein, und beendet wird durch ein ret
-
Nur wie sollte die Speicherverwaltung gesamt aussehen? Es sollen ja auch eigen gecodete ASM Prozesse laufen und nicht nur mit unserem eigenen Compiler erstellte Programme...das OS braucht ja zur Verwaltung Daten des Prozesses damit es das Multitasking umsetzen kann..jedes Programm denkt dann es wäre direkt an 0x00000000 und durch das Paging wird das dann umgesetzt, ich denke das wäre gut! Jedoch muss bei Seitenfehlern das OS wissen welcher Prozess ihn ausgelöst hat um es dann richtig zu verwalten...um die Prozesse in eine Prozessliste einzusetzen bräuchte man dann am besten die Adresse der LDT die man eigens für den Prozess erstellt und schreibt diese dann mit Infos in die Liste oder was meint ihr? Aber wie ist es machbar dass der Prozess beim OS ansagt dass er da ist auch bei ganz fremden ASM Anwendungen die nicht mit dem eigenen Compiler gemacht wurden damit dieser dann eien LDT anlegen kann und ihn einreihen kann?
Kevin
-
@rapso
ich versteh nicht ganz, woher das db-fs dann die daten bekommt. die müssen ja auch auf der hd stehen; oder halt auf einem geeigneten medium. wahrscheinlich wird einfach die hd als große datei angesehen und die dateien, ordner und deren attribute dann als datensätze...interessant wäre eine swap partition, wie bei linux und co. dort könnte man einfach dann die partition in 4 kb teile aufteilen. das hat den vorteil, dass man nicht über das dateisystem gehen muss. wenn auch noch so schnell es ist.
ich denk, dass die string-verwaltung nicht unbedingt teil des os sein muss. eigentlich gar nicht. das os ist im prinzip nur für die teilung der prozesse voneinander und der teilung von code und daten innerhalb der prozesse wichtig. was dann die programme mit ihren strings im speicher anfangen ist schon einmal weniger gefährlich, als wenn sie code von sich oder anderen prozessen überschreiben.
speicher sollte wie folgend aufgeteilt sein:
jedes programm bekommt eine bestimmte anzahl an segmenten. mindestens 3: ldt, cs, ss. ss ist read/write, cs execute only. ldt read-only.
im gdt sitzt der deskriptor für das ldt segment. im ldt register wird ja nur ein selector auf das gdt gespeichert. in der ldt sind dann die deskriptoren für cs und ss und weiter lokale segmente. dynamischer speicher wird im ds verwaltet. auch read/write.
man könnte dann die restlichen segmente zb für shared memory verwenden. ich möchte verhindern, dass die segmente oft während dem ausführen des programm verändert werden, da man dadurch immer den descriptor cache im segmentregister verliert.die idee zum allgemeinen aufbau ist: mircrokernel in ring 0, dateisystem in ring 1, netzwerk, console,... in ring 2. und user space is nur ring 3. was denkt ihr? so können zb fehler im netzwerk-stack des os keine katastrophen im prozess- und speichermanagment oder im dateisystem anstellen.
@bashar
hab leider bei google nichts gefunden zu dieser message id. würd mich aber dafür interessieren.[ Dieser Beitrag wurde am 03.04.2003 um 19:23 Uhr von mastamind editiert. ]
-
Original erstellt von Surkevin:
Nur wie sollte die Speicherverwaltung gesamt aussehen? Es sollen ja auch eigen gecodete ASM Prozesse laufen und nicht nur mit unserem eigenen Compiler erstellte Programme...das OS braucht ja zur Verwaltung Daten des Prozesses damit es das Multitasking umsetzen kann..jedes Programm denkt dann es wäre direkt an 0x00000000 und durch das Paging wird das dann umgesetzt, ich denke das wäre gut! Jedoch muss bei Seitenfehlern das OS wissen welcher Prozess ihn ausgelöst hat um es dann richtig zu verwalten...um die Prozesse in eine Prozessliste einzusetzen bräuchte man dann am besten die Adresse der LDT die man eigens für den Prozess erstellt und schreibt diese dann mit Infos in die Liste oder was meint ihr? Aber wie ist es machbar dass der Prozess beim OS ansagt dass er da ist auch bei ganz fremden ASM Anwendungen die nicht mit dem eigenen Compiler gemacht wurden damit dieser dann eien LDT anlegen kann und ihn einreihen kann?Das LDT-anlegen etc. muss über einen System-Call geregelt werden, in der Art wie fork() bei Unix und createProcess bei Windows. Die Aufrufe dazu kann man ja in einer Library legen, die jeder Compiler fressen kann.
Ich persönlich bin bim Speichermanagement ja Feind von Segmenten, die Dinger verwursten alles nur. Ich denke selbst mit Segmenten kriegt man Exploits auf dem Stack etc. noch irgendwie hin, Sicherheitslücken gibst immer, sie sehen nur immer anders aus. Ein Problem wa sihc mit Segmente sehe ist das Kompilieren von Anwendungsprogrammen. Ich weiß nicht, was für Erfahrungen andere gemacht haben, aber ich habe extreme Probleme damit gehabt, dem GCC z.B. auch nur meine Speicherverwaltung vernünftig aufzuwzwängen (ich benutze Paging, Flat-Mode, Kernel ab 0x80000000), ich weiß nicht welcher Compiler so mit Segmenten jonglieren kann, vielelicht schaffts ja wer den DJGPP zu dressieren, da man für so ein Segmentmodell ja evtl. mit FAR Pointern standardmäßig arbeiten müsste. Aber das ist sicherlich irgendwo Geschmackssache
Die Idee mit den verschiedenen Ringen und verschiedneen Stacks klignt allerdings Interessant. Kann man ja genauso problemlos im Flat-Mode realisieren Die Frage ist nur, wie das OS darauf reagieren soll, wenn sagen wir mal der Dateisystemtreiber wegbrezelt @mastamind: http://www.google.de/groups?ie=UTF-8&oe=UTF-8&as_umsgid=W5Scnc1GdODTUOajXTWcoA@dls.net&lr=&hl=de (Google Groups-->Erweiterte Suche ;))
[ Dieser Beitrag wurde am 04.04.2003 um 00:14 Uhr von TriPhoenix editiert. ]
-
ich denk, dass man dann einfach den treiber neu läd. dadurch, dass ich auch kernelthreads verwenden würd, brezelt im prinzip ja nur ein thread weg. vielleicht schafft man es, dass die behandlungsroutine des os für eine segfault einfach nur den thread beendet und mit einem anderen fortfährt, ohne, dass gleich der ganze prozess abstürzt. jeder thread hat ja einen eigenen stack, auf dem erfehler produzieren kann.
zum compiler: das wird allgemein ein großes problem, da ich kein posix einbauen will. das ist, denk ich, komplizierter als sich für die einfachen dinge selbst etwas einfallne zulassen. ich würd lieber eine vollständig objektorientierte api verwenden. das wäre wirklich etwas neues. hat aber auch nachteile.
björn
-
noch was:
man könnte sich mit der segmentierung eine art working-set algorithmus überlegen, der zb den code nicht auf pageebene einlagert, sondern auf segmenteben. wäre eine idee.zum compiler: ich trau es mich gar nicht zu sagen, aber ich denke, ein eigener compiler wird die einzige option sein. das würde vielleicht auch die möglichkeit geben eine stringverwaltung direkt in die sprache zu integrieren. so ist diese dann zwar relativ sicher, aber doch nicht teil des os.
somit wäre eine gute sicherheit durch os, compiler und sprache gegeben. sowas ist natürlich das schwerste, was man sich vorstellen kann. ohne diese 3er-kombination, würden, denk ich, mehr sicherheitslücken offen blleiben.björn
-
ich hab ja auch von einem sicherem OS gesprochen, sobald man irgendwo ne ausnahme macht, dann wird es nicht möglich sein die bufferoverflows 100%ig zu stoppen.
wenn man code und daten immer trennen würde, dann könnte nur ein hardware bug die sicherheit behindern.und mit der datenbank meinte ich das schon so dass die ganze HD wie eine einzige datei gehändelt wird. die HD würde dann mit memorymapping aufs ram gelegt (ja dann bräuchte man heutzutage eventuell 64BIT als OS basis.
aber eigentlich muss man am anfang das einsatzgebiet für ein OS wissen, damit man weiß worauf man achten muss, weil wenn sicherheit egal ist und nur performance wichtig ist, dann kann man so ziemlich alles anders machen.
rapso->greets();
-
ich denk auch, dass durch das verwenden von verschiedenen segmenten mit angepassten rechten nur ein hardware bug solche fehler produzieren kann. vielleicht sieht aber jemand einen anderen grund.
den artikel bei google hab ich gefunden. mir kommt vor, dass das beschriebene dort nicht als möglichkeit zum aushebeln der sicherheit ist, sondern einfach ein feature, das der gcc hat. mit der segmentierung wird er allerdings das feature verlieren.
das dateisystem von beos ist ein 64 bit system. hab ich irgendwo einmal gelesen. mir kommt vor, dass hier viele paralellen zu xfs existieren zb.
zum einsatzgebiet:
zuerst nur einfach vieles auszuprobieren, was der pentium und seine kinder und enkelkinder so zu bieten haben. genau die kombination von segmentierung und paging zusammen find ich sehr interessant.
um das os dann wirklich einsetzen zu können, könnte man sich auf netzwerktechniken konzentrieren. ip, tcp, udp, routing, paketfilter. so dinge.björn
-
Original erstellt von mastamind:
ich denk, dass man dann einfach den treiber neu läd. dadurch, dass ich auch kernelthreads verwenden würd, brezelt im prinzip ja nur ein thread weg. vielleicht schafft man es, dass die behandlungsroutine des os für eine segfault einfach nur den thread beendet und mit einem anderen fortfährt, ohne, dass gleich der ganze prozess abstürzt. jeder thread hat ja einen eigenen stack, auf dem erfehler produzieren kann.Hmm....wenn mir der Dateisystemtreiber wegbrezelt, dann stimmt denke ich soviel schon nicht, dass das System durchaus ein Argument hat, zu verrecken. Und ob da einfach Neustarten die Idee ist, ich meine da stimmt doch was gewaltig nicht.
Zumindest soltle der Admin eine Riesenbox in rot aufn Screen bekommen oder so [ Dieser Beitrag wurde am 05.04.2003 um 12:52 Uhr von TriPhoenix editiert. ]
-
wenn man für den code schreibgeschützte segmente verwendet, kann im prinzip der code nicht wegbrezeln. der bleibt sicher da. dadurch muss man ihn nicht neu laden. nur der thread oder im schlimmsten fall der process stürzt ab.
wie kann man nun am besten verhindern, dass solche fehler schlimme auswirkungen haben?als beispiel, dass einer allein viel erreichen kann, kann man sich zb http://www.atheos.cx/ ansehen. das os kann sehr viel. eine solche gui will ich gar nicht anstreben. das erste wäre eben ein gutes speicher- und prozessmanagment. das find ich wichtiger.
wir haben bis jetzt einen bootsector, der 3 sectoren von der bootdiskette ladet und direkt in den ram nach den bootsector ins segment an 0x07C0 schreibt und doret hin springt. soll ich den vielleicht einmal posten? würde das jemanden interessieren?
hat überhaupt noch wer interesse an dieser diskussion hier?björn
-
Intresse immer.
Mein momentanes "Problem" ist, das ich mir noch kein gutes System überlegt habe, wie die einzelnen Treiber zusammen arbeiten sollen, also wie erfährt die Konsole das ein Keyboard Interrupt ausgelöst wurde und ein neues Zeichen da ist.Falls wer Interresse hat kann ich auch mal meinen aktuellen Code rummailen oder ins netz stellen. Bis jetzt wird in Protect Mode gesprungen, eine Interrupt Vector Table angelegt und der APIC so programmiert, das der Timer und Keyboard Int angeschaltet werden
-
Interessant, währe vielleicht wenn ihr, egal ob ihr zusammenarbeitet eine Page ins Netz stellt, wo man den Code einsehen kann, und ihr vielleicht eine Faq oder ähliches zusammenstellt, wo ihr Probleme hattet.
Noch dazu ein WiKi.
Interessant währe es auf jeden Fall.
-
@geyken
ich denk, die methode, dass man alle privilegienringe des protected mode ausnützt, ist sinnvoll. dadurch bekommt man straff abgegrenzte bereiche. der kernel macht eben das prozess- und speichermanagment. das ist alles. man könnte überlegen, ob er auch das dynamic linking miteinbezieht. zb als teil des prozessmanagments.
alle anderen dinge werden von system diensten, die einfach prozesse mit höherer priorität sind bzw in höheren ringen laufen als normale user space programme, erledigt. man könnte einfach auch nur shared libs in höhere ringe laden, die der dynamic linker dann über call gates zu den programmen verlinkt...
das is meine idee. was denkt ihr darüber?die treiber würd ich objektorientiert aufbauen:
dei basisklasse aller treiber ist zb die klasse generic_driver oder so. als erste ableitungen gibts network_driver, console_driver usw. wäre eine möglichkeit.
der spezielle treiber für ein bestimmtes stück hardware zb für den vga modus wäre dann eben der vga_driver mit der basisklasse console_driver. console_driver hat virtuelle methoden um zb ein zeichen am bildschirm anzuzeigen und von der vga_driver klasse wird die methode eben implementiert... jeder treiber ist in einer art plugin enthalten, oder kann direkt eincompiliert werden.
die frage ist nun, wie so ein plugin aufgebaut werden muss bzw wie das module geladen werden soll.
linux verwendet ein ähnliches system. statt den virtuellen methoden sind es function pointer. zb bei den netzwerk treibern.das io system sollte auch modular sein, bis auf das lokale dateisystem. nachdem die module geladen werden müssen, müssen sie ja auch irgendwo existieren. eine uri könnte zb eine http-url sein, eine lokale datei, eine datei weiß gott wo. zu jeder "source" gibt s dann attribute und rechte. diese beiden können auch teileiweise modular sein.
ein weiteres module ist das "raw" module mit dem man auf die hardware zugreifen sollte. zb "raw://ide[0]/disk[0]/partition[0]" ist die erste partition der ersten platte des ersten ide controllers. "raw://smartcard[0]" ist die erste smartcard zb. dadurch hat man eine einheitliche schnittstelle. programm merken gar nicht, ob sie über webdav eine datei schreiben, oder ob die von einer smartcard kommt.
eine api könnte so aussehen, dass im namespace "io" die klasse source existiert.
mit io::source laufwerka("raw://floppy[a]"); könnte man die das erste floppy laufwerk öffnen.
mit io::source memory("shm://server-verbindung"); könnte man das shared memory mit der bezeichnung server-verbindung öffnen.
ich weiß, das sieht sehr nach den io slaves unter kde aus. is es auch die idee ist nämlich nicht schlecht.@snorredev
die frage is, wer so eine site macht. und wer den server dafür hat.björn
-
Wenn ihr wollt, stell ich etwas von meinem Space bereit - soviel Daten werden es wohl nicht werden. Allerdings müßt ihr euch um die Website selbst kümmern. Dafür fehlt mir die Zeit. Ich könnte euch einen Webscript zum Hochladen der Dateien bzw. zum administrieren bereitstellen. Das FTP Password geb ich nicht raus, was ja verständlich ist
-
Platz hätte ich auch noch. Ich weiß nur nicht, wie viel Zeit ich ihm nächsten Semester habe aber ansonsten ist es kein Problem
Meine aktuellen Sourcen stehen jetzt unter http://www.informatik.uni-oldenburg.de/~geyken/os-0.00.01.tar.gz
einfach die disk.bin mit dd eine Diskette schreiben[ Dieser Beitrag wurde am 07.04.2003 um 21:13 Uhr von geyken editiert. ]