Gutes Multitasking fähiges OS
-
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. ]
-
Ich weiß nicht ob das jemanden interessiert, aber werft doch mal einen Blick darauf: http://lusitanos.hybrid-2k.freeddns.com/
-
sorry, dass ich so lange nichts geschrieben hab. war ziemlich krank. bin es immer noch.
ich habe mir gedacht, dass vielleicht so ein phpbb board praktisch wäre. verschiedene foren zb über speicher/prozessmanagment, hardware treiber, netzwerke, dateisystem könnte man einrichten. wäre eine idee, nur ist die frage, ob das wirklich nötig ist und wer das macht. ich kann es nicht. kenn mich da nicht so gut aus. (dh ich müsste mir das genauer ansehen.)
der primäre sinn für mich persönlich ist es, über ideen zu diskutieren. leider gibt s ja nicht mehr all zu viele hier, die sich an der diskussion beteiligen. wenn sich doch wirklich jemand für so ein forum interessieren würde, sollte sich vielleicht hier mit einem kurzen posting melden. wenn das nur 2 oder 3 sind, dann is der aufwand für ein board wahrscheinlich zu groß.
björn
-
-
Ich denke es wären nicht so viele an einem Board interessiert..ich denk mal nicht viel mehr als so 5...es gibt leider viel zu viele Leute im Internet die nichts besseres zu tun haben als rumzustänkern
-
*unfreundlichbinweilgenervt*
Jammer hier doch nicht unnötig herum - schau ins Assembly-Forum und poste dort ein paar Details dann wirds vielleicht ja auch mit dem Surkevin-OS-Team was...
-
http://www.acm.uiuc.edu/sigops/roll_your_own/
http://www.mega-tokyo.com/os/os-faq.html
http://w3studi.informatik.uni-stuttgart.de/~staigesn/betriebssysteme.html
http://www.cs.utah.edu/flux/oskit/
http://www.cs.washington.edu/homes/tom/nachos/
-
http://linuxgazette.sourceforge.net/modules.php?op=modload&name=Sections&file=index&req=viewarticle&artid=111&page=1
http://linuxgazette.sourceforge.net/modules.php?op=modload&name=Sections&file=index&req=viewarticle&artid=112&page=1Gibt es hiervon eigentlich eine Fortsetzung?
[ Dieser Beitrag wurde am 02.05.2003 um 17:05 Uhr von Erhard Henkes editiert. ]
-
Die englischen Originalseiten sind übrigens hier:
http://www.linuxgazette.com/issue77/krishnakumar.html
http://www.linuxgazette.com/issue79/krishnakumar.htmlandere Seiten:
http://www.themoebius.org.uk/tutes/ http://www.themoebius.org.uk/tutes/ckernel.html