Warning: fopen(111data/log202003290508.log): failed to open stream: No space left on device in /home/pde321/public_html/header.php on line 107

Warning: flock() expects parameter 1 to be resource, boolean given in /home/pde321/public_html/header.php on line 108

Warning: fclose() expects parameter 1 to be resource, boolean given in /home/pde321/public_html/header.php on line 113
Bereitstellen eines erweiterten Speicherschutzes - Dokument DE102006015106A1
 
PatentDe  


Dokumentenidentifikation DE102006015106A1 09.11.2006
Titel Bereitstellen eines erweiterten Speicherschutzes
Anmelder Intel Corp., Santa Clara, Calif., US
Erfinder McKeen, Francis, Portland, Oreg., US;
Cheng, Antonio, Portland, Oreg., US
Vertreter BOEHMERT & BOEHMERT, 28209 Bremen
DE-Anmeldedatum 31.03.2006
DE-Aktenzeichen 102006015106
Offenlegungstag 09.11.2006
Veröffentlichungstag im Patentblatt 09.11.2006
IPC-Hauptklasse G06F 12/14(2006.01)A, F, I, 20060718, B, H, DE
Zusammenfassung In einer Ausführungsform sorgt die vorliegende Erfindung für einen erweiterten Speicherschutz für den Speicher eines Systems. Die Ausführungsform umfasst ein Verfahren zum Verknüpfen eines Schutzindikators eines Schutzdatensatzes, der außerhalb des Datenraums einer Anwendung bewahrt wird, mit einem Speicherort und, auf der Grundlage des Status des Schutzindikators, ein Verhindern des Zugriffs auf den Speicherort. Auf diese Weise wird für einen sichereren Betrieb gesorgt, da ein Schadcode oder andere Malware darin gehindert wird, auf geschützte Speicherorte zuzugreifen. Andere Ausführungsformen werden beschrieben und beansprucht.

Beschreibung[de]

Die Computerindustrie hat während der letzten Jahre an zahlreichen Sicherheitsschwachstellen gelitten, und die Zahl der Schwachstellen steigt weiter an. Weitere Sicherheitsschwachstellen sind zu Angriffen genutzt worden, die die Unversehrtheit des angegriffenen Computers gefährden. Die Grundursache für viele dieser Angriffe sind Programmierfehler, die beim Erzeugen oder Ändern von Code gemacht werden.

Es sind mehrere Lösungsversuche unternommen worden. Kurse über das Schreiben von sicherem Code sind von vielen Gruppen durchgeführt worden. Eine verwaltete Laufzeitumgebung (Managed Run Time Environment, MRTE) ist wirksam, wo sie verwendet wird, erfasst aber nicht den ganzen Programmierraum. Keine dieser Bemühungen hat es geschafft, die Abwärtsspirale der Schwachstellen, Angriffe und Patches umzudrehen. Durch das Verringern der Zahl der Programmierfehler könnte man die Zahl der Sicherheitsschwachstellen verringern und die Systemintegrität verbessern.

Eine häufige Schwachstelle ist ein Angriff bei einem Pufferüberlauf. Ein Beispiel für einen solchen Angriff tritt auf, wenn ein Schadcode eine Rücksprungadresse einer Funktion, die im Stack gespeichert ist, überschreibt. Bei der Rückkehr von der Funktion wird eine modifizierte Rücksprungadresse in das Befehlszeigerregister (erweitertes Befehlszählerregister (EIP)) geschoben. Diese geänderte Rücksprungadresse kann die Ausführung eines Schadcode und/oder einen Stapelspeicherausführungsfehler verursachen. Solch ein Angriff wird normalerweise durch mangelhafte Programmierpraktiken, wie zum Beispiel unkontrollierte Pufferspeicherübertragungen, ermöglicht. Im Gegensatz dazu bildet ein gut strukturiertes Programm Speicher in strukturierte Abschnitte ab, einschließlich eines Textteils zur Aufnahme von Programmcode, einem Datensegment zur Speicherung von initialisierten und nicht initialisierten globalen Daten und einem Abschnitt, den sich Kellerspeicher (Stack) und Heap teilen. Der Kellerspeicher (Stack) kann zum Speichern von Funktionsaufrufen nach Argumenten, lokalen Variablen und Werten von ausgewählten Registern, wie zum Beispiel dem EIP-Register, verwendet werden. Der Heap enthält dynamische Variablen. Mangelhafte Programmierpraktiken können bewirken, dass diese Segmente überschrieben werden.

Es gibt andere Stellen mit unkontrollierten Puffern. Ein Beispiel für eine solche Stelle ist ein Pufferüberlauf in den Heapspeicher. Der Heapspeicher ist ein Speicher, der aus einem gemeinsamen Pool zugewiesen und von einem Programm verwendet wird, um Variablen und andere Laufzeitdaten zu speichern.

Es besteht daher ein Bedarf, für mehr Schutz vor Sicherheitsschwachstellen zu sorgen.

Kurze Beschreibung der Zeichnungen

1 ist ein Flußdiagramm eines Verfahrens zum Kontrollieren von Speicherzugriffen gemäß einer Ausführungsform der vorliegenden Erfindung.

2 ist ein Blockdiagramm eines Puffers, der gemäß einer Ausführungsform der vorliegenden Erfindung verwendet werden kann.

3 ist ein Blockdiagramm verschiedener Pipeline-Strukturen gemäß einer Ausführungsform der vorliegenden Erfindung.

4 ist ein Flußdiagramm eines Verfahrens gemäß einer Ausführungsform der vorliegenden Erfindung.

5 ist ein Flußdiagramm eines Verfahrens gemäß einer weiteren Ausführungsform der vorliegenden Erfindung.

6 ist ein Blockdiagramm eines Systems gemäß einer Ausführungsform der vorliegenden Erfindung.

Ausführliche Beschreibung

Ausführungsformen der vorliegenden Erfindung stellen einen Mechanismus zum Kennzeichnen von Speicherorten als nicht zugänglich bereit. Wenn ein Programm versucht, auf einen geschützten Speicherort zuzugreifen, kann der Mechanismus eine Speicherzugriffsverletzung signalisieren. Das heißt, Speicherschutz gemäß einer Ausführungsform der vorliegenden Erfindung kann einen Anhaltepunkt fester Größe bereitstellen, der zu einem Speicherort gehört. Orte können durch die Kennzeichnung des Ortes als für bestimmte Arten von Operationen unzugänglich geschützt werden. Auf diese Weise laufen sicherere Operationen ab.

In verschiedenen Ausführungsformen sind die Attributbits so festgelegt, dass sie Schutz für Speicherorte bieten. Diese Bits zeigen an, ob für Lese- oder Schreiboperationen Zugriff gewährt werden kann. Diese Attribute können für einen erweiterten Speicherschutz (EMP) durch die Bereitstellung von Zugriffskontrolle über eine Variable sorgen, die in einigen Ausführungsformen als 32 Bit Speicher definiert sein kann. Ein Programm, das von einem EMP-freigegebenen Compiler erzeugt wird, setzt die Attribute, um für das richtige Niveau an Unterstützung zu sorgen. Ältere Programme können nahtlos arbeiten, indem sie keins dieser Attributbits setzen.

