Nachrichten

161

Offtopic / Re: Hello Lowlevel!

« am: 21. January 2014, 03:39 »

Ich weiß nicht so recht, was du dir vorstellst, aber wenn es ein auf JS basierendes Userland mit Linux-Kernel drunter werden soll, dann würde ich (erstmal) was eigenes machen. Das hilft auch ungemein beim Verständnis der Technik dahinter. Später kann man immernoch feststellen, dass man lieber eine vorhandene Distribution als Basis nimmt.

Tutorials gibt es im Internet, z.B. From PowerUp To Bash Prompt oder How To Build a Minimal Linux System from Source Code. Beide stinken zwar schon ein kleines bisschen, aber durchspielen kann man es ja trotzdem mal (in einer virtuellen Maschine z.B.).

Linux from Scratch richtet sich eher an Leute, die ein benutzbares System aus Standardkomponenten haben möchten, aber da sehe ich dich im Augenblick noch nicht.

Gruß,
Svenska

162

Offtopic / Re: NSA und die Sicherheit von Betriebssystemen

« am: 20. January 2014, 06:09 »

Könnte man dadurch mehr Sicherheit erreichen?

Theoretisch ja, praktisch eher nein. Wenn du selbst ein Betriebssystem baust, dann wirst du da erstmal Unmengen an Bugs haben, die woanders schon vor langer Zeit entfernt wurden. Außerdem wirst du an einigen Stellen ziemlich sicher nicht alles komplett durchdacht haben, wodurch sich Hintertüren ergeben, an die du nicht denkst. Sollte dein Betriebssystem das alles nicht haben und zusätzlich noch verbreitet genug sein, dann können Geheimdienste da trotzdem subtile Bugs einfügen.

Alternativ suchen sie einen anderen Angriffsvektor. Jedes Betriebssystem wird auf einer Hardware ausgeführt, die fast vollständig aus (nicht ersetzbarer und geschlossener) Software besteht; für (DMA-fähige!) Peripherie gilt das ebenfalls. Linux kommt nicht aus den USA, dein BIOS schon. Wenn nicht die Chinesen unterwegs ihre eigenen Türen eingebaut haben.

Kompatibilität zu POSIX könnte man dabei ja leicht erreichen, und damit hätte man schon viel Software zur Verfügung.

Mit POSIX allein hast du ein System der 80er, aber noch lange keinen modernen 3D-fähigen Desktop mit Webbrowser und Videobeschleunigung.

Ich war ehrlich gesagt, etwas erstaunt, dass es noch keinen NSA-Thread hier gibt, da das Thema gerade für Betriebssysteme sehr wichtig zu sein scheint.

Ich vermute, dass den meisten hier entweder klar ist, dass es keinen vollständigen Schutz vor Geheimdiensten gibt, oder dass es für ein selbst entwickeltes Betriebssystem sowieso egal ist.

Man kann die Kosten für einen gezielten Angriff erhöhen. Snowden hat aber gezeigt, dass die Kosten keine Rolle spielen. Es gibt schlicht zu viele Angriffsvektoren, die man nicht unter Kontrolle hat.

Gruß,
Svenska

163

Lowlevel-Coding / Re: Floppy Kabel für 5'25 Zoll gesucht

« am: 16. January 2014, 21:56 »

Hallo,

notfalls geht es auch ohne. Man braucht nur eine Diskette (die Bootdiskette), alle weiteren kann man notfalls auf dem Zielrechner selbst erstellen. Die Daten holt man am elegantesten über ein serielles (Nullmodem-)Kabel von einem Hostrechner. Moderne Versionen von DOS bieten INTERLNK und INTERSVR an, womit die Laufwerke des Hosts als Laufwerksbuchstaben auftauchen, der Norton Commander kann sich selbst über so ein Kabel klonen und bietet schnellere Datenübertragung an.

Damit kann man die Disketten ziemlich komplett weglassen.

