Thema: Logisim CPU

[Jidder]

Meine Posts hier sind alles nur meine persönliche Ansicht. Beim Design von CPUs/Betriebssystemen geht man immer Kompromisse ein, mit denen nicht jeder einverstanden ist. Meine einzige absolute Aussage ist, dass alle absoluten Aussagen falsch sind.


Meine Grundannahme ist, dass jedes System, bei dem Stackschutz relevant ist, Virtual Memory beherrscht. Ansonsten ist kann man da nicht viel mit Sicherheit argumentieren und die Erkennung von Fehlern in ausgelieferten Programmen rechtfertigt keine aufwändigen CPU-Features. Guard Pages fangen Stack Overflows ab, wenn der Stack Pointer höchstens ein paar Kilobytes¹⁾ über das Ende hinausgeht. Die Frage ist also, wieviel Aufwand man treiben will, um Stack Overflows zu erkennen, bei denen der Stack Pointer größere Sprünge macht.

Mir fallen nur zwei Ursachen ein: Wenn ein Programmierer versucht sehr große, dünnbesetzte Objekte auf dem Stack anzulegen, oder ein Angriff durch Schadsoftware. Den ersten Fall argumentiere wie eben auch weg: Der Programmierer braucht kein aufwändiges CPU-Feature, um seinen Fehler zu erkennen. Den zweiten Fall kann man nur wegargumentieren, wenn man entweder andere Sicherheitslücken vorschiebt (also den Overflow als Folgefehler deklariert) oder aber wie ich behauptet, dass man das erstmal einen erfolgreichen Angriff durch einen Stack Overflow, der nicht von Guard Pages abgefangen wird, hinkriegen muss. Das Ziel eines solchen Angriffs ist ja etwas außerhalb des Stacks zu überschreiben (andere Angriffe erkennt ein Overflowschutz nicht). Sowas kann man auch versuchen zu verhindern, indem man Stack, Heap, Programm, Shared Librarys an zufälligen Adressen im Speicher platziert (ALSR.) Damit kann man meistens die Erfolgswahrscheinlichkeit von Angriffen reduzieren. Das ist genauso wie Guard Pages kein 100%iger Schutz, aber (vermutlich) einfacher umzusetzen als die Alternativen (Extra-Bit für Adressen, Segmentierung).

_{1) Wenn man einen 64-Bit-Adressraum hat, dann ist gegen Guard Pages, die ein paar Mega- oder Gigabyte überspannen, auch nichts einzuwenden.}

[Tufelix]

Mhh stimmt software würde für den stackschutz völlig ausreichen und wäre mir zudem lieber wie hardware. Aber naja die software braucht rechenleistung und da dachte ich mir das vielleicht durch so ne hardware stack-überlaufschutz meine CPU ein wenig schneller wird  . Naja ich hab ein wenig nachgedacht und weiß jetzt das des ne blöde idee war . Ich glaub ich sollte erstmal schauen das meine CPU überhaupt funkioniert bevor ich an rechenleistung denke und die rechenleichtung mit ner hardware stacksicherung zu erhöhen ist glaub auch nicht so ne tolle idee.

[Svenska]

stimmt software würde für den stackschutz völlig ausreichen

Kann sie nicht. Auch der Einsatz von Guard Pages basiert auf Hardwarefähigkeiten (nämlich Page Faults und "schreiben in nur lesbare Pages").

[Tufelix]

Mhh dann hab ich wohl was falsch verstanden... ich werd dann in meiner cpu zusätzlich eine mmu einbauen die dann paging unterstützt

[Svenska]

Hallo,

du kannst die MMU auch weglassen und einfach mit physischen Adressen arbeiten. Sie ist für Betriebssysteme nicht unbedingt erforderlich (siehe uClinux, MINIX/68k und allgemein ältere Unixe).

Bis 12/16 MHz Taktfrequenz kannst du gewöhnliche SIMM-Module (8 Bit, 30 Pin, 80/60 ns) einsetzen, die du billig bei eBay oder auf dem Flohmarkt schießen kannst. (Für SD- und DDR-Speicher solltest du Hochfrequenzerfahrung haben, die sind vom Timing her deutlich kritischer.) Bei den Geschwindigkeiten brauchst du auch keinen Cache, der die Sache nur unnötig verkompliziert.