Es versteht sich, dass die Eigenschaften des Speicherschutzes architekturspezifisch sein können. Die Wahlmöglichkeiten können zum Beispiel die Art des Zugriffsschutzes, der bereitgestellt wird, umfassen: Leseschutz, Schreibschutz, Ausführungsschutz oder eine gemischte Auswahl von allen Dreien; der Adressenbereich, der von jedem Attributbit erfasst wird, die Fähigkeit, sich mit anderen Attributen zu überdecken oder zu überlappen; der Betriebsadreßraum: virtuell oder physisch, und ein Schutzlaufprozeß zum Umcodieren einer Adresse auf den entsprechenden Schutzwert.

In einer Ausführungsform werden vier Zustände auf der Basis von Lese-/Schreibbeschränkungen definiert, von denen jede durch ein Bit ausgedrückt wird. Diese Zustände entsprechen einem Pufferspeicherverwendungsmodell, das vier Zustände hat, nämlich nicht zugewiesen, nicht initialisiert, initialisiert und gesperrt. Dieses Modell kann auf die folgenden Zustände abgebildet werden:

nicht_lesen_nicht_schreiben; nicht_lesen_schreiben_ok; lesen_ok_schreiben_ok und lesen_ok_nicht_schreiben. Als Beispiel kann der Zustand nicht_lesen_nicht_schreiben durch Setzen der Lese-und Schreibschutzbits definiert werden. Daher kann eine Ausnahme erzeugt werden, wenn ein Lesen oder Schreiben an einem Ort auftritt, dessen Schutzbits gesetzt sind.

EMP-Informationen können im Hauptspeicher aufrechterhalten werden und können direkt jedem adressierbaren Speicherelement in der Maschine entsprechen. Das heißt, jedes adressierbare Speicherelement kann einen Satz von EMP-Attributen haben, die damit verbunden sind. Die EMP-Informationen können als Attributseiten im Speicher verwaltet werden. Diese Seiten sind im virtuellen Adreßraum des Programms nicht zugänglich, sondern können statt dessen durch einen speziellen Befehl erreicht werden. Die Attributbits könne bei jedem Speicherzugriff kontrolliert werden. Wenn die Bits einen Ort mit begrenztem Zugriff anzeigen, wird eine Speicherzugriffsverletzung erzeugt.

In virtuellen Speicherseitenverwaltungssystemen erzeugen Programme Verweise in einem logischen Adreßraum. Die logische Adresse wird dann über die Segmentierung in eine lineare oder virtuelle Adresse umgeformt. Zum Schluß übersetzt der Seitenverwaltungsmechanismus eines Prozessors die virtuelle Adresse in eine physische Adresse, die dem Ort entspricht, an dem die Daten im physischen Speicher gespeichert sind. Wenn ein virtuelles adressenbasiertes EMP implementiert und aktiviert wird, erzeugt der Prozessor eine zusätzliche Umcodierung von der virtuellen Adresse in einen EMP-Beschränkungsdatensatz, der in einem separaten physischen EMP-Adreßraum gespeichert wird.

In 1 wird nun ein Flußdiagramm eines Verfahrens zur Kontrolle der Speicherzugriffe gemäß einer Ausführungsform der vorliegenden Erfindung gezeigt. Wie in 1 gezeigt, wird eine Datenzugriffsanforderung 10 in einem Prozessor aufgenommen. Die Datenzugriffsanforderung 10 umfasst eine virtuelle Adresse, eine Zugriffsgröße und eine Art der Operation (z.B. eine Lese(R)- oder eine Schreib(W)-Operation). Die virtuellen Adreßinformationen werden einem Seitenübersetzungsmechanismus 20 und einem EMP-Übersetzungsmechanismus 30 zugeführt. Diese Übersetzungsmechanismen übersetzen die virtuelle Adresseninformationen aus der Datenzugriffsanforderung 10 in einen physischen Adreßraum.

Wie in 1 gezeigt, wird die physische Adresse, die durch den Seitenübersetzungsmechanismus 20 erhalten wird, einem logischen Operator 25 zugeführt, der die physische Adresse mit der Operationsart kombiniert, um so auf Daten in einem physischen Speicher 50 zuzugreifen. Spezieller gesagt, kann auf die gewünschten Daten 65 innerhalb der Datenseite 60 unter Verwendung der physischen Adresse, die erhalten wurde, zugegriffen werden.

Vor der Möglichkeit, auf die gewünschten Daten 65 zuzugreifen, kann jedoch zuerst in Ausführungsformen, in denen EMP aktiviert ist, festgestellt werden, ob auf den Speicherort von Daten 65 zugegriffen werden darf. Zum Beispiel kann eine Lese- oder Schreiboperation verhindert werden, wenn EMP aktiviert ist und der Zugriff auf die gewünschten Daten 65 beschränkt ist.

Das heißt, die virtuellen Adreßinformationen aus der Datenzugriffsanforderung 10 werden dem EMP-Übersetzungsmechanismus 30 zugeführt, wo die virtuelle Adresse in eine physische Adresse umgesetzt wird, die einem EMP- oder Einschränkungsdatensatz 75 (der mit den Daten 65 verbunden ist) entspricht, welcher in einer EMP-Seite 70 (die mit der Datenseite 60 verbunden ist) gespeichert ist. Der EMP-Datensatz 75, auf den zugegriffen wird, wird an einen EMP-Kontrollmechanismus 40 geliefert, wo festgestellt werden kann, ob der Zugriff auf die angeforderten Daten 65 erlaubt ist. Zum Beispiel können ein oder mehrere Bits des EMP-Datensatzes 75 anzeigen, dass der Zugriff auf die entsprechenden angeforderten Daten 65 nicht erlaubt ist. Wenn solch ein Zugriff nicht erlaubt ist, kann der EMP-Kontrollmechanismus 40 eine EMP-Schutzverletzung (EPV) auf einer Signalleitung 45 erzeugen. Dementsprechend wird der Zugriff auf die Daten 65 verhindert.

Wenn also der EMP-Schreibschutz für eine gegebene virtuelle Adresse gesetzt ist und es einen Datenschreibversuch auf diese Adresse gibt, kann der Prozessor eine EMP-Schutzverletzungs(EPV)-Ablaufunterbrechung erzeugen. Ein EMP-Leseschutz hat auf die Datenlesezugriffe denselben Effekt. Speicherlesevorgänge auf Grund des Abrufens von Befehlen wird in einigen Ausführungsformen eventuell nicht als Datenlesezugriff angesehen. In verschiedenen Ausführungsformen kann ein EMP- Bearbeitungsprogramm für Ablaufunterbrechung verwendet werden, um eine Erholung von der Schutzverletzung in sicherer Weise zu erreichen.