Übrigens gibt es Projekte, um IDE-Festplatten (bzw. CompactFlash-Karten) an XT-Computer anzuschließen, z.B. XTIDE. IDE-Festplatten werden vom originalen PC-BIOS nicht unterstützt, müssen also ihre eigene ROM-Erweiterung mitbringen und das System-BIOS muss ROM-Erweiterungen unterstützen (IBM-Maschinen: BIOS-Datum 10/27/82 oder neuer).

Nachtrag: Die neue Revision dieser Karte kann übrigens auch von der seriellen Schnittstelle booten. Wenn man einen schnellen COM-Port hat, sogar mit bis zu 460.8 kBit/s auf einem Ur-PC.

Gruß,
Svenska

164

Lowlevel-Coding / Re: Floppy Kabel für 5'25 Zoll gesucht

« am: 15. January 2014, 21:01 »

Kein Floppy-Controller, kein Floppy. Ganz einfach.
Für ISA sind mir genug Controller bekannt, für PCI nicht. USB-Diskettenlaufwerke kann man vermutlich nicht schlachten.

165

Lowlevel-Coding / Re: Bandlaufwerk (Floppy-Streamer)

« am: 15. January 2014, 18:54 »

QIC-80 ist ein Standard, so dass du wenigstens keinen exakten Herstellertreiber brauchst.
Die Teile wurden von Linux seit mindestens 2.0-Zeiten unterstützt, und die Unterstützung in 2.6.19 entfernt (ftape). Du kannst dir die notwendigen Informationen aus den Linux-Sourcen zusammenbasteln; einen Patch für aktuellere Kernel gibt es hier. Aber: "floppy" und "ftape" sind inzwischen inkompatibel zueinander und vermutlich funktioniert das mit SMP und 64 Bit auch nicht mehr.

Ich hab ein Lesegerät und zwei Bänder (eins davon unbenutzbar). Die Teile machen nicht wirklich Spaß.

Treiber für DOS gibt es im Internet; Windows NT unterstützt die Geräte mit der mitgelieferten QIC-117.SYS in den Versionen 3.1 bis 4.0, danach nicht mehr.

166

Lowlevel-Coding / Re: Floppy Kabel für 5'25 Zoll gesucht

« am: 15. January 2014, 18:42 »

Gewöhnliche, alte Floppy-Kabel sind etwas kompliziert aufgebaut und haben:
- einen Pfostenstecker, der relativ allein am Ende ist; der kommt in den Floppy-Controller
- einen Pfosten- und einen Platinenstecker, die nah beieinander sind; nur einer! davon wird an das sekundäre Diskettenlaufwerk angeschlossen (Laufwerk B:)
- ein paar verdrehte Adern
- einen Pfosten- und einen Platinenstecker, die nah beieinander sind; nur einer! davon wird an das primäre Diskettenlaufwerk angeschlossen (Laufwerk A:)

Anmerkungen zum Kabel:
- Manche Kabel haben statt der Steckerpaare nur einen Stecker. Dann ist durch das Kabel festgelegt, welchen Typ die Diskettenlaufwerke haben. Neue Kabel haben meist nur 2 Stecker, dann geht nur ein 3.5"-Diskettenlaufwerk.
- Manche Kabel haben zweimal verdrehte Adern (einmal vor und einmal nach dem mittleren Steckerpaar). Dann sind A: und B: vertauscht.
- Manche Kabel haben keine verdrehten Adern. Dann muss man die Diskettenlaufwerke entsprechend jumpern.

Nichtbeachtung kann zur Zerstörung des Floppy-Controllers führen. (Ich spreche da aus Erfahrung.)