Ohne Cache kannst du eine MMU später problemlos nachrüsten, die sitzt dann einfach zwischen CPU und RAM, hat ein bisschen eigenen Speicher (SRAM) für die Tabellen und wird von der CPU wie jede andere Hardware auch angesprochen. Wichtig ist aber, dass deine CPU einen Speicherbusfehler akzeptieren kann.

Die Motorola 68010/68020 konnten mit externen MMUs (68451 und 68851) betrieben werden.

Gruß,
Svenska

[Tufelix]

du kannst die MMU auch weglassen und einfach mit physischen Adressen arbeiten. Sie ist für Betriebssysteme nicht unbedingt erforderlich (siehe uClinux, MINIX/68k und allgemein ältere Unixe).

Mhh ok, wie mache ich das dann aber mit den guard pages ?

Bis 12/16 MHz Taktfrequenz kannst du gewöhnliche SIMM-Module (8 Bit, 30 Pin, 80/60 ns) einsetzen, die du billig bei eBay oder auf dem Flohmarkt schießen kannst. (Für SD- und DDR-Speicher solltest du Hochfrequenzerfahrung haben, die sind vom Timing her deutlich kritischer.) Bei den Geschwindigkeiten brauchst du auch keinen Cache, der die Sache nur unnötig verkompliziert.

Naja ich will eigentlich zunächst die CPU in logisim zuende bauen bevor ich sie dann in hardware verwirkliche.
 

[Svenska]

Garnicht. Ohne MMU/MPU gibt es keinen Speicherschutz.

Wobei du die Guard Pages trotzdem einbauen kannst und dann z.B. nur beim Taskwechsel vom Scheduler prüfen lässt, ob die überschrieben wurden oder nicht. Kostet halt etwas mehr RAM in der Implementation, ist langsamer und schützt nicht so gut - ist aber trotzdem besser als nichts.

Naja ich will eigentlich zunächst die CPU in logisim zuende bauen bevor ich sie dann in hardware verwirkliche.

Ist ein Argument. Allerdings solltest du dir trotzdem überlegen, was du überhaupt verwirklichen kannst und was eher nicht.

Gruß,
Svenska

[Tufelix]

Garnicht. Ohne MMU/MPU gibt es keinen Speicherschutz.

Naja wollt schon immer ne MMU in logisim bauen. Wie werden eigentlich die tabellen von der mmu beschrieben?

[Svenska]

Denk dir was aus, du bist CPU-Designer.

[Tufelix]

Nun ich hab mir folgenes ausgedacht, die tabellen sind direkt am bus angeschlossen. Auserdem gibts noch zusätzlich 9 "spezial-adressen" die auch am Bus angeschlossen sind. 8 "permission-adressen" und 1. "controll-adresse". Sowohl auf die tabellen als auch auf die spezial-adressen kann man nur zugreifen wenn das erste bit der "controll-adresse" 0 ist. Der bit wir immer nur  Beim einschalten oder wenn sich im programm-counter der CPU ,sich die selbe adresse befindet wie in einem der 8 "permission-adressen" auf 0 gesetzt.Nun was hält ihr von der Idee, bzw hat jemand fragen ?

[Svenska]

Ich verstehe deinen Post nicht wirklich.

Du willst also acht Adressen im Speicher haben, die die MMU verändern dürfen und sonst nichts? Dürfte funktionieren, aber verkompliziert unter Umständen das Betriebssystem (eine Schleife, um z.B. die Tabellen zu leeren, dürfte schon mehr als acht Byte brauchen - und du wirst vermutlich auch an mehreren Stellen im VMM die MMU verändern wollen).

[Tufelix]

Naja eigentlich hab ich mir das anders gedacht...Das Betriebssystem oder eine anwendung darf auf alle adressen der tabelle und den "spezial-adressen zugreifen, Wenn die Tabellen und die Spezial-adressen nicht durch den ersten bit der "controll-adresse" gesperrt sind.... Die Spezial-adressen sind eigentlich nur da um die Tabellen vor unbefugte zugriffe zu schützen... In den 8 "permissions-adressen" stehen dann z.b die Start-adressen der Funktionen die auf die Tabellen zugreifen dürfen...

[Svenska]

