Nachrichten

581

OS-Design / Zum Thema Mikrokernel

« am: 27. May 2005, 12:38 »

Jo, aber (D)DoS geht meistens über Server vollmüllen mit der mehr Bandbreite als der selber hat. Und wenn der Speicher voll ist, hast du evtl. nen DoS geschafft, aber noch keinen Buffer Overflow in dem Sinne das du probieren könntest Code einzuschleusen. Dazu musst du Puffer suchen über deren Grenzen hinaus geschrieben werden könnte. Die Funktion gets ist so ein Beispiel für den Anfang - gets auf nen Array auf den Stack angewendet und du kannst über den Array hinaus die Rücksprungaddresse oder andere Variablen abändern. Das exakt ist ein Buffer Overflow Angriff - wenn die Kiste stattdessen abschmiert, nun gut, dann ist der Dienst auch weg, stimmt schon.

582

OS-Design / Zum Thema Mikrokernel

« am: 27. May 2005, 09:28 »

Zum Thema BOF bei Servern, es gibt ja die lieben netten DOS-Attacken. Wenn die Anfragen zu schnell kommen, als dass sie der Server verarbeiten kann, kackt er irgendwann ab. Nur hat das mit Memory Protection direkt erstmal nix zu tun^^

Liegt daran das DoS-Attacken erstmal nichts mit Buffer Overflows zu tun haben, ausser ich finde einen Puffer der z.B. bei zu vielen IP-Verbindungen überlaufen könnte. Aber in den meistens Fällen werden Buffer Overflows durch einzelne, spezielle Datenpakete ausgelöst.

583

Lowlevel-Coding / RISC CPU

« am: 27. May 2005, 09:24 »

Abgesehen davon das die ganzen Transistoren dafür ja immer noch vorhanden sind wegen dem Legay Modus.
Aber 128 Register zu haben hat nicht nur Vorteile. Bei einem Taskswitch müssen die ja auch alle gesichert werden ...

584

OS-Design / Zum Thema Mikrokernel

« am: 26. May 2005, 12:45 »

Jop, NX-Bits sind auch eine Möglichkeit. Und bedenke das man ja bei dynamischen Webseiten auch noch mehr probieren könnte - ausser es sind JSP's oder php-skripte.

C/C++ - CGI Skripte wären auch eine mögliche Gefährdung!

585

Lowlevel-Coding / RISC CPU

« am: 26. May 2005, 12:44 »

Bei gleicher MHz Zahl wäre eine RISC CPU einer CISC CPU wahrscheinlich sogar unterlegen. Wobei man dann beachten muss, welche Befehle wieviele Takte brauchen.

Ausser du meinst PA-RISC und x86 ...

586

OS-Design / Zum Thema Mikrokernel

« am: 26. May 2005, 02:27 »

Ich sag nur Buffer Overflow. So startet sich ein Programm selber. Und dann ist ohne Speicherschutz direkt alles verloren. Mit Speicherschutz erstmal nur das, was das Programm tun könnte (was bei guten System SEHR viel weniger sein sollte).

Lösung -> Eine Technik nehmen die Buffer Overflow Angriffe gar nicht erst ermöglicht.

587

Lowlevel-Coding / Eigenes OS in 4 Monaten?

« am: 26. May 2005, 02:25 »

Du kannst auch im RM selber hardware nah programmieren, daran hindert dich nichts (und im RM heisst das ja wirklich NICHTS, man kann nicht mal was verhindern wenn man wollte), aber ja, ohne zumindestens etwas inline assembler (für spezielle instruktionen wie in/out oder interrupt handler) kommt nicht hin.

588

Lowlevel-Coding / RISC CPU

« am: 26. May 2005, 02:22 »