In verschiedenen Ausführungsformen nimmt der Kontrollvorgang von EMP-Beschränkungen nicht das Privilegierungsniveau wahr. Das heißt, wenn ein EMP-Schreibschutz für einen bestimmten Speicherort gesetzt ist, führen alle Schreibversuche auf diesen Ort zu einer EPV-Ablaufunterbrechung, ungeachtet des aktuellen Privilegierungsniveaus des Programms. In diesen Ausführungsformen müssen immer noch alle Seitenbeschränkungen erfüllt werden, damit der Verweis Erfolg haben kann. EMP-Ablaufunterbrechungen treten nicht auf, wenn der Seitenlevelschutz keinen Zugriff auf dem aktuellen Privilegierungsniveau erlaubt.

Ein EMP-Flag kann innerhalb einer Prozessorkontrollstruktur, wie zum Beispiel eines Kontrollregisters (z.B. Kontrollregister 4 (CR4)), enthalten sein. In einigen Ausführungsformen ist die Voreinstellung des EMP-Flags null (gelöscht), was bedeutet, dass es keine EMP-Beschränkungskontrolle für Datenzugriffe gibt. Wenn die EMP-Beschränkungskontrolle global abgeschaltet ist, besteht für den Prozessor keine Notwendigkeit, EMP-Adreßumcodierungen auf die virtuelle Adresse jedes Datenzugriffs auszuführen. Zum Aktivieren der EMP-Beschränkungskontrolle kann das EMP-Flag auf l gesetzt werden.

Der physische EMP-Adreßraum ist für die Softwareprogramme im virtuellen Adreßraum nicht sichtbar. Dementsprechend kann ein Betriebssystem (OS) verhindern, dass die physischen EMP-Adressen durch reguläre Seitenadressierungsmechanismen offengelegt werden. Zum Modifizieren von EMP-Beschränkungsattributen kann ein Softwareprogramm einen Befehl zum Ändern der Speicherattribute verwenden, wie zum Beispiel Beschränkungen zum Verschieben von Speicher (z.B. ein MOVMR-Befehl), der das Speicherattribut (EMP-Beschränkungsdatensatz) in den EMP-Speicher im physischen Speicher verschieben kann.

Die EMP-Schutzverletzung (EPV) kann ihren eigenen Bezeichner (ID) für den Ablaufunterbrechungsvektor haben. Der Prozessor löst eine EPV-Ablaufunterbrechung aus, wenn ein Datenzugriff die EMP-Beschränkungskontrolle nicht besteht. Außerdem kann die EPV-Ablaufunterbrechung auch während eines MOVMR-Befehls ausgelöst werden. Außerdem kann eine EPV als Befehlsausführungsfehler angesehen werden. Die sich daraus ergebende Unterbrechung ist präzise und verhindert die Ausführung des Befehls.

Wenn die EPV-Ablaufunterbrechung ausgelöst wird, stellt sie einen Fehlercode in den aktuellen Kellerspeicher. Der Fehlercode kann eine Reihe von Fehlerstatusbits enthalten. Jedes Bit im Fehlercode kann dazu verwendet werden, eine andere Ursache der EPV-Ablaufunterbrechung anzuzeigen. Wenn eine EPV ausgelöst wird, wird die virtuelle Quellenadresse, die die EMP-Umcodierung oder die Beschränkungskontrolle in Gang gesetzt hat, an einem speziellen Ort gespeichert, zum Beispiel innerhalb eines Kontrollregisters (z.B. CR2).

In verschiedenen Ausführungsformen kann ein solcher EMP-Mechanismus auf verschiedene Weise verwendet werden, die Systemintegrität zu erhöhen. Während einige Ausführungsformen Kellerspeichervariablen und -Parameter sowie Heap-Variablen schützen können, versteht es sich, daß der Geltungsbereich der vorliegenden Erfindung nicht so eingeschränkt ist.

Im folgenden Beispiel wird ein byteweiser Schreibschutz an einem virtuellen Adreßmodell verwendet. In einer solchen Ausführungsform gibt es für jedes Byte von adressierbaren Daten (in einem virtuellen Adreßraum) ein Schreibschutzattributbit, das damit verbunden ist. Wenn dieses Bit gesetzt ist, kann jeder Versuch, auf diesen Ort zu schreiben, eine strukturelle Ablaufunterbrechung verursachen. Für jede virtuelle Adreßseite kann das Betriebssystem (OS) an einem getrennten virtuellen Speicherort einen Schutzdatensatz zuweisen, zum Beispiel einen Vektor einer entsprechenden Größe (z.B. 1 Bit pro Byte). In einer Ausführungsform beschreibt jeder EMP-Schutzdatensatz die Datenzugriffsbeschränkungen für 32 Bit (4 Bytes) von virtuellen Adressen. Mehrere EMP-Schutzdatensätze können verwendet werden, wenn ein Datenzugriff mehrere 4-Byte-Dateneinheiten erfasst. Der Ort dieses Vektors im physischen Speicher kann durch einen Schutzlaufmechanismus bereitgestellt werden. In einer Ausführungsform kann dieser Mechanismus einem Seitenlauf ähnlich sein, wobei der letzte Eintrag auf die Vektorbasisadresse statt auf die physische Seite zeigt. In anderen Ausführungsformen sind verschiedene Umcodierungsschemata, einschließlich einer Hash-Tabelle mit einem Software-Assist, möglich.

Während hierin der Schutz als byteweiser Schreibschutz beschrieben wird, können in anderen Ausführungsformen Leseschutz und andere Schutzgrade implementiert werden. Beschränkungsdatensätze können hierin ebenfalls als Vektoren bezeichnet werden. Ein Vektor kann vor einer Änderung durch reguläre Speicheroperationen geschützt werden. Beispielsweise kann ein Spezialbefehl von Nutzeranwendungen verwendet werden, um ein spezielles Bit in einem Vektor zu ändern. Der Befehl kann als „Schutz-Setz/Löschbefehl" bezeichnet werden. Bei gegebener virtueller Adresse kann mit den speziellen Setz- oder Löschbefehl das geeignete Attribut geändert werden, ohne eine Ablaufunterbrechung zu verursachen.

Der Kellerspeicher kann vor Pufferüberlauf und anderen gefährlichen Überschreibvorgängen durch das Kennzeichnen von Speicherorten, wie zum Beispiel der Rücksprungadresse, als unzugänglich geschützt werden. Beispielsweise kann ein Compiler Code beim Eintritt in eine Routine ausgeben, um die Rücksprungadresse als unzugänglich zu kennzeichnen. Sollte die Routine einen Schreibvorgang an den zugewiesenen Variablen vorbei und in die Rücksprungadresse versuchen, dann wird ein Fehler unter Verwendung eines EMP-Mechanismus festgestellt. Der Fehler kann als Speicherzugriffsverletzung gemeldet werden. Im Ergebnis dessen tritt kein Schreibvorgang auf, und ein Fehlerbearbeitungsprogramm kann eine geeignete Weise festlegen, wie der Fehler zu lösen ist, was sich von Pufferüberlauffeststellungsprogrammen unterscheidet, die einen Überlauf erst feststellen, nachdem der Puffer bereits verfälscht wurde.

