Nachrichten

1

tyndur / Re: Der große tyndur-Blog-und-Twitter-Ersatzthread

« am: 13. April 2015, 00:49 »

Mit Erfolg, das hat nämlich erstmal ein paar Bugs aufgedeckt, aber nach ein, zwei Tagen hat alles soweit funktioniert und ich kann jetzt tyndur vom USB-Stick booten. Ziemlich coole Sache.
[...]
Aber selbst einen USB-Stick ständig umzustecken und nach jeder Debugging-Änderung ein neues Image draufzuspielen war mir mit der Zeit dann doch noch zu umständlich.

Da hätte ich doch glatt den nächsten Vorschlag in Sachen Bootvorgang: Mit iPXE+NFS übers Netzwerk booten

2

Lowlevel-Coding / Re: Segmentierung im Long Mode

« am: 19. October 2013, 17:45 »

In compatibility mode, the code-segment descriptor is interpreted and behaves just as it does in legacy mode as described in “Code-Segment Descriptors” on page 82.

Scheint so

3

Softwareentwicklung / Re: [All In One]-Question lolxdfly

« am: 16. September 2013, 20:47 »

Wäre auch zu schön gewesen hätte es funktioniert 
Liegt es daran, dass ich in text mode und in 13h mode was machen wollte?

Das liegt daran, dass du Copy-Paste-gesündigt hast Stell dir mal folgende Frage: Wieso hätte es funktionieren sollen? Du befindest dich im Textmodus und versuchst Pixel zu setzen.

Für Grafik gibt es eigentlich drei Möglichkeiten:
1. VGA: Nur geringe Auflösungen und wenige Farben, dafür aber (meines Wissens nach) problemlos aus dem Protected-Mode verwendbar da VGA-Hardware per I/O Ports angesteuert wird.
2. VBE (VESA Bios Extensions): Höhere Auflösungen und mehr Farben, unterstützt aber nicht immer alle möglichen Auflösungen (z.B. ist auf meinem Notebook die native Auflösung des Bildschirms nicht per VBE setzbar). Schwieriger zu benutzen, da die Verwendung im Real Mode vorgesehen war. Es gab zwar später ein Protected-Mode Interface, aber nach allem was ich bisher gehört habe war das auch nur halbgarer Käse.
3. Eigener Treiber: Extrem hoher Aufwand, dafür kann ein eigener Treiber dann alles unterstützen was die Hardware bietet. Aus Mangel an Dokumentation und Beispielcode extrem schwierig, und selbst große Projekte wie nouveau, die schon seit Jahren existieren und zu denen hunderte Menschen beigetragen haben, können die Hardware nicht komplett ausreizen.
Wobei, eine eingeschränkte vierte Möglichkeit gibts auch noch:
4. Emulator-Treiber: Fällt zwar eigentlich unter Nr.3, aber Treiber für emulierte Hardware sind deutlich einfacher zu schreiben. Vor einiger Zeit hab ich mal ein paar Minuten investiert und mir den BGA (Bochs Graphics Adaptor) angesehen, innerhalb von Minuten hatte ich bunte Pixel auf dem Bildschirm. Eine echt einfache Sache, aber dafür läufts halt nicht auf echter Hardware.

Aber an dieser Stelle noch einen Rat: Nicht zu früh an Grafik denken. Die buntesten Pixel bringen nichts wenn das OS dahinter nichts kann

Soll ich auf C umsteigen? Bis jetzt hatte ich mit C nur Probleme. Außerdem lernen wir in der Schule grade c++. Wobei wir da erstmal lernen was cin und cout ist -.-

Diese Frage solltest du niemals einer anderen Person stellen, höchstens dir selbst. Benutz einfach die Sprache die dir am angenehmsten ist bzw. die deinen gesteckten Zielen dienlich ist. Wenn du bereits in C++ angefangen hast, warum solltest du in C neu anfangen? Auch mit C++ ist OS-dev möglich.

4

Lowlevel-Coding / Re: Seltsamer Pagefault

« am: 21. August 2013, 21:57 »

BTW: in der pmm::alloc könnte eventuell auch ein if bitmap(counter) == 0 zu besserer Performance beitragen. Ist mir so beim singlesteppen aufgefallen.

