segmentaion fault

[nwp2]

Ich weiß nicht genau was du meinst, aber ich rate einfach mal.
Wir gehen mal davon aus wir haben die Standardbibliotheken, strcpy zum Beispiel. Alle möglichen Programme benutzen strcpy, also wird die Standardbibliothek inklusive strcpy einmal in den RAM kopiert und alle Prozesse erhalten einen entsprechenden Eintrage der es erlaubt diesen Speicherteil auszuführen.
Wenn Programm A ausgeführt wird, dann sind die Tabellen für Programm A geladen, also darf strcpy nur dort lesen und schreiben wo Programm A lesen und schreiben darf. Der Kernel benutzt auch strcpy und hat die entsprechenden Tabelleneinträge dass in den Kernelspeicher geschrieben werden kann, was Programm A nicht konnte.

Übrigens hat natürlich nur der Kernel die entsprechenden Lese/Schreibrechte um die Tabelle zu bearbeiten, sonst wäre es ja sinnlos.

Ich glaube ich weiß jetzt was du meinst. Der Speicher den du nicht reserviert hast, existiert nicht. Es existiert nur die Adresse. Sobald du darauf zugreifen willst wird die virtuelle Adresse in eine physische Adresse umgerechnet, und genau da passiert der Fehler, diese virtuelle Adresse ist garnicht definiert und es gibt einen Segmentation Fault.
Es gibt also keinen Code für Speicher den du nicht reserviert hast, du kannst also auch nicht drauf zugreifen.

[noobLolo]

Woher/Wie kommt Code in den Adressraum eines Prozesses, der eigentlich gar nicht von diesem Prozess verwendet werden darf?

ich dachte spontan an sowas wie Pufferüberläufe alternativ einen Heap-Überlauf um nicht zu viel zu schreiben kopier ich ein bischen aus wiki..."Im Wesentlichen werden bei einem Pufferüberlauf durch Fehler im Programm zu große Datenmengen in einen dafür zu kleinen reservierten Speicherbereich, den Puffer, geschrieben, wodurch dem Ziel-Speicherbereich nachfolgende Informationen im Speicher überschrieben werden."

so hatte ich mir das vorgestellt

[MatheStein]

ich glaube so langsam komme ich dahinter

Was genau passiert denn im dem kernel-space des Prozess-Adressraums?
Liegen dort nur dynmaische bibs rum?

gruß

[noobLolo]

sind die libs überhaupt im kernel space? könnten doch auch im user space liegen, das wär doch nur eine unnötige sicherheits lücke oder brauchen die unbedingt den kernel space? der kernel hat doch seinen eigenen adress raum und hat mit dem prozess raum nichts am hut außer das er ihn zuweist? find das thema auch spannend deswegen *bump*

[MatheStein]

hey

Dynamische bibs müssen ja irgendwo für jeden Prozess frei zugänglich sein. Würde jeder Prozess seine eigene bib bekommen, wären das ja statische bibs, wenn ich mich jetzt nicht irre

gruß

[noobLolo]

MatheStein schrieb:

Dynamische bibs müssen ja irgendwo für jeden Prozess frei zugänglich sein

das wären sie doch auch wenn sie im user-space sind? der user-space kann doch nicht auf der kernel-space zugreifen? sonst müßt ich doch nen kernel treiber coden hatt ich ja schon immer mal vor;)

[nwp2]

Was ist denn der kernel-space des Prozess-Adressraums?

Die libs haben die Rechte des ausführenden Programms. Wenn ein Programm die Standardlibs benutzt haben die Standardlibs die Rechte dieses Programms, wenn der Kernel sie benutzt haben sie die Rechte des Kernels. Das hat mit Userspace und Kernelspace nichts zu tun, Standardlibs tun nur Dinge die im Userspace erlaubt sind. strcpy funktioniert für jedes Programm wie Kernel gleich, jeweils mit dem Unterschied dass entsprechend verschiedener Speicher ansprechbar ist.

Kernelspace und Userspace wird erst dann interessant wenn ein Programm etwas tun will was man ohne Kernelrechte nicht machen kann, hauptsächlich auf die Hardware zugreifen.

malloc ist ein gutes Beispiel, man sagt malloc(irgendwas), malloc kuckt ob noch Platz auf der aktuellen Seite ist, wenn ja wird der Platz als belegt markiert und ein Pointer darauf zurückgegeben, alles komplett ohne Kernel.
Aber wenn die Seite nicht mehr reicht muss malloc eine neue anfordern und dann muss im Descriptor Table ein Eintrag hinzugefügt werden, dass das Programm auf die neue Seite auch zugreifen darf. Dazu braucht man den Kernel. Man legt auf den Stack oder in Register einen Code für "Gib mir eine Seite" und erzeugt einen Interrupt. Der Interrupt setzt die Rechte auf Kernelrechte und springt in den Interrupthandler. Der kuckt dann in Register oder den Stack was das Programm will, handelt entsprechend und springt zurück ins Programm. (naja, meistens schlägt der Scheduler zu und springt in ein anderes Programm weil die Kosten gering sind weil das Programm eh schon unterbrochen ist.)

Edit:

noobLolo schrieb:

der user-space kann doch nicht auf der kernel-space zugreifen? sonst müßt ich doch nen kernel treiber coden hatt ich ja schon immer mal vor;)

Klar kann ein normales Programm auf "Kernelspace" zugreifen, vorausgesetzt der entsprechende Tabelleneintrag ist gesetzt. Das ist sogar sinnvoll, man denke da an eine Funktion "GetFreeDiskSpace". Diese Funktion liegt in einer allgemein Zugänglichen Bibliothek und gibt einfach eine lokale statische Variable zurück. Jedes mal wenn sich der Speicherplatz ändert passt der Kernel die Variable entsprechend an. Damit liegt die Funktion und die Variable sowohl im Userspace als auch im Kernelspace, obwohl das eigentlich die falschen Begriffe dafür sind.