Der Heapspeicher kann auf zweierlei Weise geschützt werden. Nicht zugewiesener und freigegebener Speicher kann als nicht zugewiesener Speicher gekennzeichnet werden. Jeder Verweis auf diese Orte erzeugt einen Fehler. Ferner kann der Heap-Manager wichtige Zeiger und interne Variablen als unzugänglich kennzeichnen.

Zum Beispiel wird unter Verweis auf 2 nun ein Blockdiagramm eines Puffers gezeigt, der gemäß einer Ausführungsform der vorliegenden Erfindung verwendet werden kann. Der Puffer kann in einem Daten-Heap oder einer Kellerspeicherstruktur liegen und kann, wie in 2 gezeigt, mehrere Datenblöcke aufweisen, einschließlich eines ersten Datenblocks 115, der x Byte lang ist, und eines zweiten Datenblocks 125, der y Byte lang ist. Die beiden Blöcke 115 und 125 haben jeweils einen Blockkopf, der damit verbunden ist. Speziell weist Block 115 einen Kopf 110 auf, und Block 125 weist einen Kopf 120 auf. Außerdem ist ein Kopf 105 für einen Nullbyteblock vorhanden.

Bei einem Pufferüberlaufangriff überschreibt Schadcode den Puffer von einem zugewiesenen Block zu einem nächsten Block und ändert die Daten darin. Um einen Pufferüberlauf zu vermeiden, können die Ausführungsformen der vorliegenden Erfindung die Blockköpfe jedes Pufferblocks unter Verwendung von Schutzdatensätzen schützen. Zum Beispiel können die Köpfe 105, 110 und 120 von 2 jeweils damit verbundene Schutzindikatoren haben, die so gesetzt sind, dass sie anzeigen, dass diese Speicherorte für Schreib- und/oder Leseoperationen unzugänglich sind. Diese Schutzindikatoren können in einem oder mehreren Schutzvektoren oder -datensätzen gespeichert sein, zum Beispiel EMP-Datensatz 75 von 1.

Um die Leistungseinbuße auf Grund von zusätzlichen Speicherzugriffen für die Schutzinformationen zu minimieren, kann ein Schutz-Cache und ein Schutzübersetzungspuffer (PTLB) in eine Speicher-Pipeline aufgenommen werden. Mit Verweis auf 3 wird ein Blockdiagramm verschiedener Pipelinestrukturen gemäß einer Ausführungsform der vorliegenden Erfindung gezeigt. Wie in 3 gezeigt, kann ein Mikroprozessor 200 verschiedene Prozessor-Ressourcen aufweisen, die die Speicherung und die Kontrolle von Schutzdaten ermöglichen.

In der Ausführungsform von 3 kann Prozessor 200 einen Schutz-Cache 210 aufweisen, der zum Speichern einer Teilmenge der EMP-Datensätze, welche sich in physischem Speicher befinden, verwendet wird. Auf diese Weise können die meisten Schutzdatensätze, auf die kurz vorher oder häufig zugegriffen wird, schnell erhalten werden, ohne Verzögerungen beim Erhalten der Informationen aus einer Speicherhierarchie zu verursachen.

Wie ferner in 3 gezeigt wird, ist ein Datenübersetzungspuffer (DTLB) 220 vorhanden, in dem Kopien von Datenadreßumcodierungen gespeichert werden. Analog dazu ist ein PTLB 230 vorhanden, der Umcodierungen von einer virtuellen Adresse auf eine physische Adresse von Schutzdatensätzen, auf die kurz vorher zugegriffen wurde, speichert. Jede dieser Strukturen 210, 220 und 230 ist angekoppelt, um eine virtuelle Adresse, z.B. entsprechend einer Speicheroperation, aufzunehmen. Ein physischer Speicher 270 ist mit diesen Pipeline-Strukturen verbunden. In verschiedenen Ausführungsformen können die EMP-Strukturen ähnlich den Mikroarchitekturstrukturen für Seitenverwaltungsfunktionen gestaltet sein. In einigen Ausführungsformen kann das Schaltungssystem für EMP und Seitenverwaltung gemeinsam genutzt werden.

Der Schutz-Cache 210 umfasst einen Datenabschnitt, der Cache-Zeilen von Schutzdatensätzen hat. Während die Länge jeder Cache-Zeile implementierungsspezifisch ist, kann die Länge ein Mehrfaches der Datencachezeile betragen, um die Handhabung von geteilten Adressen zu vereinfachen. Statt die Schutzvektoradresse als Suchtag zu verwenden, kann die originale virtuelle Adresse einer Speicheroperation, die in der Pipeline empfangen wurde, zum Zugreifen auf ein Tagfeld von Schutz-Cache 210 verwendet werden. Die Zeilenadresse des Schutzvektor-Caches wird in Form von Addreßkontrolldaten im Cache gespeichert. Bei dieser Struktur kann die Cache-Suchoperation parallel zu DTLB- und PTLB-Suchoperationen auftreten oder sobald die virtuelle Adresse der Speicheranforderungen verfügbar ist.

DTLB 220 wird angekoppelt, um dem Schutzcache 210 eine Adreßseite zusammen mit einem Schutzaktivierungssignal zu liefern. Analog liefert DTLB 220 das Schutzaktivierungssignal an PTLB 230.

Die Ergebnisse von DTLB 220 und PTLB 230 können benutzt werden, um das Ergebnis der Cache-Suchoperation durch Vergleich der Ergebnisse mit den Adreßkontrolldaten zu kennzeichnen. Zusätzlich zum Senden von Adressen an Cache 210 kann entweder DTLB 220 oder PTLB 230 das Cache-Suchergebnis deaktivieren. In solchen Fällen wird das Cache-Ergebnis verworfen, ohne daß sich daraus eine Ausgabe daraus ergibt. Das Suchergebnis kann zum Beispiel bei einem negativen DTLB- oder PTLB-Suchvorgang, Deaktivieren des Schutzsuchvorgangs auf Seitenniveau (DTLB/PTLB) und Deaktivieren des Prozessorzustandsschutzsuchvorgangs deaktiviert werden.

Wenn die virtuelle Adresse, die einer Anforderung entspricht, in PTLB 230 vorhanden ist, wird die physische Adresse des EMP-Datensatzes, zusammen mit einem PTLB-Treffersignal, für den Schutzcache 210 bereitgestellt. Analog zu einem TLB für einen Seitenlauf kann PTLB 230 zum Beschleunigen des Schutzlaufprozesses verwendet werden. Wie ein TLB für einen Seitenlauf, kann PTLB 230 auch implementierungsspezifisch sein. Zum Beispiel kann er ein Einzel- oder Mehrebenen-TLB sein, er kann eine oder mehrere Laufbaumdefinitionen unterstützen und kann auch die Hash-Tabelle mit Software-Assists nutzen.