Das ist eine super Idee, das bau ich gleich ein

Das kann ich leider nur sehr schwer überprüfen weil die Sourcen im Repository(1c6bf59d20…) scheinbar nicht 100%ig mit dem ISO zusammen passen. GDB spring bei mir zumindest in der VMM.pas wirr in irgenwelchen Zeilen herum in denen kein code steht.

Ja, ich hatte kurz bevor ich die ISO erstellt habe ein paar if's and verschiedenen Stellen eingefügt die Alarm schlagen wenn ungewöhnliche Werte auftauchen. Es wäre wohl schlauer gewesen auf den Repository-Stand zurückzugehen bevor ich die ISO erstellt hab.

du rufst

Code: [Auswählen]

asm invlpg [v_addr]auf. Damit Invalidierst du die Speicherseite die die Variable V_ADDR enthält, nicht die Adresse die in V_ADDR drin steht. (Also das tut zumindest die Binärversion im ISO)

Autsch... Der Fehler ist ja echt mies, da wäre ich absolut nicht drauf gekommen. Die Zeile ist schon so lange im Kernel und hat vorher nie Probleme gemacht, daher ging ich davon aus dass sie stimmt. Ich hab die Stelle jetzt geändert und meine Probleme sind verschwunden, so sieht die Stelle jetzt aus:

Code: (freebasic) [Auswählen]

asm
mov eax, dword ptr [v_addr]
invlpg [eax]
end asmDamit funktioniert es jetzt, ich hoffe dass es jetzt nicht auf irgendeine andere Weise falsch ist.

Schon mal vielen Dank für die Hilfe, aber darf ich dich noch fragen, wie du so etwas debuggst? Du hast ja vermutlich QEMU + GDB benutzt, aber benutzt du da eine GUI für GDB? Und wie geht man vor, wenn man so etwas debuggen will? Hast du da vielleicht eine Empfehlung für ein Tutorial, Dokumentation o.Ä. für mich? Mein "Debugging" bestand bisher immer nur aus eingebauten Debugausgaben und dem Ansehen von QEMU-logs, und ich würde in Zukunft solche Fehler gerne selbstständig aufspüren können.

5

Lowlevel-Coding / Re: Seltsamer Pagefault

« am: 21. August 2013, 04:43 »

Ich hab jetzt mal genauer nachgesehen an welcher Stelle die Nullen ins Spiel kommen. Von GRUB bekomme ich das Modul ohne Probleme geladen, die ersten vier Bytes davon sind in Ordnung, auch nach dem memcpy-Aufruf. Im Zielspeicher stehen nach dem memcpy aber Nullen drin. Testweise hab ich auch mal das nachfolgende memset auskommentiert aber das hat nichts geändert. Ich weiß echt nicht mehr weiter - wie kann die Größe des größeren Programmes dafür sorgen, dass der Kernel sich so seltsam verhält?

/edit: Auch wenn das Stack-Mapping bei memcpy verschwindet, memcpy kopiert aber tatsächlich korrekt. Im Speicherbereich landen die richtigen Bytes, aber obwohl genau dieser Speicherbereich dann in den Prozesskontext gemappt wird (ich habs überprüft, es wird genau dieser physische Speicherbereich gemappt) stehen im Prozesskontext dann Nullen drin. Ich kapiers einfach nicht...

6

Lowlevel-Coding / Re: Seltsamer Pagefault

« am: 20. August 2013, 07:19 »