Anmerkungen zur Technologie:
- Moderne BIOSse unterstützen keine 5.25"-Diskettenlaufwerke mehr, moderne Windows-Versionen ebenfalls nicht. (Windows XP formatiert z.B. 3.5"/720 KB nicht mehr im Explorer.)
- Diskettenlaufwerke werden normalerweise auf "Laufwerk B:" gejumpert. Manche Hersteller fangen bei null an (dann "Drive 1"), andere bei eins (dann "Drive 2"). Ausnahmen werden durch das Kabel vorgegeben.
- Beachte, ob dein 5.25"-Diskettenlaufwerk ein DD-Laufwerk (360 KB) oder HD-Laufwerk (1.2 MB) ist. Ein HD-Laufwerk kann DD-Disketten nicht zuverlässig schreiben, weil die Spuren dünner sind. Wenn du mit 360 KB-Disketten arbeiten musst, dann formatiere sie zumindest auf einem 360 KB-Laufwerk prüfe die Daten.

Platinenstecker werden auf eine Platine gesteckt und finden sich bei älteren Geräten (8"- und 5.25"-Diskettenlaufwerke, ...). Pfostenstecker benutzt man bei moderneren Geräten (3.5"-Diskettenlaufwerke, IDE-Geräte, ...).

167

OS-Design / Re: Paging - Segen oder Fluch?

« am: 12. January 2014, 22:50 »

Wieviel Speicher es gibt, erfährst du aus der Memory-Map, die dir dein multibootfähiger Bootloader beim Start mitgibt. Oder du fragst das BIOS, das kann dir da auch kompetent Rede und Antwort stehen. Übrigens sollte pmm_alloc() nur Adressen rausrücken, wo auch wirklich freier RAM zu finden ist.

"Gesamter Speicher - Rausgegebener Speicher = noch freier Speicher" ist dann sogar ganz einfach.

168

OS-Design / Re: Paging - Segen oder Fluch?

« am: 12. January 2014, 20:24 »

Hallo,

Und natürlich der gute alte 486'er mit 128MB Speicher, wie soll ich da 1GB Kernel mappen + Programme? Eigentlich gar nicht möglich oder?

Wow, wie hast du so viel RAM in die Maschine gekriegt?

Jeder Prozess hat 4 GB "Adressraum", belegt aber nur so viel RAM, wie du ihm auch gibst. Der Kernel z.B. ist in jeden Prozess gemappt, aber die Tabellen zeigen alle auf den gleichen RAM. Wenn du das mit Anwendungen machst, hast du Shared Memory.

Und dann kannst du natürlich noch mehr RAM mappen, als du hast ("overcommitment"). Wenn ein Programm da wirklich drauf zugreifen möchte, bekommst du einen Page-Fault und kannst dann entweder echten RAM zuweisen oder auf die Festplatte auslagern.

Dann musst du natürlich immer im Blick haben, wieviel RAM du noch frei hast - aber dafür hast du ja die physische Speicherverwaltung.

169

OS-Design / Re: Paging - Segen oder Fluch?

« am: 07. January 2014, 03:40 »

Zuerst:
- initiale Page Table erstellen und füllen (4 KB), initiales Page Directory (4 KB) erstellen und ersten Eintrag damit füllen
- Adresse des Page Directories nach CR3 tun (z.B. mit Inline-Assembler)
- Paging aktivieren
Wenn du Paging aktivierst, ohne ein gültiges Page Directory geladen zu haben, wirft dir die CPU höchstwahrscheinlich mehrere Exceptions vor die Füße und resettet.

Beim Task erstellen:
- Page Directory erstellen (4 KB)
- initiale Page Table dort eintragen (ist schon vorhanden)
- weitere Page Tables erstellen, entsprechend füllen und ins Page Directory eintragen (je 4 KB/Page Table)

Beim Task wechseln:
- Adresse des Page Directories des Task nach CR3 schreiben

Wenn du nach CR3 schreibst, wird der TLB automatisch geflusht. Selbst machen musst du es nur, wenn du im gerade aktiven Page Directory (oder den dort eingetragenen Page Tables) was veränderst. Entweder, du lädst CR3 danach mit dem gleichen Page Directory neu, was langsam ist, oder du nutzt Inline-Assembler für INVLPG, was erst ab dem 486er geht.

Jede Page Table beschreibt 4 MB Speicher, ist aber nur 4 KB groß. Das Page Directory selbst ist auch 4 KB groß. Lass dich nicht dadurch verwirren.

170

OS-Design / Re: Paging - Segen oder Fluch?

« am: 06. January 2014, 00:46 »

Jede Page Table und jedes Page Directory sind einfach nur 4 KB große Speicherbereiche, wo du die Mapping-Informationen reinschreibst.

Dein pmm_alloc() gibt dir eine physische Adresse, die du in die Page Table einträgst. Die physische Adresse der Page Table trägst du dann in das Page Directory ein. Wenn du dann die physische Adresse des Page Directories in CR3 hineinschreibst, ist das Mapping aktiv.

171

OS-Design / Re: Paging - Segen oder Fluch?

« am: 05. January 2014, 17:51 »

Jeder Eintrag des Page Directories zeigt auf eine Page Table. Jeder Eintrag in der Page Table zeigt auf eine Page. Also verwaltet jeder Eintrag in der Page Table einen Speicher von 4 KB, und jeder Eintrag im Page Directory verwaltet 4 MB.

Üblicherweise mappt man den Kernel in jedem Task an die gleiche Stelle. Damit ist er überall immer gleich gemappt, damit kann das beim Anlegen von Page Directories gleich mit erledigt werden.

Ein Eintrag im Page Directory verwaltet 4 MB. Wenn du größere Speicherblöcke benutzen möchtest, dann brauchst du mehrere Einträge im Page Directory.

Was die Paging-Unit tut ist nichts anderes, als jedem 4K-Speicherblock im Adressraum einen 4K-Speicherblock im RAM zuzuweisen. Welchen genau, steht in den Tabellen. Auf den Speicher greifst du also ganz normal zu.

172

OS-Design / Re: Paging - Segen oder Fluch?

« am: 05. January 2014, 02:16 »

Deine Frage lautet kurz: Was ist Paging und wie funktioniert es, brauche ich es und überhaupt und so?

Grundsätzlich brauchst du kein Paging, ein Betriebssystem funktioniert auch ohne. Wenn du dich auf x86 im Protected Mode beschränkst, kannst du Speicherschutz auch mit Segmentierung allein herstellen. Außerdem beherrscht auch nicht jede CPU Paging.

Eine pagingfähige MMU enthält nur eine Tabelle, die aus einer "CPU-Adresse" eine "RAM-Adresse" macht, im Sinne von "wenn die CPU 0x12340000 sagt, meint sie in Wirklichkeit 0x43210000". Diese Tabelle beschreibt Blöcke von jeweils 4 KB, enthält damit 1 Mio Einträge (4 GB Adressraum / 4 KB Pagegröße) und belegt damit 4 MB RAM. Das ist zu viel.

Also hat man die Tabelle in kleinere Teiltabellen zerteilt, die jeweils nur 1024 Einträge (4 MB Adressraum / 4 KB Pagegröße) haben und damit zufällig genau eine Page groß sind. Diese heißen Page Table - und die große Tabelle heißt Page Directory. Alle Page Tables zusammen belegen zwar auch 4 MB, aber sie müssen nicht existieren (dann kann man auf die dadurch beschriebenen Adressen halt nicht zugreifen) - das spart Speicher.

Jeder Task hat sein eigenes Page Directory, damit sich verschiedene Tasks nicht in die Quere kommen (Speicherschutz). Aber Teile der Page Directories können gleich sein (normalerweise ist der Kernel in allen Tasks gleich gemappt, und gemeinsam genutzter Speicher taucht auch in mehreren Tasks auf).

Ein vmm_create_context() erzeugt ein Page Directory und initialisiert es mit den Mapping, die sowieso überall sind. Ein vmm_alloc() sucht sich ein (oder mehrere) Speicherblöcke und mappt die als einzelnen, großen Block in ein Page Directory.

Wie du es im Detail implementierst, bleibt dir überlassen.
In Qemu kannst du mit "info mem" und "info tlb" anzeigen lassen, was gerade aktuell ist.

173

Offtopic / Re: Frohe Weihnachten 2013

« am: 24. December 2013, 17:31 »

Ein frohes Fest wünsche ich euch auch, und einen guten Rutsch ins neue Jahr. Möge es besser werden als dieses.

174

Offtopic / Re: Warning: empty character constant ?

« am: 13. December 2013, 23:51 »

Überrascht mich auch etwas, aber das knallt tatsächlich.
Ersetzt man *a durch a[], funktioniert es.
Schreibt man const davor, gibt es in beiden Fällen einen Compilerfehler (logisch).

175

Offtopic / Re: Warning: empty character constant ?

« am: 13. December 2013, 13:55 »

Du sollst das Tutorial weder kopieren noch unverstanden abschreiben.

Es ist uebrigens besser, statt einem Foto der Fehlermeldung einfach den Text der Fehlermeldung hier reinzukopieren (z.B. in Code-Tags) und am besten noch gleich den betreffenden Code dazu.

Beide Compilerausgaben sind keine Fehler, sondern nur Warnungen. Im zweiten Fall deklarierst du eine Funktion mit einem Rueckgabewert, hast aber kein return in der Funktion drin - im ersten Fall handelt es sich um den Hinweis, dass ein Stringliteral in C++ nicht mehr automatisch in einen normalen C-String umgewandelt werden sollte. Ueberhaupt ist C++ im Kernel immer so eine Sache: Wenige Dinge funktionieren, viele Features brauchen aber eine Laufzeitunterstuetzung (z.B. funktionierende Speicherverwaltung, Multithreading), und manche Eigenschaften sind in einem Kernel nicht wirklich nutzbar.

Wenn du dich mit den Details nicht auskennst, ist es vermutlich erstmal einfacher, bei C zu bleiben.

Gruss,
Svenska

176

Lowlevel-Coding / Re: Keyboard Treiber und Weitere Schritte

« am: 01. December 2013, 22:57 »

Wenn ich das in Bochs starte und z.B. 'ä' ,'ü' 'ß' 'Alt Gr' drücke, krieg ich die nachricht, dass diese Keys nicht gemappt sind. Wie kann ich das umgehen?

Du könntest sie mappen. Neben Englisch ist Deutsch da noch genügsam: Die Codepage 437 (Standardeinstellung) enthält alle benötigten Zeichen. Wenn du Dateien einliest, wirst du die Umlaute aber an anderen Stellen finden.

Sollte ich jetzt einen Prozess 'Terminal' erstellen, der beim Start automatisch aufgerufen wird und die Eingabe z.B. in nem Array speichert und mit im Programm hinterlegten Befehlen vergleicht und auswertet?

Du wirst vermutlich Programme schreiben wollen, z.B. eine Shell. Ein zeichen- oder zeilenbasiertes Interface ist recht einfach zu bauen.

Für eine Art "Textmodus-Paint" musst du die Cursorposition irgendwie ändern können, auch verschiedene Farben wären nicht schlecht. Da kannst du dir etwas eigenes ausdenken oder einen existierenden Standard implementieren (z.B. ANSI Escape-Codesequenzen). Das passiert dann aber im VGA-Treiber.

Bin ich jetzt besser beim Multithreading aufgehoben? Weil ich hab die befürchtung, dass ich das im reinen Terminalmodus
noch garnicht sinnvoll verwenden kann.

Du kannst die serielle Schnittstelle benutzen (in Qemu mit Strg+3 erreichbar, mit Strg+1 geht's wieder zurück). Dann hast du sozusagen zwei Bildschirme und zwei Tastaturen, zwischen denen du umschalten kannst (die Qemu-Darstellung der seriellen Schnittstelle kann übrigens ANSI), um das ein bisschen zu testen. "Mehrere Programme gleichzeitig" ist aber erst der Schritt nach "ein Programm gleichzeitig".

Programme kann ich noch nich starten. Aber das dürfte ja soweit kein Problem sein, als das Programme ja nichts weiter als C-Codes sind und als "Prozesse" ausgeführt werden.

Die ersten Programme wirst du vermutlich als Multiboot-Modul starten wollen. Fang also erstmal damit an, ein von GRUB geladenes Speicherstück in einen Prozess umzuwandeln.

177

Offtopic / Re: Hilfe bei Hardware problem

« am: 30. November 2013, 17:32 »

"Hallo. Ich habe ein Problem mit Gerät XY. Hier ein Bild, mit dem ein beliebiger Händler aus dem Internet das Gerät bewirbt. Was ist kaputt?"

178

Lowlevel-Coding / Re: Probleme mit dem Tutorial (GDT)

« am: 27. November 2013, 14:40 »

Tja, also, äh, GDT_ENTRIES definierst du wirklich nirgends und Code darf auch nicht außerhalb einer Funktion stehen.

179

Lowlevel-Coding / Re: Probleme mit dem Tutorial (GDT)

« am: 27. November 2013, 11:50 »

Im Protected Mode kann der Programmierer selbst entscheiden, welche Segmente es gibt und wo diese im Speicher liegen. Genau diese Informationen stehen in der GDT. (Zum Vergleich: im Real Mode haben alle Segmente 64 KB Größe und liegen im 16 Byte-Abstand hintereinander, deswegen braucht man so eine Tabelle da nicht.)

Du kannst die GDT auch als Array aus GDT-Einträgen ("struct gdt_entry") betrachten, wenn du das möchtest. Der Code tut das nicht und betrachtet die Einträge einfach als 64 Bit-Integer (jeder Eintrag hat 64 Bit, passt also) und set_entry() schreibt die Einzelteile mit Hilfe von Bithifts rein. Statt "struct gdt_entry gdt[GDT_ENTRIES]" steht da einfach nur "uint64_t gdt[GDT_ENTRIES]".

Man braucht Strukturen keinen Namen geben, dann sind sie anonym. Oft kommen die im Zusammenhang mit Typdefinitionen vor, also "typedef struct { ... } meintyp_t". Eine Möglichkeit reicht meist aus, um auf den Datentyp zuzugreifen. Die Ladefunktion definiert eine anonyme Struktur und genau eine Variable davon - man braucht diesen Typ schließlich nie wieder.

Wenn der Compiler über dein "asm" meckert, probiere mal "__asm__" stattdessen.

180

Offtopic / Re: Hardware selbstgebaut

« am: 24. November 2013, 19:34 »

Wenn ein Slot 32KiB Speicher anbieten kann und es 8 Slots (einschließlich des AVR) gibt, geht meine Rechnung irgendwie nicht auf (64KiB Speicher + 64KiB I/O).

Nur ein einziger Slot (Slot 1) kann zusätzlich zu I/O auch Speicher anbieten. Die Signale /MREQ und /RFSH sind an den anderen Slots nicht vorhanden. So können RAM und MMU auf eine einzige Karte.

Da 8 Bit I/O-Zugriffe auf dem Z80 einfacher sind (16 Bit-Zugriffe sind ein nachträglich dokumentierter Zufall und werden nicht von allen Clones und auch nicht vom 8080/8085 unterstützt), dekodiere ich A7 bis A5, um daraus /SEL für die Geräte zu generieren, ergibt 32 I/O-Adressen pro Slot. Geräte, die mehr brauchen, können aber auch volle 16-Bit-Zugriffe benutzen, haben dann aber einen fragmentierten I/O-Adressraum (256 Bereiche zu je 32 Bytes = 8 KB) im Z80.

Und wozu genau braucht man diese Bustreiber, durch die alle Signale von/zu der CPU gehen?

Eine kaputte Hardware kann mir die Bustreiber zerstören, aber nicht die CPU. Mehrere Slots parallel zu schalten führt (wegen der parasitären Kapazitäten) zu hohen kurzzeitigen Strompeaks, der den Bustreibern in der CPU nicht besonders gut tut.