Adressen haben normalerweise, im Gegensatz zu Daten, die sehr angenehme Eigenschaft, konstant zu bleiben. Das heißt, deine "controll-adresse" (da ist ein L zuviel, und Bit ist sächlich, wenn es nix mit Bohrmaschinen zu tun hat ) sollte eine Konstante sein. Sonst greift ein Programm einfach auf die Adresse mit invertiertem Erlaubnisbit zu und freut sich.

Deine Permissions-Adressen zeigen auf ein einzelnes CPU-Wort. Wenn du den Zugriff auf einzelne Funktionen beschränken willst, muss da mindestens noch eine Größenangabe dazu, sonst wird das nix.

Vermutlich solltest du einfach eine Unterscheidung zwischen "privilegierten Befehlen" (Kernel-Mode) und normalen Befehlen (User-Mode) einbauen und die MMU-Zugriffe nur im Kernel-Mode zulassen. Es gibt ja noch andere Befehle, die man Anwendungen verbieten will. Wenn du einen speziellen I/O-Bus hast (der dann privilegiert ist), kannst du die MMU auch über diesen steuern.

[Tufelix]

Adressen haben normalerweise, im Gegensatz zu Daten, die sehr angenehme Eigenschaft, konstant zu bleiben. Das heißt, deine "controll-adresse" (da ist ein L zuviel, und Bit ist sächlich, wenn es nix mit Bohrmaschinen zu tun hat ) sollte eine Konstante sein. Sonst greift ein Programm einfach auf die Adresse mit invertiertem Erlaubnisbit zu und freut sich.

Naja mit adresse hab ich eigentlich eine adresse im Bus-system gemeint konstant sollen die eigentlich nicht sein.

Deine Permissions-Adressen zeigen auf ein einzelnes CPU-Wort. Wenn du den Zugriff auf einzelne Funktionen beschränken willst, muss da mindestens noch eine Größenangabe dazu, sonst wird das nix.

Mhh naja auf einzelne Funktionen will ich mich eigentlich nicht beschränken... Die jeweiligen funktionen deren Start-adresse in den "Permission-adressen" stehen öffnen eher Die Tabellen und den "spezial-adressen" für weiter zugriffe.(sozusagen den Kernel-Mode) Wenn dann alle zugriffe auf die mmu und den "spezial-adressen gemacht wurde, setzt man als letztes den ersten bit der "controll-adresse" manuell wieder auf 0.(und wechselt somit wieder dann in den user-mode) So hatte ich mir das eigentlich vorgestellt...

[Svenska]

Ich verstehe nicht, was du da eigentlich vor hast. Benutze bitte Worte, die ich kenne und/oder einordnen kann.

[Tufelix]

Mhh nun gut... ich versuchs mal so zu fromulieren: Nun neben den Tabellen der MMU gibts noch 9 weitere speicher-plätze ("Spezial-adressen,8 -Permissions-adressen & 1 Control adresse") . Sowohl die Tabellen als auch die Speicher-pläzte kann man nur zugreifen wenn der erste bit der Control adresse auf 1 gesetzt ist ansonsten wird beim versuch auf die tabellen und den spezial-speicher-plätze zuzugeifen ein interrupt ausgelöst. Wenn der erste bit der "control-adresse" 0 ist, lässt sich logischerweiße nicht mehr mit Befehlen auf die Tabellen und den Speicher-plätze zugreifen bzw die "controll-adresse" wieder auf 1 setzen um die tabellen und den spezial-speicher-plätze zu entsperren. Nun dammit man das trotzdem entsperren kann , gibts jetzt die 8 "permissions-adressen" . In denen stehen ihrgentwelche adressen(z.b die startadresse einer funktion), diese werden die ganze zeit mit der adresse in dem programm-counter verglichen. Und wenn dann ein inhalt einer "permissions-adresse" mit dem inhalt der Programm-counter übereinstimmt wird automatisch der erste bit der "controll-adresse" auf 1 gestetzt, ohne das das programm davon ihrgentwas mitbekommt  .
Allle weiteren speicher-zugriffe und befehle können dann auf die Tabellen der MMU zugreifen ohne das ihrgent ein interrrupt ausgelößt wird. Fals dann Die Tabellen und die "spezial-speicher-plätze" wieder gesperrt werden soll muss man manuel das erste bit der "controll-adresse" wieder auf 0 setzten. Un normalerwieße ist das erste bit beim einschalten immer auf 1