Und wieder hast du den richtigen Riecher...
Direkt bevor den Kernel in den userspace springt (in handle_interrupt) hab ich die vorgeschlagene Debugausgabe eingefügt. Ich lasse mir einfach die ersten vier Bytes an 0x40000000 ausgeben. Wenn ich den kleinen Prozess nehme (mit dem es ja bisher funktioniert) erhalte ich 0xB8575653. Das entspricht push ebx, push esi, push edi und dem ersten Byte von mov eax, 42. Das ist für den kleinen Prozess korrekt. Mit dem großen Prozess kommt 0x00000000 heraus - damit wäre der Pagefault ja dann erklärt. Jetzt stellt sich nur die Frage, wo diese Nullen herkommen und wie sie dort hingekommen sind.
Ich habe auch noch herausgefunden an welcher Stelle das Stack-Mapping "verschwindet": Es ist der memcpy-Aufruf mit dem das Programm in den reservierten Speicherbereich kopiert wird. Direkt davor ist der Stack noch da, direkt danach nicht mehr, und wenn ich memcpy auskommentiere bleibt der Stack auch da. Meine memcpy-Implementierung scheint nicht das Problem zu sein, ich hatte sie testweise mal durch eine simple for-Schleife ersetzt.
So, ich geh dann erstmal schlafen, mir fallen gerade ständig die Augen zu

7

Lowlevel-Coding / Re: Seltsamer Pagefault

« am: 20. August 2013, 05:49 »

Der Aufruf von free_pagetable sollte eigentlich kein Problem sein, sofern ich da keinen Denkfehler drin habe. resolve kann ja auch Adressen auflösen, die außerhalb des aktuellen Kontext liegen, daher wird die pagetable dort auch per get_pagetable besorgt, und wenn get_pagetable sie gemappt hat, muss sie auch wieder per free_pagetable freigegeben werden. Wenn die pagetable zum aktuellen Kontext gehört mappt get_pagetable ja nichts und free_pagetable tut dann einfach nichts.

Zum Rückgabewert: Nun, ich könnte mich schlagen, dass ich darauf nicht gekommen bin. Nicht nur, dass ich den Rückgabewert nicht überprüft habe, ich habe auch noch den falschen Kontext übergeben, resolve hat nämlich im Kontext des Prozesses nach der physischen Adresse gesucht - das war natürlich völliger Unsinn. Und eine print-Anweisung und ein Test haben ergeben: Der erste Aufruf von resolve hat das korrekte Ergebnis ausgespuckt, der zweite hat 0 zurückgegeben. Das erklärt auch das mapping von 0x40001000 nach 0.
Ich habe den Code von elf.load_image jetzt geändert, bevor ich die Adresse meines Speicherbereichs an vmm.kernel_automap übergebe speichere ich mir nun die physische Adresse in phys_mem ab. Die Schleife, die den Speicher in den Prozess-Kontext überträgt, sieht nun so aus:

Code: (freebasic) [Auswählen]

'' map the pages into the context of the process
for counter as uinteger = 0 to pages-1
if (not (vmm.map_page(@process->vmm_context, cast(any ptr, min_addr + counter*pmm.PAGE_SIZE), _
  phys_mem+(counter*pmm.PAGE_SIZE), _
          (vmm.PTE_FLAGS.WRITABLE or vmm.PTE_FLAGS.PRESENT or vmm.PTE_FLAGS.USERSPACE)))) then
panic_error("Could not assign memory to the process")
end if
nextDie Verwendung von phys_mem dürfte nicht nur deutlich schneller sein, sondern erspart mir auch eine potenzielle Fehlerquelle. Oh, und ich habe bei der Schleife noch "0 to pages" auf "0 to pages-1" korrigiert, sonst zähle ich eine Page zu viel. Ich hab das ganze auch getestet und mir wieder von qemu den TLB ausgeben lassen, und siehe da:
0000000040000000: 0000000000195000 ----A--UW
0000000040001000: 0000000000196000 -------UW
Das Programm wird jetzt also korrekt gemappt. Aber: Der Stack ist immernoch nicht da und auch der mysteriöse Pagefault ist noch unverändert.

Erst mal vielen Dank, den Fehler hätte ich vermutlich noch tagelang übersehen. Ich hoffe du hast noch mehr gute Ideen auf Lager

/edit: Ok, das wird immer seltsamer... Der Stack war nämlich mal da. Ich hab gerade in thread_create den Kontext des Prozesses aktiviert und ein hlt eingefügt. Dann hab ich mir mit dem qemu Monitor den TLB angeguckt, und dort steht ganz unten ein 0xfffff000 -> 0x00193000 Mapping drin. Das heißt dann wohl, dass zwischen thread_create und dem Loslaufen des Prozesses irgendwas seltsames mit dem Kontext passiert.