[noobLolo]

nwp2 schrieb:

malloc ist ein gutes Beispiel, man sagt malloc(irgendwas), malloc kuckt ob noch Platz auf der aktuellen Seite ist, wenn ja wird der Platz als belegt markiert und ein Pointer darauf zurückgegeben, alles komplett ohne Kernel.

ruft malloc nicht den kernel auf und sagt hey hier porcess xy gib mal speicher?

bzw. natürlich müssen user-space programme mit dem kernel interagieren also hat der kernel eine schnittstelle über die der user mit dem kernel interagieren kann denke das sind die syscalls?

GetFreeDiskSpace wird doch sicher auch nur einen syscall aufrufen und nicht irgendwo im kernel space rum pfuschen?

[noobLolo]

nwp2 schrieb:

strcpy funktioniert für jedes Programm wie Kernel gleich,

kann sein, aber nehmen wir mal als beispiel malloc, da nimmt der kernel nicht malloc sonder kmalloc() oder so also sind die libs nicht zwingend identisch...

ich denke eher die libs die wir in unsere programme einbinden wurden speziell für uns erstellt und haben mit den libs die der kernel verwendet nicht all zu viel zu tun

aber das ist alles halb wissen wär schön wenn uns da jemand aufklärt:)

[supertux]

noobLolo schrieb:

nwp2 schrieb:

malloc ist ein gutes Beispiel, man sagt malloc(irgendwas), malloc kuckt ob noch Platz auf der aktuellen Seite ist, wenn ja wird der Platz als belegt markiert und ein Pointer darauf zurückgegeben, alles komplett ohne Kernel.

ruft malloc nicht den kernel auf und sagt hey hier porcess xy gib mal speicher?

ja, das tut er, aber nur wenn der Speicher knapp ist. Wenn du malloc(100) machst, werden nicht 100 bytes reserviert sondern ein Block, indem die 100 Bytes sich befinden. Dieser Block (oder Seite/Page) kann eine feste größe haben, z.b. 4Kb. Ein erneuter malloc(100); müsste nicht nochmal nach eine Seite auffordern, da auf der letzten Seite noch genug Platz für weiter 100 Bytes gibt. Mache ich aber malloc(1024 * 5), dann muss malloc wieder dem kernel mitteilen, dass er einer weitere Seite braucht.

noobLolo schrieb:

bzw. natürlich müssen user-space programme mit dem kernel interagieren also hat der kernel eine schnittstelle über die der user mit dem kernel interagieren kann denke das sind die syscalls?

richtig, das sind die syscalls.

Ich kann nur dieses Buch http://books.google.de/books?id=vdk4ZGRqMskC&pg=PA383&lpg=PA383&dq=Andrew+SLOS+ARM&source=bl&ots=UJGhxRoQdH&sig=nrycPbArXBrS6QXauNLFtsDVmtY&hl=de&ei=lSRGS92MEpiwnQOtqdT1Ag&sa=X&oi=book_result&ct=result&resnum=5&ved=0CBgQ6AEwBA#v=onepage&q=&f=false
empfehlen: ARM system developer's guide: designing and optimizing system software Von Andrew N. Sloss,Dominic Symes,Chris Wright.

ARM System Developer's Guide | ISBN: 1558608745

Die Bibel für ARM Programmier, ein wunderschönes Buch, welches viele Einblicke in genau diese Sachen gibt. Da die ARM Architektur einfach ist (im Vergleich zu x86), kann man schnell die Ideen lernen und auf andere Architekturen übertragen. Selbst wenn man keine ARM hardware hat, ist das Buch empfehlenswert. Aber die hardware ist nicht teuer, ein gumstix kostet keine 200 Dollar, zum Spielen & Lernen ist das sicher eine gute Investition.

[nwp2]

Wie gesagt, manchmal braucht malloc den Kernel, manchmal auch nicht, je nachdem ob eine neue Seite benötigt wird oder nicht. So ein Kontextswitch (Sprung von Programm in Kernel und zurück) ist ziemlich langsam, das versucht man so weit es geht zu vermeiden.
Die Libs sind in sofern für den Kernel verschieden, dass er direkt machen kann was er will. malloc würde per Interrupt eine Seite anfordern während die Kernelversion einfach direkt eine Seite holt und für sich einen Tabelleneintrag einsetzt, ansonsten ist das gleich.
Syscalls sind auch nur Interrupts, mehr ist da nicht dahinter. Als Kernel braucht man keine Interrupts/Syscalls, alles was die tun ist in den Kernelmode springen, aber da ist der Kernel eh schon. Der ruft einfach die Funktion direkt auf die eigentlich der Interrupthandler aufrufen würde. string.h ist zum Beispiel komplett identisch für Programme und Kernel weil dort keine Syscalls vorkommen. Wenn man sich die stdlib.h mal hier ankuckt: http://www.cplusplus.com/reference/clibrary/cstdlib/ stellt man fest, dass nur Funktionen unter Dynamic memory management und Environment was mit Syscalls zu tun haben, der Rest ist gleich.

GetFreeDiskSpace pfuscht nicht rum sondern könnte ganz einfach so implementiert sein:

int GetFreeDiskSpace(){
    volatile static int discspace;
    return discspace;
}

discspace ist in einer Seite wo shared Variablen rumliegen wo jeder lesen darf. Schreiben darf nur der Kernel. Als Programm kann man da nichts manipulieren weil alles mit Programmrechten läuft. Wenn man die Adresse von discspace errät kann man sie direkt lesen, das kann niemand verhindern. Schreiben allerdings geht nicht, da gibt es einen Segmentation Fault.