Wobei man bedenken muss das der PowerPC, welcher als RISC CPU gilt soweit ich weiss, auch hunderte von Befehlen kennt. In dieser Liste (http://pds.twi.tudelft.nl/vakken/in1200/labcourse/instruction-set/) wurde schon gespart und 107 sind noch übrig ...

Für optimales Tempo muss man wohl eine Balance finden, aber das sollte den OS Entwickler weniger kümmern - das ist eine Aufgabe die auch eine ganze Horde von Ingenieuren komplett auslasten kann.

589

OS-Design / Segmentierung

« am: 25. May 2005, 17:51 »

Was du tun kannst mit Segmenten - Local Procedure Calls als Far Calls implementieren, wohl viel schneller als mit page dir switch.

Wie du schon selber festgestellt hast an einem Beispiel, ist ne Kombination von Paging und Segmenten problematisch. Besonders steigt die Komplexität deutlich an und das dürfte sich auf Dauer auch auf das Tempo auswirken bei wirklich kritischen Operationen.

590

Lowlevel-Coding / RISC CPU

« am: 25. May 2005, 17:48 »

Eigentlich finde ich die Bezeichnung mehr als problematisch, weil schon einige das wohl verwechseln.
Ich kann auch eine 16 Bit RISC CPU machen, in der Weise das diese CPU dann ein reduziertes Instruktionsset hat.

Vielleicht meinst du mehr HP's PA-RISC Architektur? http://www.computerbase.de/lexikon/PA-RISC

Und Apple verbaut ja generell CPUs der PowerPC Reihe, was eine RISC-CPU ist.

591

OS-Design / Wie Windows arbeitet ...

« am: 24. May 2005, 18:03 »

Es soll nun mal nur der Kernel und evtl. noch Win32 sein. Die GUI und eigentlich alles andere was darauf auf baut gehören wohl nicht dazu.

Und ich finde leider keinen brauchbaren Link mehr zum Reverse Engineering  

592

OS-Design / Wie Windows arbeitet ...

« am: 24. May 2005, 00:53 »

In den USA ist Reverse Engineering unter sehr bestimmten Vorraussetzungen sogar legal. Wie das in Deutschland ist, da weiss ich jedoch nichts.

593

OS-Design / Wie Windows arbeitet ...

« am: 23. May 2005, 22:59 »

Das ist aber garantiert illegal ...

594

Offtopic / Kafeemaschiene

« am: 23. May 2005, 17:10 »

Also vi mag ich auch nicht, aber mit vim hab ich mich einigermassen
angefreundet...
i, a, x, dd, o und O kann ich, ist zwar manchmal etwas kompliziert aber
reicht fuer den Notfall aus. Und dann noch :w[q] und :q[!]...

vi auf ner Kaffeemaschine wär schon cool irgendwie. Andererseits aber
auch arg überflüssig. Was meinst du mit "nicht vernünftig rankommen"?

Svenska

Tja, vielleicht hat gvim ja ne Mausunterstütung, vi kann z.b. Splitscreen usw. aber suchen und ersetzen, kopieren und einfügen ohne Maus bleiben bei jedem Editor ne Katastrophe. Und reguläre Ausdrücke ... lohnen sich meiner Meinung nach nur in Skripten, in der Zeit wo sich einer nen Ausdruck überlegt  und fertig getestet hat, hab ich schon lange die Sachen per Hand mit  "primitiveren" Mitteln gemacht.

Bei der Kaffeemaschine wäre das genauso. Mit unserem Vollautomaten der nicht per telnet und vi über rs232 konfiguriert werden muss hab ich schon lange genausoguten Kaffee wie jemand der erst da durch müsste.

Und die tolle Konfigurationsmöglichkeiten - 99% der Konfigurationsmöglichkeiten bei vielen Dingen in der Unixwelt könnte man sich auch sparen, wenn es einfach von anfang funktionieren würde!
Die meisten taugen nur um Schrott zu erreichen.

Aber das ist meine Meinung. Den absoluten Knüller habe ich bei Squid gefunden, wo man aktivieren beim Kompilieren wohl aktivieren kann das Squid für bestimmt 1% mehr Tempo Cookies so falsch behandelt das man kein Forum mehr richtig benutzen kann - na danke, wer hat das überhaupt eingebaut? Hab Wochen damit verbracht zu gucken warum das nicht läuft, um zu sehen das das Binary auf der SuSe CD schon fehlerhaft war.

Sowas meine ich mit "nicht richtig rankommen".

595

OS-Design / Kernel an virtuelle Adresse laden

« am: 23. May 2005, 17:02 »

GRUB aktiviert Paging nicht, d.h. solange du nicht mehr als 3GB RAM hast, wirst du deinen Kernel wohl nicht an per GRUB an 0xC0000000 laden können!

596

OS-Design / Kernel an virtuelle Adresse laden

« am: 23. May 2005, 02:20 »

Genau. Den Wert den man da dann absolut auf den Stack gelegt bekommt, der stimmt ja auch!

597

Offtopic / Kafeemaschiene

« am: 22. May 2005, 16:35 »

Ich sehs eher anders: Wohin führt uns die Elektronisierung von ALLEM? Es gibt doch einfach Dinge, die sind schön wie sie sind und die sollten nicht von der Technik versaut werden.

Hoffentlich nicht zu vi auf der Kaffeemaschine. Ich nehm das Teil nicht mal unter unix als Texteditor. Was der alles kann ist zwar ganz toll, aber wenn man nicht vernünftig drankommt, nützt es einem halt gar nichts, wie bei dieser Kaffeemaschine

598

OS-Design / Kernel an virtuelle Adresse laden

« am: 22. May 2005, 16:32 »

Generell kann man zumindestens beim GCC C-Code ohne globalen Variablen nehmen. Der ist PIC (Position Independant Code).

599

Lowlevel-Coding / C++ ifstream <- ofstream

« am: 19. May 2005, 17:26 »

Da du ja scheinbar eigene Klasse gebastelt hast, wäre es wohl interressant welche Methode du benutzt um auf die Dateien zuzugreifen. fopen, open, was anderes?

600

Lowlevel-Coding / Ohne Änderung funzt Kernel auf einmal nich mehr!

« am: 16. May 2005, 15:45 »

Ja, stimmt, GDTR ist etwas falsch, ich meine den Deskriptor zum Laden der GDT, den du an LGDT übergibts.