8

Lowlevel-Coding / Seltsamer Pagefault

« am: 20. August 2013, 01:23 »

Hi,
ich habe momentan ein Problem bei dem ich nicht mehr weiter weiß. Vor ein paar Tagen hab ich mal wieder an meinem Kernel gebastelt und er ist nun so weit dass er einen simplen userspace-Prozess ausführen kann. Der userspace-Prozess ruft dabei einen simplen Syscall auf, der eine einfache Textzeile ausgibt. So sieht es aus, wenn es funktioniert:

Als ich dann anfing meinen simplen Prozess zu erweitern, fingen die Probleme an. Wenn der userspace-Prozess groß genug wird fällt der Kernel beim Sprung in den userspace auf die Nase, das scheint aufzutreten sobald der Prozess im RAM die Größe einer Page übersteigt. Das sieht dann folgendermaßen aus:

Um das Problem einzugrenzen hab ich dann meinen Testprozess vereinfacht, er sieht so aus:

Code: (asm) [Auswählen]

mov eax, 42
int 0x62
jmp $

xchg eax, eax
[...]Wie man sieht, keine Stackzugriffe und nur ein simpler Syscall, aufgeblasen wird das dann mit sehr vielen "xchg eax, eax"-Befehlen um das Programm groß genug zu bekommen um den Crash zu provozieren.
Natürlich hab ich mir dann das Logfile von qemu angesehen, ich hab es mal hier auf pastebin gepackt.
Was mich zunächst daran irritiert ist das cr2 die Adresse 0x00000000 angibt. Dort ist die obere Grenze des vom Kernel bereitgestellt usermode-Stacks, aber ein Zugriff auf den Stack findet ja gar nicht statt! Um ganz sicher zu sein hab ich mir zunächst per objdump die Anweisung an der von qemu angegebenen eip-Adresse angesehen, und dort steht ganz brav mein "mov eax, 42". Also, tatsächlich kein Stackzugriff, und beim instruction fetch scheints ja auch nicht zu krachen (sonst wäre ja cr2=eip), also was will die CPU an 0x00000000?
Ebenfalls seltsam ist, dass der error-code angibt, die Page sei nicht gemappt. Ich hab daher probiert per "info tlb" aus qemu mehr Infos herauszubekommen, und um das ganze vergleichen zu können hab ich das einmal mit einer funktionierenden Version des Programms (d.h. klein genug) und einmal mit der nicht funktionierenden Version getan:
1. Funktionierend
2. Nicht funktionierend
Ich hab die beiden Files dann mit einem diff-Tool (meld) verglichen, dabei fiel mir zunächst auf, dass in der nicht funktionierenden Version folgende Zeile fehlte: "00000000fffff000: 0000000000192000 ---DA--UW". D.h. der Stack ist nicht gemappt - wie bereits der Pagefault sagte. Auffällig ist auch das hier:
0000000040000000: 0000000000195000 ----A--UW
0000000040001000: 0000000000000000 -------UW
Die zweite Page des Programmes ist also nicht korrekt gemappt. Das sind zwar schon zwei Probleme, allerdings dürften beide nicht für den Pagefault verantwortlich sein. Es ist mir auch ein Rätsel, warum diese beiden Adressen nicht korrekt gemappt sind - die entsprechenden Code-Zeilen wurden definitiv ausgeführt.

Ich habe jetzt schon einige Stunden damit verbracht auf logs zu starren und an meinem Code herumzubasteln, aber die Ursache für den Pagefault und die zwei anderen Fehler konnte ich nicht finden, trotz zahlreicher eingefügter Print-Anweisungen. Daher poste ich mein Problem nun hier, in der Hoffnung dass jemand von euch eine Idee oder einen Tipp hat, damit ich dieses Problem endlich beheben kann. Der Code entspricht, abgesehen von ein paar zusätzlichen print-Anweisungen, der Version im Repository. Relevant für mein Problem dürften wohl vor allem elf.bas, modules.bas und vmm.bas sein.

Grüße,
TheThing


/edit: Ich hab mal eine ISO mit besagtem Problem hochgeladen: http://venom.improved-madness.de/frost.iso