[Svenska]

Hallo,

die sehr schlechte Rechtschreibung und Fließtext machen das nicht unbedingt lesbarer... achte demnächst darauf. Laut Duden ist es übrigens immernoch "das" Bit, aber egal.

So, wie ich das verstehe, ist deine "Control Adresse" keine Adresse, sondern nur eine einzelne (zusätzliche) Steuerleitung auf dem Bus, wo die anderen Bits keine Bedeutung haben. Die "Permissions Adressen" sind dann einfach Register innerhalb der MMU.

Die Idee, die MMU "im Vorbeigehen" zu entsperren, finde ich nicht gut. Aktionen sollten nicht "einfach so" ausgelöst werden, sondern immer eine konkrete, beeinflussbare Ursache haben.

Der Übergang von User- in Kernel-Mode sollte nur durch bestimmte Befehle (Interrupts, Syscall) möglich sein, sonst kannst du dir die Unterscheidung gleich sparen. Außerdem sollten bestimmte Befehle im User-Mode verboten sein.

Gruß,
Svenska

[streetrunner]

Ich mache mir auch Sorgen, dass ein Programmierer nach dem Zugriff vergessen könnte das erste Bit deiner 'Control-Adresse' auf 0 zu setzten. Dann würde nämlich jedem Task deine MMU offen stehen.

Gruß,
Streetrunner

[Tufelix]

Hallo,

die sehr schlechte Rechtschreibung und Fließtext machen das nicht unbedingt lesbarer...

Naja ist relativ

So, wie ich das verstehe, ist deine "Control Adresse" keine Adresse, sondern nur eine einzelne (zusätzliche) Steuerleitung auf dem Bus, wo die anderen Bits keine Bedeutung haben. Die "Permissions Adressen" sind dann einfach Register innerhalb der MMU.

Das ist eigentlich auch ein register bei dem bis jetzt nur DAS erste Bit genutzt wird.( Für die restlichen Bits hab ich noch keine Verwendung  ).

Die Idee, die MMU "im Vorbeigehen" zu entsperren, finde ich nicht gut. Aktionen sollten nicht "einfach so" ausgelöst werden, sondern immer eine konkrete, beeinflussbare Ursache haben.

Na dann bau ich ein bestätigungs-Befehl ein. DAS erste Bit des "Control-Registers" setzt sich dann nur auf 1 wenn sich ein "Permissions-Register" mit dem CP übereinstimmt und zusätzlich an der Adresse auf die der CP zeigt ein solcher Befehl ist.

Der Übergang von User- in Kernel-Mode sollte nur durch bestimmte Befehle (Interrupts, Syscall) möglich sein, sonst kannst du dir die Unterscheidung gleich sparen. Außerdem sollten bestimmte Befehle im User-Mode verboten sein.

Naja ich hab bei mir kein software-interrupts eingebaut, mit interrupts in den kernel-Mode zu kommen wird daher eher schwierig . Und wieso sollten Befehle verboten sein ?

ch mache mir auch Sorgen, dass ein Programmierer nach dem Zugriff vergessen könnte das erste Bit deiner 'Control-Adresse' auf 0 zu setzten. Dann würde nämlich jedem Task deine MMU offen stehen.

Mhh stimmt, ich überleg mir da noch was...

[streetrunner]

Na dann bau ich ein bestätigungs-Befehl ein. DAS erste Bit des "Control-Registers" setzt sich dann nur auf 1 wenn sich ein "Permissions-Register" mit dem CP übereinstimmt und zusätzlich an der Adresse auf die der CP zeigt ein solcher Befehl ist.

Das verkompliziert die Sache nur noch, da man damit auf bestimmten Adressen auch noch bestimmte Befehle haben muss.

Und wieso sollten Befehle verboten sein ?

Darum. Und weil sonst jeden beliebige Programm z.B. an den I/O-Ports (sofern vorhanden) rumspielen kann. Je nach dem was da dran hängt (bei x86 z.B. der PIT) könnte das Programm dann das komplette System einfrieren bzw. sich unendlich viel Rechenzeit verschaffen.

Gruß,
Streetrunner