Ein PTLB-Suchvorgang kann mit der virtuellen Seitenadresse einer ankommenden Speicheroperation beginnen, der parallel zu einem DTLB-Suchvorgang ausgeführt werden kann. Die Datenausgabe von PTLB 230 ist der physische Beginn des Schutzdatensatzes für die entsprechende Seite. Der PTLB sendet diese Adresse und ein Treffer- (oder Aktivierungs-)Signal an den Schutzcache 210. Die PTLB-Ausgabe ist nur bei einem DTLB-Treffer relevant, wenn DTLB 220 den Schutz für diese Seite aktiviert hat. Unter Verwendung der virtuellen Adresse, die zusammen mit den Informationen vom DTLB 220 und PTLB 230 empfangen wurden, kann der Schutzcache 210 feststellen, ob der angeforderte EMP-Datensatz vorhanden ist. Eine einzelne virtuelle Adresse kann also dazu verwendet werden, Umcodierungen für eine physische Adresse für die Speicheranforderung (d.h. Informationen im Speicher) und eine physische Adresse des EMP-Datensatzes, die der Speicheranforderung entspricht, zu erhalten.

Wenn die Cache-Suchausgabe nicht verworfen wird und alle Schutzbits, die der Speicheranforderung entsprechen, in der Struktur gepuffert sind, tritt ein Cache-Treffer auf. Neben dem Melden des Cache-Treffers kann der Schutzcache 210 eine logische „ODER"-Operation an allen Schutzbits ausführen, die von der Speicheranforderungen betroffen sind. Das heißt, der Schutzcache 210 führt zusätzlich zum Puffern der physischen Adreßumcodierungen eine Bitindexierung unter Verwendung einer Bytemaske aus, die auf die Speichergrößeninformationen hindeutet. Wenn der kombinierte Schutz gesetzt ist, kann eine Schreibzugriffsverletzung erzeugt werden (das Signal „Schreibgeschützt" von 3), was zu einer sichtbaren Software-Ablaufunterbrechung, d.h. einem EPV führt. Die kombinierte physische Adresse kann also zum Kontrollieren des Speicherschutzes verwendet werden, der zu einem Speicherort gehört.