9

tyndur / Re: Kleine Ungenauigkeit in kernel2

« am: 31. March 2013, 21:02 »

Als Fehler würde ich das zwar nicht unbedingt bezeichnen

Ja, ein richtiger Fehler ist das ja nicht, deswegen hab ich ja auch Anführungszeichen um das Wort Fehler gemacht Hatte mich nur vorhin etwas irritiert, als ich anhand von lowlevel-Wiki, osdev-Wiki, tyndur-Code und Spezifikation mal angefangen habe, meinem Kernel die Grundzüge von SMP beizubringen.

10

tyndur / Kleine Ungenauigkeit in kernel2

« am: 31. March 2013, 17:00 »

Hi,
ich glaube einen kleinen "Fehler" in der SMP-Implementierung von kernel2 gefunden zu haben. Laut Spezifikation liegt der dritte Bereich, in dem der floating pointer liegen kann zwischen 0x0F0000 und 0x0FFFFF, kernel2 sucht an dieser Stelle allerdings bereits ab 0x0E0000 und sucht damit einen doppelt so großen Bereich ab. Habe ich da irgendetwas übersehen oder ist das tatsächlich ein Fehler in kernel2? Sollte es einer sein dürfte das ja eigentlich nicht weiter schlimm sein (der kernel betreibt dann halt nur mehr Aufwand als nötig), könnte allerdings Lernende etwas verwirren, so wie mich vorhin

11

Lowlevel-Coding / Re: C - Inline Assembler: Sicherheitslücke?

« am: 31. March 2013, 16:46 »

Ich selbst bin auch kein großer Freund von Managed Code, solte man jedoch (aus welchen Gründen auch immer) auf die hardwareseitigen Sicherheitsmechanismen verzichten wollen ist das meines Wissens nach die einzige Möglichkeit Unfug zu unterbinden. Ich würde jedoch stets dazu raten sich mit den harwareseitigen Sicherheitsmechanismen abzufinden, der Aufwand den man betreiben muss bis etwas zufriendestellend läuft ist bedeutend geringer und man hält sich die Möglichkeit des Portierens von Software offen.

12

Lowlevel-Coding / Re: C - Inline Assembler: Sicherheitslücke?

« am: 30. March 2013, 11:06 »

Ich bin aber davon ausgegangen, dass man das softwareseitig löst... Möglich wäre es ja.

Nur bedingt. Wenn du den Anwendern erlaubst Programme in Maschinencode auszuführen, kannst du softwareseitig nicht viel machen. Eine Möglichkeit wäre allerdings nur Programme in Managed Code zu erlauben wie das meines Wissens nach Singularity tat. Das ist dann softwareseitig gelöst und du kannst auf die hardwareseitigen Sicherheitsmaßnahmen größtenteils verzichten, theoretisch brauchst du noch nicht einmal mehrere Adressräume. Allerdings hat das den Nachteil dass jegliche Software in Managed Code sein muss, d.h. es wird sich vermutlich nicht viel auf das OS portieren lassen.

13

Offtopic / Re: Bis wann ist ein OS ein OS?

« am: 11. March 2013, 04:59 »

Nö. Der hatte bereits ein Kickstart ROM (Upgradeanleitung).

Mist, mein müdes Gehirn hat doch glatt Kickstart mit der Workbench verwechselt. Aua. Vielleicht ist es auch einfach zu lange her, dass ich meinen Amiga 500 mal angeschlossen hatte.

14

Offtopic / Re: Bis wann ist ein OS ein OS?

« am: 10. March 2013, 04:31 »

Aber auch nur, weil die Entwicklung zum Erscheibungszeitpunkt noch nicht rechtzeitig fertig war. Alle Nachfolger hatten Kickstart-ROMs. Ich korrigiere meine Aussage: Alle Heimcomputer der 80er außer der Amiga 1000.

Aus reinem Spaß an Haarspalterei möchte ich einwerfen, dass es beim Amiga 500 genauso war

15

Lowlevel-Coding / Re: Was genau ist ein Sprung?

« am: 15. February 2013, 15:56 »

Ja, hat es. jmp steht für jump, engl. to jump = springen. jmp sorgt dafür, dass der Prozessor zur angegebenen Speicheradresse springt.
Ein kleines Beispiel:

Code: [Auswählen]

mov eax, 0xDEADC0DE
jmp testlabel
mov eax, 0xDEADBEEF
testlabel:
#irgendetwas...Die Prozessor wird zuerst "mov eax, 0xDEADC0DE" ausführen, danach findet er jmp (das Label ist natürlich in der Maschinensprache nicht mehr vorhanden, sondern wird durch die entsprechende Adresse ersetzt) und überspringt den zweiten mov-Befehl.
Würde der Prozessor keine Sprünge kennen, hätten wir am Schluss 0xDEADBEEF in eax, da der Prozesor aber ein braver Kerl ist und unseren Befehlen gehorcht, steht da auch schön 0xDEADC0DE drin.
Sprünge sind immer dann notwendig, wenn du von einer strikt linearen Programmausführung abweichen willst, d.h. bei Verzweigungen (if) brauchst du Sprünge, ebenso bei Prozeduraufrufen.
Allerdings gibt es mehrere Sprungbefehle, je nachdem warum genau du springen willst. Für Prozeduraufrufe z.B. gibt es afaik "call", welches dir eine Rücksprungadresse auf den Stack legt (schließlich möchte deine Prozedur die Kontrolle auch zurückgeben), dann gibt es noch bedingte Sprünge, d.h. der Prozessor wird nur springen, wenn bestimmte Flags gesetzt sind o.Ä.

P.S:  Der Assembler-Code ist ohne jegliche Gewähr, ich hab in letzter Zeit mehr mit MIPS-Assembler als mit x86-Assembler zu tun.

16

Softwareentwicklung / Re: CPU Register auslesen

« am: 08. January 2013, 21:00 »

Da hat kevin natürlich Recht, die aktuellen Werte sind ja im Bezug auf den Fehler, der auftrat, völlig irrelevant.
Wie man elegant an die richtigen Werte kommt, kann man sich hier und hier ansehen.

17

Offtopic / Re: Screen of Death

« am: 29. November 2012, 20:10 »

So, einmal der normale panic-screen:

Und einmal mit dem Parameter -no-clear-on-panic, der hilft zu erkennen wo der Fehler auftrat:

Bei anderen Fehlern, z.b. Pagefaults, spuckt der natürlich ein paar infos mehr aus. Erweitern werd ich ihn aber trotzdem noch da ein paar mehr Infos noch praktisch wären.

18

OS-Design / Re: Multiboot Information Structure

« am: 28. November 2012, 23:57 »

Debian benutzt generell etwas ältere, dafür stabile Software. Wenn du das neueste vomm Allerneuesten willst, bleibt dir unter Debian meist nur das selberbauen. Ist bei qemu aber echt nicht schwer

/edit: Bei Wheezy gibts immerhin 1.1.0.

19

Offtopic / Re: Beichte

« am: 25. November 2012, 23:50 »

@TheThing: da kannst du mir doch bestimmt mal einen VS2012-Key zukommen lassen, oder?

Ist schon für mich selbst beschlagnahmt

Zum Thema Metro: Ich kann mir echt nicht vorstellen, wie man das wirklich produktiv nutzen könnte. Auf einem "Smartphone" mag sowas ja noch akzeptabel sein, aber auf einem Desktop? Da bleibe ich lieber bei KDE 4, das macht meiner Meinung nach wenigstens Schritte in die richtige Richtung. Diese ganze Abriegelei setzt dem ganzen ja sowieso noch die Krone auf (nervt übrigens auch auf Android, das ich nun leider nutzen muss, da mein bisheriges Handy vor ein paar Tagen den Geist aufgegeben hat).

20

Offtopic / Re: Beichte

« am: 24. November 2012, 13:29 »

Ich muss sagen, Windows 8 hat bei mir einen Rekord aufgestellt. So schnell war bisher kein anderes Betriebssystem wieder von der Platte. Hatte es auch nur installiert weil ich eine DreamSpark-Lizenz kostenlos abgestaubt hatte (Student sein hat seine Vorteile ).