Wenn statt dessen ein Treffer auftritt und die angeforderten Daten nicht dem Schutz unterliegen, gibt der Schutzcache 210 ein Berechtigungssignal (das Signal „Schreiben erlaubt" von 3) aus, das anzeigt, dass ein Zugriff erfolgen darf.

Wenn die Cache-Suchausgabe nicht verworfen wird, aber entweder die Speicheradresse nicht im Cachetagfeld ist oder die Kontrolladresse nicht zur DTLB/PTLB-Ausgabe passt, dann tritt ein Cache-Fehlversuch auf. Im Ergebnis dessen kann der Schutzcache 210 eine Fülloperation durch Senden eines Fehlsignals an PTLB 230 zusammen mit notwendigen Adreßinformationen über die Speicheranforderung senden. PTLB 230 kann dann einen Speicherlesevorgang der angeforderten Cache-Zeile im entsprechenden Schutzdatensatz 275 in Speicher 270 in Gang setzen. Die Speicheroperation wird dann wieder auf die Speicher-Pipeline beim Abschluß des Cache-Zeilenfüllens (das auf Zeile 280 erfolgt) zugreifen.

Wenn ein PTLB-Suchvorgang fehlschlägt und der Schutz für die angeforderte Seite aktiviert ist, tritt ein PTLB-Fehlversuch ein. Wenn ein Fehlversuch in PTLB 230 auftritt (d.h. es ist keine Umcodierung auf der physischen Adresse des angeforderten EMP-Satzes 275 vorhanden), wird ein PTLB-Fehlsignal erzeugt und an ein Schutzfehlversuchshandhabungsprogramm (PMH) 240 gesandt. PMH 240 kann ähnlich arbeiten wie ein Seitenfehlversuchshandhabungsprogramm, um einen Schutzseitenlauf zu verursachen, um so die physische Adresse, die dem gewünschten EMP-Datensatz entspricht, zu erhalten. PMH 240 führt einen Schutzlauf mit der originalen Anforderungsadresse aus.

Wie gezeigt, setzt PMH 240 also einen Seitenlauf in Gang, bei dem auf verschiedene Seitentabellen zugegriffen werden kann, um die gewünschte physische Adresse zu erhalten und sie an PTLB 230 zum Speichern zu liefern. In der Ausführungsform, die in 3 gezeigt ist, ist eine dreistufige Seitenadressierungshierarchie vorhanden, einschließlich einer ersten Seitenadressierungsstruktur 252, einer zweiten Seitenadressierungsstruktur 254 und einer dritten Seitenadressierungsstruktur 256. Solche Seitentabellen können einer virtuellen 64-Bit-Adresse entsprechen, einschließlich einer Tabelle des Seitenabbildungsniveaus 4 (PML4), einer Seitenverzeichniszeigertabelle und einem Seitenverzeichnis. Dementsprechend kann PMH 240 einen Eintrag in einer Seitentabelle an PTLB 230 liefern. Dieser kann wiederum, zusammen mit dem Byte-Versatz, der vom Schutzcache 210 bereitgestellt wird, verwendet werden, um auf den gewünschten EMP-Datensatz 275 im physischen Speicher 270 zuzugreifen.

Natürlich hängt die tatsächliche Schutzlaufzustandsmaschine von der strukturellen Auswahl des Schutzlaufalgorithmus ab. Beim Abschluß des Schutzlaufs kann PTLB 230 automatisch eine Cache-Fülloperation für die kritische Cache-Zeile, die für die aktuelle Speicheroperation gewünscht wird, in Gang setzen. Wie oben beschrieben, kann die Speicheroperation nochmals versucht werden, nachdem die Cache-Fülloperation abgeschlossen ist. Dementsprechend kann PMH 240 einen Eintrag innerhalb einer Seitentabelle an PTLB 230 liefern. Dieser Eintrag wiederum kann, zusammen mit dem Byte-Versatz, der vom Schutzcache 210 geliefert wird, dazu verwendet werden, auf den gewünschten EMP-Datensatz 275 im physischen Speicher 270 zuzugreifen.

In einigen Ausführungsformen können PTLB-Einträge entweder durch explizite Befehle oder Kapazitätsersatz ersetzt werden. Während die entsprechende Cache-Zeile nicht ausgeräumt zu werden braucht, weil ein PTLB-Treffer eine Vorbedingung für einen Cache-Treffer ist, kann ein solches Ausräumen die Cache-Effzienz verbessern. Während Cache 210, DTLB 220 und PTLB 230 bei der speziellen Struktur in der Ausführungsform von 3 gezeigt werden, können sie in anderen Ausführungsformen in eine einzige Speicherstruktur integriert werden.

Mit Verweis auf 4 wird ein Flussdigramm eines Verfahrens gemäß einer Ausführungsform der vorliegenden Erfindung gezeigt. Wie in 4 gezeigt, kann Verfahren 300 dazu benutzt werden, für einen Speicherschutz für einen gegebenen Speicherort zu sorgen. Verfahren 300 kann beim Empfang eines festgelegten Schutzbefehls (Kasten 310) beginnen. Solch ein Befehl kann durch einen Compiler ausgegeben werden, um den Schutz von festgelegten Speicherorten, wie zum Beispiel Pufferköpfen, zu aktivieren, um einen Pufferüberlaufangriff zu verhindern.

Als Nächstes kann die Art des Schutzes, der gewünscht wird (z.B. Lese- oder Schreibschutz), und der Ort des geschützten Speichers festgestellt werden (Kasten 320). Zum Beispiel kann der Ort eines Pufferkopfes im Kellerspeicher festgestellt werden. Unter Verwendung dieser Ortsinformationen kann auf einen Schutzdatensatz, der dem Speicherort entspricht, zugegriffen werden (Kasten 330). Dieser Schutzdatensatz kann zum Beispiel in separaten Schutzseiten des Systemspeichers gespeichert werden. Zum Schluß kann ein Bit innerhalb des Schutzdatensatzes gesetzt werden, das dem Speicherort entspricht (Kasten 340). Beispielsweise kann ein Schutzdatensatz ein Vektor sein, der acht Bits hat, wobei jedes einem Vier-Byte-Segment des Speichers entspricht. Dementsprechend kann das gegebene Bit, das einem Vier-Byte-Block einschließlich des Pufferkopfs entspricht, entsprechend gesetzt werden.

Mit Verweis auf 5 wird ein Flußdiagramm einer Implementierung von erweitertem Speicherschutz unter Verwendung zusätzlicher Pipeline-Strukturen gezeigt, wie zum Beispiel der in 3 gezeigten. Wie in 5 gezeigt, kann Verfahren 400 beim Empfang einer Speicheroperation (Kasten 410) beginnen. Die virtuelle Adresse der Speicheroperation kann auf einen Schutzcache und TLBs (z.B. einen DTLB und einen PTLB) angewendet werden (Kasten 420).

Als Nächstes kann festgestellt werden, ob es einen Schutz-TLB-Fehlversuch gibt (Raute 430). Falls ja, tritt ein Schutzseitenfehlversuch auf, und ein Schutzseitenlaufmechanismus kann ausgeführt werden (Kasten 440). Wenn der Schutz-TLB einen Treffer hat oder beim Abschluss des Seitenlaufs, kann als Nächstes festgestellt werden, ob es einen Schutz-Cache-Treffer (Raute 445) gibt. Wenn nicht, kann eine Cache-Fülloperation ausgeführt werden (Kasten 450), und die Kontrolle kehrt zu Kasten 420 zurück. Wie oben diskutiert, kann durch den Cache-Füllvorgang der gewünschte Schutzdatensatz aus dem Systemspeicher erhalten werden und dem Schutzcache zugeführt werden.

Wenn stattdessen bei Raute 445 ein Schutzcachetreffer auftritt, kann der Schutzstatus der Speicheroperation festgestellt werden (Kasten 460). Zum Beispiel kann der Schutzcache oder eine andere Struktur eine logische Operation ausführen, um festzustellen, ob ein oder mehrere Bits, die der Speicheroperation entsprechen, gesetzt sind, was einen geschützten Status anzeigt. Daher kann festgestellt werden, ob die Adresse, die der Speicheroperation entspricht, geschützt ist (Raute 470). Falls nicht, kann die Operation erlaubt werden (Kasten 480). Wenn stattdessen die Adresse geschützt ist, kann eine Speicherzugriffsverletzung signalisiert werden (Kasten 490).

In einigen Ausführungsformen kann EMP gemäß einer Ausführungsform der vorliegenden Erfindung für eine Laufzeitkontrolle in der Hardware sorgen, als ein Weg, um die katastrophalen Ergebnisse von Programmierfehlern zu mindern und eine kontrollierte Beendigung eines Programms bei einem aufgetretenen Fehler sicherzustellen. Auf diese Weise können die bessere Feststellung von Fehlern und die Gültigkeitsprüfung die Feststellung und Erfassung von Fehlern vor der Freigabe von Code steigern.

Ein EMP-Mechanismus kann ein Programm auf unerwartetes Verhalten kontrollieren. Beispielsweise können solche Kontrollen die Kontrolle auf Zugriff nach dem Ende einer Variablen, auf nicht zugewiesene Speicherorte und auf nicht initialisierte Speicherorte umfassen. Die Kontrollen sind nicht auf eine spezielle Sprache oder Routine beschränkt. Außerdem kann mit einem EMP-Mechanismus die Integrität der wichtigen Bausteine, wie zum Beispiel des Heaps, durch Schutz der Schlüsseldaten aufrechterhalten werden.

Auf diese Weise kann durch Bereitstellung von mikrostruktureller Unterstützung der Speicherschutz mit minimaler Auswirkung auf den kritischen Pfad der Speicher-Pipeline in einem Mehrzweckprozessor mit zeitverschachtelter Befehlsausführung implementiert werden.

Dementsprechend ist der Leistungszusatzaufwand für einen solchen Schutz viel kleiner als ein auf Software basierender Feststellmechanismus für Überschreibung.

Auf diese Weise kann die Softwareintegrität verbessert werden. Als ein Anwendungsszenario kann ein verbesserter Pufferüberlaufnachweis in Daten-Heap- und Kellerspeicherstrukturen erreicht werden. Im Kontext des Daten-Heaps kann ein Heap-Manager den Schutzmechanismus dazu nutzen, den Blockkopf jedes Puffers, der zugewiesen ist, zu schützen. Wenn ein Pufferüberlaufangriff von einem zugewiesenen Block zum nächsten versucht wird, entdeckt der Schutzmechanismus das und verhindert die unerwünschte Änderung. Dementsprechend kann das Auftreten von Pufferüberlauf und anderen Überschreibangriffen verhindert werden, statt den Angriff erst nach dem Erfolgen festzustellen.

Mit Compiler-Unterstützung können Software-Schwachstellen unter Verwendung des Speicherschutzes gemäß einer Ausführungsform der vorliegenden Erfindung gemildert werden. Zum Beispiel kann die feinstrukturelle Natur von Schutzdatensätzen zum Schutz anderer statischer Strukturen, wie zum Beispiel eines virtuellen Funktionstabellenzeigers, vor der Änderung als Teil eines Ausführungspfadumleitungsangriffs verwendet werden. In einigen Ausführungsformen kann auch ein Hardware-Canary um statistisch zugewiesene Puffer gelegt werden, die Quelle eines Überlaufs sein können.

Außerdem können Schutzdatensätze als unbegrenzte Implementierung von Debug-Unterbrechungspunkten angesehen werden. Statt durch ein paar verfügbare Debug-Register beschränkt zu werden, hat ein Software-Entwickler so viele gleichzeitige Debug-Unterbrechungspunkte wie gewünscht. Dementsprechend kann ein kleinteiliger Unterbrechungspunktnachweis für den ganzen Adreßraum implementiert werden. Dieser Nachweis stellt somit einen Hardware-Ansatz für die Lösung bestimmter Softwareintegritätsprobleme bereit. Das heißt, das Feststellen von unerwünschtem Verhalten in Anwendungen kann über das Erfassen von Unterbrechungspunkten erreicht werden, was eine neue Programmiermethodik ermöglicht.

Mit Verweis auf 6 wird ein Blockdiagramm eines Systems gemäß einer Ausführungsform der vorliegenden Erfindung gezeigt. Wie in 6 gezeigt, ist das System ein Multiprozessorsystem, das eine fest verschaltete Busarchitektur, wie zum Beispiel ein System mit Gemeinsamer Systemschnittstelle (CSI), hat und einen ersten Prozessor 570 und einen zweiten Prozessor 580 aufweist, die über eine fest verschaltete Zwischenverbindung 550 gekoppelt sind. Der erste Prozessor 570 umfasst mehrere Prozessorkerne 574a und 574b, einen Speicher-Controllerhub (MCH) 572 und Punkt-Punkt-(P-P-)Schnittstellen 576 und 578. In ähnlicher Weise umfasst der zweite Prozessor 580 dieselben Komponenten, nämlich Prozessorkerne 584a und 584b, einen MCH 582 und P-P-Schnittstellen 586 und 588.

Wie in 6 gezeigt, verbinden die MCHs 572 und 582 die Prozessoren mit den jeweiligen Speichern, nämlich einen Speicher 532 und einen Speicher 534, die Teile des Hauptspeichers sein können, der lokal mit den jeweiligen Prozessoren verbunden ist. Der erste Prozessor 570 und der zweite Prozessor 580 können über P-P-Schnittstellen 552 bzw. 554 an einen Chipsatz 590 angekoppelt sein. Wie in 6 gezeigt, umfasst Chipsatz 590 die P-P-Schnittstellen 594 und 598. Ferner umfasst Chipsatz 590 eine Schnittstelle 592 zum Verbinden von Chipsatz 590 mit einer Hochleistungsgrafik-Engine 538. In einer Ausführungsform kann ein Advanced Graphics Port-(AGP-)Bus zum Verbinden der Grafik-Engine 538 mit Chipsatz 590 verwendet werden. Der AGP-Bus 539 kann der AGP-Schnittstellenspezifikation, Rev. 2.0, entsprechen, die von der Intel Corporation, Santa Clara, Kalifornien, USA, am 5. Mai 1998 veröffentlicht wurde. Alternativ kann eine Punkt-Punkt-Verbindung 539 diese Komponenten koppeln.

Chipsatz 590 wiederum kann mit einem ersten Bus 516 über eine Schnittstelle 596 verbunden sein. In einer Ausführungsform kann der erste Bus 516 ein Peripheral Component Interconnect- (PCI-) Bus sein, wie durch die PCI Local Bus Specification, Produktionsversion, Rev. 2.1, vom Juni 1995 definiert, oder ein Bus, wie zum Beispiel der PCI Express-Bus oder ein weiterer E/A-Verbindungsbus der dritten Generation, obwohl der Geltungsbereich der vorliegenden Erfindung nicht in dieser Weise eingeschränkt ist.

Wie in 6 gezeigt, können verschiedene Eingabe-/Ausgabe- (E/A-)Geräte 514 an den ersten Bus 516 angekoppelt werden, zusammen mit einer Busbrücke 518, die den ersten Bus 516 mit einem zweiten Bus 520 verbindet. In einer Ausführungsform kann der zweite Bus 520 ein Bus mit wenigen Anschlussstiften (LPC-Bus) sein. Verschiedene Geräte können in einer Ausführungsform an den zweiten Bus 520 angeschlossen werden, einschließlich beispielsweise einer Tastatur/Maus 522, Kommunikationsgeräte 526 und einer Datenspeichereinheit 528, die Code 530 aufweisen kann. Ferner kann ein Audio-E/A 524 an den zweiten Bus 520 angeschlossen werden. Natürlich kann in anderen Ausfuhrungsformen ein System anders implementiert werden, wie zum Beispiel als Einprozessorsystem oder dergleichen. Während ferner der Geltungsbereich der vorliegenden Erfindung mit der speziellen Implementierung von 6 gezeigt wird, ist der Geltungsbereich der vorliegenden Erfindung nicht so stark eingeschränkt, und EMP kann auch in anderen Architekturen implementiert werden.

Ausführungsformen können in einem Computerprogramm implementiert werden, das auf einem Speichermedium gespeichert werden kann, welches Befehle hat, mit denen ein Computersystem zur Ausführung der Ausführungsformen programmiert wird. Das Speichermedium kann jede An von Platte umfassen, ohne darauf beschränkt zu sein, einschließlich Disketten, optische Speicherplatten, Compact-Disk-Nur-Lese-Speicher (CD-ROMs), wieder beschreibbare Compact-Disks (CD-RWs) und magnetooptische Platten, Halbleitergeräte, wie zum Beispiel Nur-Lese-Speicher (ROMs), Direktzugriffsspeicher (RAMs), wie zum Beispiel dynamische und statische RAMs, elektrisch löschbare programmierbare Nur-Lese-Speicher (EEPROMs), Flash-Speicher, magnetische oder optische Karten oder eine beliebige An von Medien, die sich zum Speichern von elektronischen Befehlen eignet. Andere Ausführungsformen können als Software-Module implementiert werden, die von einem programmierbaren Steuergerät ausgeführt werden.

Während die vorliegende Erfindung mit Bezug auf eine begrenzte Zahl von Ausführungsformen beschrieben wurde, werden Fachleute auf diesem Gebiet zahlreiche Modifizierungen und Abwandlungen davon erkennen. Es ist vorgesehen, dass die beigefügten Ansprüche alle solchen Modifizierungen und Abwandlungen als innerhalb des wahren Geistes und des Geltungsbereiches der vorliegenden Erfindung liegend erfassen.


Anspruch[de]
Verfahren, umfassend:

– Verknüpfen eines Schutzindikators eines Schutzdatensatzes mit einem Speicherort, wobei der Schutzdatensatz nicht über einen virtuellen Adreßraum zugänglich ist; und

– Verhindern des Zugriffs auf den Speicherort auf der Basis des Status des Schutzindikators.
Verfahren nach Anspruch 1, das ferner ein Speichern des Schutzdatensatzes an einem zweiten Speicherort, welcher vom Speicherort entfernt ist, umfasst. Verfahren nach Anspruch 1, das ferner ein Signalisieren einer Speicherzugriffsverletzung umfasst, wenn der Zugriff verhindert ist. Verfahren nach Anspruch 1, das ferner ein Zuweisen des Schutzdatensatzes zu einer virtuellen Adreßseite umfasst. Verfahren nach Anspruch 1, das ferner ein Speichern einer Kopie des Schutzdatensatzes in einem ersten Puffer umfasst. Verfahren nach Anspruch 5, das ferner ein Feststellen umfasst, ob eine Umcodierung, die einem Adresse des Schutzdatensatzes entspricht, in einem zweiten Puffer vorhanden ist. Verfahren nach Anspruch 1, das ferner ein Setzen eines Schutzindikators umfasst, der einem Pufferkopf entspricht. Verfahren nach Anspruch 7, das ferner ein Verhindern eines Pufferüberlaufangriffs unter Verwendung des Schutzdatensatzes umfasst. Verfahren nach Anspruch 1, das ferner ein Umcodieren einer virtuellen Adresse des Speicherortes in eine erste physische Adresse für den Speicherort und eine zweite physische Adresse für den Schutzdatensatz umfasst. Verfahren nach Anspruch 9, das ferner ein Kombinieren der ersten physischen Adresse und der zweiten physischen Adresse umfasst, um einen Schutzstatus des Speicherorts zu bestimmen. Vorrichtung, umfassend:

– einen ersten Speicher zum Speichern von Kopien von Schutzvektoren, wobei die Schutzvektoren einen Schutzstatus eines Teils eines zweiten Speichers kennzeichnen; und

– einen ersten Puffer, der an den ersten Speicher angeschlossen ist, wobei der erste Puffer so ausgebildet ist, daß er Umcodierungen zwischen einer virtuellen Adresse und einer entsprechenden physischen Adresse speichert, der erste so ausgebildet ist, daß er Puffer ein Treffersignal und ein Fehlsignal erzeugt.
Vorrichtung nach Anspruch 11, die ferner einen Schutzfehlversuchs-Handler umfasst, der das Fehlsignal empfängt und vom zweiten Speicher einen angeforderten Schutzvektor zur Speicherung im ersten Speicher erhält. Vorrichtung nach Anspruch 11, die ferner einen zweiten Puffer umfasst, der an den ersten Speicher und den ersten Puffer angeschlossen ist, wobei der zweite Puffer Umcodierungen zwischen einer virtuellen Adresse und einer physischen Adresse eines entsprechenden Teils des zweiten Speichers speichern soll, wobei die Umcodierungen des ersten Puffers physische Adressen von mindestens einem der Schutzdatensätze umfassen. Vorrichtung nach Anspruch 13, wobei der erste Puffer und der zweite Puffer eine einzige Speicherstruktur umfassen. Vorrichtung nach Anspruch 11, wobei der erste Speicher einen Cachespeicher zum Erzeugen eines Schutzsignals umfasst, wenn der Teil des zweiten Speichers geschützt ist. Vorrichtung nach Anspruch 11, wobei der erste Speicher eine logische Operation an einer oder mehreren Kopien von Schutzvektoren ausführen soll, um den Schutzstatus einer Adresse einer Speicheranforderungen zu bestimmen. Vorrichtung nach Anspruch 11, wobei der Teil des zweiten Speichers mindestens einen Pufferkopf eines Puffers im zweiten Speicher umfasst. Vorrichtung nach Anspruch 11, wobei der zweite Speicher eine Schutzseite umfasst, die Schutzvektoren umfasst, wobei die Schutzseite aus Datenseiten des zweiten Speichers segmentiert ist. Gegenstand, der ein maschinenlesbares Speichermedium umfasst, welches Daten speichert, die eine integrierte Schaltung darstellen, umfassend:

– einen ersten Cache zum Puffern von Schutzdatensätzen, wobei jeder der Schutzdatensätze einen Schutzstatus eines Teils eines Systemspeichers markieren soll; und

– einen Übersetzungspuffer, der mit dem ersten Cache verbunden ist; wobei der Übersetzungspuffer Umcodierungen zwischen einer virtuellen Adresse und einer entsprechenden physischen Adresse für die Schutzdatensätze speichern soll.
Gegenstand nach Anspruch 19, wobei die integrierte Schaltung ferner einen Schutzfehlversuchs-Handler umfasst, um ein Fehlsignal aus einem Übersetzungspuffer zu empfangen, wenn eine angeforderte Umcodierung nicht im Übersetzungspuffer vorhanden ist. Gegenstand nach Anspruch 19, wobei der erste Cache einen logischen Operator zum Bit-Indexieren auf der Basis eines angeforderten Schutzdatensatzes und einer Bytemaske umfasst, die auf eine Größe einer Speicheroperation hindeutet. Gegenstand nach Anspruch 19, wobei die integrierte Schaltung ferner einen Datenübersetzungspuffer umfasst, der mit dem ersten Cache verbunden ist. System, umfassend:

– einen ersten Speicher zum Speichern von Kopien von Schutzvektoren, wobei die Schutzvektoren einen Schutzstatus eines Teils eines adressierbaren Speichers kennzeichnen;

– einen ersten Puffer, der mit dem ersten Speicher verbunden ist, wobei der erste Puffer Umcodierungen zwischen einer virtuellen Adresse und einer entsprechenden physischen Adresse speichern soll; und

– einen dynamischen Direktzugriffsspeicher, der mit dem ersten Speicher und dem ersten Puffer verbunden ist.
System nach Anspruch 23, wobei der dynamische Direktzugriffsspeicher einen Speicherpuffer umfasst, der mehrere Köpfe hat, welche jeweils einem Block des Speicherpuffers entsprechen, wobei mehrere Köpfer den Teil des adressierbaren Speichers umfassen. System nach Anspruch 23, wobei der dynamische Direktzugriffsspeicher einen Kellerspeicher umfasst, wobei mindestens Teile des Kellerspeichers den Teil des adressierbaren Speichers umfassen. System nach Anspruch 23, wobei der dynamische Direktzugriffsspeicher einen ersten Teil zum Speichern von Datenseiten und einen zweiten Teil zum Speichern von Schutzseiten umfasst. System nach Anspruch 26, wobei der zweite Teil nicht über einen virtuellen Adreßraum zugänglich ist. System nach Anspruch 23, wobei der erste Speicher einen Cachespeicher umfasst, wobei der Cachespeicher ein Schutzsignal auf der Basis des Schutzstatus erzeugen soll. System nach Anspruch 28, wobei das Schutzsignal eine Speicherzugriffsverletzung verursachen soll. System nach Anspruch 23, wobei der erste Puffer eine erste Umcodierung auf eine physische Adresse für den Teil des adressierbaren Speichers und eine zweite Umcodierung auf eine physische Adresse für den Schutzvektor, der mit dem Teil des adressierbaren Speichers verbunden ist, speichern soll.






IPC
A Täglicher Lebensbedarf
B Arbeitsverfahren; Transportieren
C Chemie; Hüttenwesen
D Textilien; Papier
E Bauwesen; Erdbohren; Bergbau
F Maschinenbau; Beleuchtung; Heizung; Waffen; Sprengen
G Physik
H Elektrotechnik

Anmelder
Datum

Patentrecherche

  Patente PDF

Copyright © 2008 Patent-De Alle Rechte vorbehalten. eMail: info@patent-de.com