DE102004063573B4

DE102004063573B4 - Bereitstellen eines flexiblen Schutzmodells in einem Computersystem durch Trennen eines Schutzes aus einer Computerprivilegebene

Info

Publication number: DE102004063573B4
Application number: DE102004063573A
Authority: DE
Inventors: Ahmed K. Cupertino Ezzat
Original assignee: Hewlett Packard Development Co LP
Current assignee: Hewlett Packard Enterprise Development LP
Priority date: 2004-01-30
Filing date: 2004-12-30
Publication date: 2009-02-12
Anticipated expiration: 2024-12-31
Also published as: US9152785B2; DE102004063573A1; CN1648813A; US20050172138A1; JP4481180B2; JP2005216305A

Abstract

Verfahren zum Bereitstellen eines flexiblen Schutzes in einem Computersystem durch Trennen von Schutz von Privileg, wobei das Verfahren folgende Schritte aufweist:
Empfangen von Informationen, die zwei oder mehr Schutztypen beschreiben (302);
Empfangen von Informationen, die eine Beziehung zwischen den zwei oder mehr Schutztypen und Codeabschnitten beschreiben, die auf einer gleichen Privilegebene des Computersystems ausgeführt werden, wobei die Beziehung nicht notwendigerweise linear ist (302); und
Zuordnen der Informationen, die die zwei oder mehr Schutztypen beschreiben, und der Informationen, die die Beziehung beschreiben, zu den Codeabschnitten, wobei die einem ersten Codeabschnitt zugeordneten Informationen definieren, welche anderen Codeabschnitte auf den ersten Codeabschnitt zugreifen dürfen,
wobei die Codeabschnitte Bereiche sind und jeder der Schutztypen zumindest teilweise durch eines oder mehrere Bereichsattribute definiert ist, und wobei das eine oder die mehreren Bereichsattribute einen Bereichsidentifizierer umfassen, der einen eindeutigen Wert für einen bestimmten Bereich spezifiziert.

Description

Ausführungsbeispiele der vorliegenden Erfindung beziehen sich auf das Schützen von Informationen in einem Computersystem. Insbesondere beziehen sich Ausführungsbeispiele der vorliegenden Erfindung auf das Schützen von Informationen, die einem Computersystem zugeordnet sind, durch Entkoppeln des Schutzes der Informationen aus der Privilegebene, die dem Zugreifen auf die Informationen zugeordnet ist.
Ein Problem, das heutigen Computersystemen zugeordnet ist, ist das Schützen von Informationen in einem Computersystem vor einem unerwünschten Zugriff, der zufällig oder böswillig sein könnte. Zum Beispiel ist es für Benutzer vielleicht nicht wünschenswert, in der Lage zu sein, zu bestimmen, wie ein bestimmter Code funktioniert, die Daten, auf denen der Code arbeitet, oder die Datenstrukturen, in denen die Daten gespeichert sind. Informationen, wie sie hierin verwendet werden, umfassen, sind jedoch nicht beschränkt auf Code, Daten und/oder das Format, in dem die Daten gespeichert sind (ebenfalls bekannt als eine „Datenstruktur"). Ferner werden zu Zwecken der vorliegenden Anmeldung Aktivitäten, wie Zugreifen auf, Modifizieren und/oder Ausführen von Informationen, hierin nachfolgend als „Zugreifen" bezeichnet.
In der Computerterminologie bestimmt „Privileg", welche Aktionen ein Code an Informationen in einem Computersystem ausführen darf. Bei den meisten Betriebssystemen werden die Aktionen, die ein Code durchführen darf, dadurch bestimmt, in welcher Privilegebene der Code ausgeführt wird oder vorliegt. Zum Beispiel wird ein Code üblicherweise in einer von zwei Privilegebenen ausgeführt, die als Betriebssystem kern und Benutzer bekannt sind. Ferner hat ein Code, der in dem Betriebssystemkern vorliegt, eine uneingeschränkte Leistungsmenge, um Aktionen auszuführen, wie z. B. das Zugreifen auf Informationen irgendwo in dem Computersystem. Im Gegensatz dazu hat der Code, der in der Benutzerebene vorliegt, eine begrenzte Leistungsmenge zum Durchführen von Aktionen. Zum Beispiel kann der Code in der Benutzerebene nicht direkt auf Code oder Daten in dem Betriebssystemkern zugreifen.
In der Computerterminologie bezieht sich „Schutz" auf das Schützen von Informationen in dem Computersystem vor verschiedenen Aktionen, die an diesen Informationen ausgeführt werden. Zum Beispiel werden Code oder Daten, die in dem Betriebssystemkern vorliegen, vor Benutzern des Computersystems geschützt, die auf den Code oder die Daten entweder unbeabsichtigt oder mit böswilliger Absicht zugreifen. Auf ähnliche Weise wird der Code und die Daten in dem Betriebssystemspeicher vor einem direkten Zugriff durch den Code in der Benutzerebene geschützt. Im Gegensatz dazu kann auf Code und Daten in der Benutzerebene durch Benutzer entweder unbeabsichtigt oder mit böswilliger Absicht zugegriffen werden.
Üblicherweise liegen Betriebssysteme in dem Betriebssystemkern vor und Anwendungen liegen in der Benutzerebene vor. Ein Betriebssystemcode weist eine höhere Schutzebene auf als es Benutzeranwendungen haben. Im Allgemeinen gibt es keine feine Schutzgranularität entweder für das Betriebssystem oder für Anwendungen. Zum Beispiel kann eine Anwendung einen Satz von Modulen und/oder Bibliotheken umfassen. Einige dieser Module und/oder Bibliotheken können von einer dritten Partei kommen und sind daher nicht besonders vertrauenswürdig. Es wäre wünschenswert, einen Schutz auf flexible Weise für bestimmte Module und/oder Dienste in den Bibliotheken der Anwendung auf flexible Weise von anderen Modulen und/oder Diensten in den Bibliotheken bereitzustellen.
Bei einem anderen Beispiel enthalten vom Verkäufer gelieferte Anwendungsbibliotheken üblicherweise kritische Daten, die durch einen schlechten Anwendungscode verfälscht werden könnten, wie z. B. einen Anwendungscode, der einen nichtinitialisierten Zeiger dereferenziert. In diesen Situationen und in anderen wäre es höchst wünschenswert, den Zugriff dieser Module sowie auf was diese Module zugreifen, zu steuern, egal ob unbeabsichtigt oder mit böswilliger Absicht, um eine größere Anwendungsrobustheit bereitzustellen.
Aus der US 6 125 447 ist ein System bekannt, bei dem mehrere Schutzbereiche eingerichtet werden, wobei einem Schutzbereich keine Berechtigung zugeordnet ist oder mehrere Berechtigungen zugeordnet werden. Zwischen den Schutzbereichen und einer oder mehreren Klassen eines oder mehrerer Objekte einer Objekt-orientierten Software wird eine Zuordnung eingerichtet. Basierend auf dieser Zuordnung wird bestimmt, ob eine Aktion, die durch ein Objekt angefordert wird, zulässig ist. Schutzbereiche, die einer oder mehreren Klassen zugeordnet sein können, definieren Berechtigungen, die diese zugeordneten Klassen haben.
Aus der US 4 525 780 ist es bekannt, einen eindeutigen Identifizierer zu jedem Objekt zuzuordnen. Diese Schrift befasst sich mit einem Schutzschema zum Bestimmen von Zugriffsrechten auf Objekte basierend auf einer Benutzeridentifikation. Insbesondere wird der Zugriff auf ein Objekt durch einen eindeutigen Identifizierer in dem Objekt gesteuert.
Gegenüber diesem Stand der Technik liegt der Erfindung die Aufgabe zugrunde, ein Verfahren zum Bereitstellen eines flexiblen Schutzes in einem Computersystem, ein Computersystem und ein computerverwendbares Medium zum Bereitstellen eines flexiblen Schutzes zu schaffen.
Diese Aufgabe wird durch ein Verfahren gemäß den Ansprüchen 1 und 8, durch ein Computersystem gemäß den Ansprüchen 10 und 13 sowie durch ein computerverwendbares Medium gemäß Anspruch 15 gelöst.
Die vorliegende Erfindung ermöglicht eine flexible Feingranularität eines Schutzes unabhängig von der Privilegebene. Die vorliegende Erfindung ermöglicht diese Flexibilität mit einem bedeutend reduzierten Aufwand. Ferner verursacht ein Code, der keine feine Schutzgranularität benötigt, einen zusätzlichen Aufwand. Die vorliegende Erfindung schafft einen gewünschten Schutz für ein Anwendungsmodul, ohne den Bedarf, dieses Modul in den Betriebssystemkern zu bewegen. Die vorliegende Erfindung ermöglicht es den Programmentwicklern, die Ebene des Schutzes kundenspezifisch herzustellen, um ihre Bedürfnisse auf einer beliebigen Privilegebene zu erfüllen, ohne einen Code in anderen Privilegebenen zu beeinflussen oder zu integrieren.
Ausführungsbeispiele der vorliegenden Erfindung beziehen sich auf Verfahren und Systeme, die eine feine Schutzgranularität in einem Computersystem innerhalb derselben Privi legebene schaffen, d. h., anders ausgedrückt, durch Entkoppeln bzw. Trennen eines Schutzes von der Privilegebene. Bei einem Ausführungsbeispiel werden Informationen, die zwei oder mehr Schutztypen beschreiben, empfangen. Ferner werden Informationen, die eine Beziehung zwischen den zwei oder mehreren Schutztypen und Codeabschnitten beschreiben, empfangen. Die Beziehung muss nicht linear sein. Die Codeabschnitte werden in derselben Privilegebene ausgeführt. Die Informationen, die die zwei oder mehr Schutztypen und die Beziehung beschreiben, sind den Codeabschnitten zugeordnet.
Bevorzugte Ausführungsbeispiele der vorliegenden Erfindung werden nachfolgend Bezug nehmend auf die beiliegenden Zeichnungen näher erläutert. Es zeigen:
1A gemäß dem Stand der Technik ein Blockdiagramm eines Computersystems, bei dem Teile der Anwendung in dem Betriebssystemkern ausgeführt werden;
1B gemäß dem Stand der Technik ein Blockdiagramm der Multics-Architektur;
2A ein Blockdiagramm eines exemplarischen Computersystems zum Kompilieren und Verbindungseditieren von Codeabschnitten einer Anwendung gemäß Ausführungsbeispielen der vorliegenden Erfindung;
2B ein Blockdiagramm eines exemplarischen Computersystems, das sowohl Betriebssystemkern- als auch Anwendungs-Code gemäß Ausführungsbeispielen der vorliegenden Erfindung zeigt;
3A und 3B ein Flussdiagramm zum Unterstützen des Schutzes in einem Computersystem innerhalb einer Anwendung durch Trennen des Schutzes von dem Privileg gemäß Ausführungsbeispielen der vorliegenden Erfindung;
4 ein Blockdiagramm eines exemplarischen Computersystems, an dem Ausführungsbeispiele der vorliegenden Erfindung praktiziert werden können.
Die Zeichnungen, auf die in dieser Beschreibung Bezug genommen wird, sollten nicht als maßstabsgetreu gezeichnet betrachtet werden, außer dies ist ausdrücklich erwähnt.
Es wird nun detailliert Bezug auf die verschiedenen Ausführungsbeispiele der Erfindung genommen, wobei Beispiele derselben in den beiliegenden Zeichnungen dargestellt sind. Während die Erfindung in Verbindung mit diesen Ausführungsbeispielen beschrieben wird, wird darauf hingewiesen, dass sie die Erfindung nicht auf diese Ausführungsbeispiele einschränken sollen. Im Gegenteil, die Erfindung soll Alternativen, Abänderungen und Entsprechungen abdecken, die innerhalb des Wesens und des Schutzbereichs der Erfindung umfasst sein können, wie durch die beiliegenden Ansprüche definiert wird. Ferner werden in der nachfolgenden Beschreibung der vorliegenden Erfindung zahlreiche spezifische Details ausgeführt, um ein tiefgreifendes Verständnis der vorliegenden Erfindung zu liefern. In anderen Fällen wurden bekannte Verfahren, Prozesse, Komponenten und Schaltungen nicht detailliert beschrieben, um die Aspekte der Erfindung nicht unnötig unklar zu machen.
Wie bereits erwähnt wurde, besteht ein Problem im Hinblick auf das Schützen von Code und Daten mit feiner Granularität innerhalb einer Anwendung oder innerhalb des Betriebssystemkerns vor einem unerwünschten Zugriff, egal ob unbeabsichtigt oder mit böswilliger Absicht. Eine Lösung für das Problem ist das Bewegen der Teile einer Anwendung, die einen Schutz vor dem Rest der Anwendung benötigen, in den Betriebssystemkern. Dieser Lösungsansatz umfasst allgemein was als „Programmumschalten" bzw. „Kontextschalten" bekannt ist, wie nachfolgend detaillierter beschrieben wird. 1 gemäß dem Stand der Technik ist ein Blockdiagramm eines Computersystems, bei dem Teile der Anwendung in dem Be triebssystemkern ausgeführt werden. Zum Beispiel liegt ein Teil des Anwendungscodes (C1A, C2A, C3A) und der Daten (D1A, D2A, D3A), auf denen dieser Code (C1A, C2A, C3A) arbeitet, in dem Betriebssystemkern 140A vor, und ein Teil des Anwendungscodes (C4A, C5A, C6A) und der Daten (D4A, D5A, D6A), auf denen dieser Code (C4A, C5A, C6A) arbeitet, liegt in der Benutzerebene 150A vor. Der Code (C1A, C2A, C3A) und die Daten (D1A, D2A, D3A) der Anwendung, die in dem Betriebssystemkern 140A vorliegen, werden davor geschützt, dass Benutzer Zugriff auf dieselben haben. Diese Lösung hat jedoch viele Nachteile.
Ein Nachteil ist der Mehraufwand, der aus dem Programmumschalten zwischen dem Code (C4A, C5A, C6A), der in der Benutzerebene 150A ausgeführt wird, und dem Code (C1A, C2A, C3A), der in dem Betriebssystemkern 140A ausgeführt wird, entsteht. Zum Beispiel, wenn der Code (C4A, C5A, C6A) in der Benutzerebene 150A einen Code (C1A, C2A, C3A) in dem Betriebssystemkern 140A aufruft, muss der „Kontext", der die Inhalte einer sehr großen Anzahl von Registern umfasst, gesichert werden. Wenn die Steuerung von dem Code (C1A, C2A, C3A) in dem Betriebssystemkern 140A zu dem Code (C4A, C5A, C6A) in der Benutzerebene 150A zurückkehrt, muss der „Kontext" wiederhergestellt werden. Zahlreiche CPU-Zyklen sind erforderlich, um die Kontexte dieser Register während Kontextumschaltungen zu speichern und zurückzuspeichern.
Ein zweiter Nachteil ist, dass der Teil der Anwendung (C1A, C2A, C3A), der in dem Betriebssystemkern vorliegt, den Betriebssystemkern destabilisieren kann. Damit ein Computer zufällig arbeiten kann, muss das Betriebssystem stabil sein. Der Hauptzweck des Betriebssystemkerns 140A ist das Bereitstellen einer hohen Privileg- und Schutz-Ebene für das Betriebssystem. Potentiell kann jeder Code (C1A, C2A, C3A), der in den Betriebssystemkern 140A eingebracht wird, Programmfehler aufweisen und kann daher das Betriebssystem destabilisieren.
Ein dritter Nachteil ist, dass es einem Anwendungscode möglicherweise nicht erlaubt ist, in dem Betriebssystemkern bzw. Kernel ausgeführt zu werden. Wie bereits erörtert wurde, muss das Betriebssystem stabil sein. Daher ermöglichen es die Programmentwickler, die für den Code verantwortlich sind, der in dem Betriebssystemkern ausgeführt wird, den Programmentwicklern, die für die Anwendung verantwortlich sind, nicht, Teile der Anwendung in dem Betriebssystemkern zu platzieren.
Ein vierter Nachteil ist, dass, sobald ein Codeabschnitt für eine Anwendung in den Betriebssystemkern bewegt wird, er keine anderen Anwendungsverfahren mehr aufrufen kann. Anders ausgedrückt sind Zurückrufe nicht mehr möglich. In vielen Fällen ist dies nicht akzeptabel.
Eine zweite Lösung für das Problem umfasst das Teilen der Benutzerprivilegebene in mehrere lineare Vertrauensebenen (hierin nachfolgend bezeichnet als „Multics"). 1 gemäß dem Stand der Technik ist ein Blockdiagramm der Multics-Architektur. Zum Beispiel hat der Betriebssystemkern die höchste Vertrauensebene bei Ring 0 und die Benutzerebene ist in mehrere niedrigere Vertrauensebenen (Ringe 1, 2, 3) unterteilt.
Ein Code, der mehr Schaden verursachen kann, wird üblicherweise einer umfangreicheren Programmfehlerbeseitigung unterzogen, und folglich weist derselbe eine höhere Vertrauensebene auf. Zum Beispiel kann der Betriebssystemkern bei Ring 0 die größte Schadensmenge verursachen, und daher wird der Code bei Ring 0 der umfangreichsten Programmfehlerbeseitigung unterzogen und ist der vertrauenswürdigste Code. Ferner wird Ring 0 mit der größten Schutzmenge versehen. Im Gegensatz dazu wird der Code in Ring 3 der geringsten Programmfehlerbeseitigung unterzogen, daher ist Ring 3 am wenigsten vertrauenswürdig und wird mit der geringsten Schutzmenge versehen. Die nachfolgenden Regeln fassen zusammen, wie die linearen Vertrauensebenen in Multics funktionieren.

1. Der Code in Ring (j) sollte in der Lage sein, den Code in Ring (j) oder den Code in einer größeren Ringzahl als „j" aufzurufen.
2. Der Code in Ring (j) sollte nicht die Fähigkeit erhalten, den Code in Ring (i) direkt aufzurufen, wobei „i" geringer ist als „j", wobei Ring (j) den Code in Ring (i) auf gesteuerte Weise aufrufen kann, z. B. durch Aufrufen eines „Pförtners", der in dem Betriebssystemkern bei Ring 0 vorliegt. Dabei führt der „Pförtner" ein Kontextumschalten zwischen den Ringen durch.
3. Der Code in Ring (j) darf nie Zugriff auf Daten erhalten, die dem Ring (i) zugeordnet sind, wobei „i" geringer ist als „j".

Ein Nachteil mit dieser zweiten Lösung ist der Mehraufwand, den Multics verursacht. Zum Beispiel ist ein Kontextumschalten zwischen Ringen erforderlich und ein Kontextumschalten, wie bereits erörtert wurde, verursacht einen beträchtlichen Mehraufwand.
Ein zweiter Nachteil für die zweite Lösung ist der Mangel an Flexibilität. Das Schema ist strikt linear, und folglich sind Rückrufe nicht erlaubt. Zum Beispiel kann Ring 1 auf Ring 2 zugreifen, aber nicht umgekehrt. Rückrufe sind ein beliebter Programmierungsstil und in vielen Anwendungen relativ häufig.
Aus diesen und anderen Gründen wären ein Verfahren und ein System, die keinen beträchtlichen Mehraufwand verursachen, wertvoll. Ein Verfahren und ein System, die den Betriebssystemkern nicht destabilisieren, wären ebenfalls wünschenswert. Ein Verfahren und ein System zum Definieren einer flexiblen, nicht linearen Beziehung zwischen unter schiedlichen Codeabschnitten und Schutztypen, die Rückrufe erlauben, wären ebenfalls wünschenswert. Ein Verfahren und ein System, die ein Schutzmodell mit feiner Granularität innerhalb der selben Privilegebene erlauben (d. h. Benutzer oder Betriebssystemkern), wären wünschenswert. Ein Verfahren und ein System, die nicht erfordern, dass Programmentwickler, die an einer Anwendung arbeiten, eine Genehmigung von Programmentwicklern erhalten, die an dem Betriebssystemkern arbeiten, um den Schutz zu implementieren, den sie benötigen, um die Integrität ihres Codes zu bewahren, wären ebenfalls wünschenswert.
In der Computerterminologie bestimmt „Privileg", welche Aktionen ein Code an Informationen in einem Computersystem durchführen darf. In der Computerterminologie bezieht sich „Schutz" auf das Schützen von Informationen in dem Computersystem vor verschiedenen Aktionen, die an diesen Aktionen durchgeführt werden. Bei typischen heutigen Systemen ist der Schutz von Informationen direkt mit der Privilegebene korreliert, der die Informationen zugeordnet sind. Zum Beispiel weisen in 1A gemäß dem Stand der Technik Code (C1A, C2A, C3A) und Daten (D1A, D2A, D3A), die in dem Betriebssystemkern 140A vorliegen, eine hohe Schutz- und Privileg-Ebene auf. Im Gegensatz dazu weisen Code (C4A, C5A, C6A) und Daten (D4A, D5A, D6A), die in der Benutzerebene 150A vorliegen, eine niedrige Schutz- und Privileg-Ebene auf.
Bei einem wiederum anderen Beispiel zum Koppeln von Privileg und Schutz zeigt 1 gemäß dem Stand der Technik Code und Daten, die mit unterschiedlichen Schutz- und Privileg-Ebenen versehen sind, durch Zuordnen des Codes und der Daten zu linearen Vertrauensebenen, z. B. Ringen. Die Vertrauensebenen werden dadurch bestimmt, wie gut der Code von Fehlern bereinigt bzw. korrigiert ist. Je gründlicher der Code bereinigt ist, desto höher die Vertrauensebene, die dem Code zugewiesen ist. Je höher die Vertrauensebene, desto höher die Privileg- und Schutz-Ebene, die dem Code gegeben ist. Daher ist die Beziehung zwischen dem Code in den Ringen und dem Schutz, der dem Code durch die Vertrauensebenen gegeben wird, linear. Zum Beispiel könnte der Code in Ring (j) den Code in Ring (i) aufrufen, wobei „i" kleiner ist als „j", wodurch der Code in Ring (j) eine höhere Privileg-Ebene aufweist als der Code in Ring (i). Ferner kann der Code in Ring (i) den Code in Ring (j) nicht aufrufen, wodurch der Code in Ring (j) vor dem Code in Ring (i) geschützt ist. Gemäß einem Ausführungsbeispiel wird das Schutzkonzept ausgeweitet durch Entkoppeln bzw. Abtrennen der Privileg-Ebene, der Informationen zugeordnet sind, von dem Schutztyp, der den Informationen gegeben ist.
2A ist ein Blockdiagramm eines exemplarischen Computersystems zum Kompilieren und Verknüpfungs-Editieren von Codeabschnitten gemäß Ausführungsbeispielen der vorliegenden Erfindung. Die Blöcke in 2A können unterschiedlich angeordnet sein als dargestellt ist und können zusätzliche Merkmale implementieren, die hierin nicht beschrieben sind.
Gemäß einem Ausführungsbeispiel der vorliegenden Erfindung wird ein Schutz von dem Privileg getrennt, durch Teilen von Code- und/oder Daten-Abschnitten in Bereiche und Definieren von Schutztypen mit Bereichsattributen. Zum Beispiel umfasst ein Softwaresystem 200A Codeabschnitte (C1A, C2A, C3A, C4A, C5A, C6A, C7A, C8A, C9A) und Datenabschnitte (D1A, D2A, D3A, D4A, D5A, D6A, D7A, D8A, D9A), die in Bereiche 1–9 unterteilt sind. Das Softwaresystem 200A umfasst ferner eine Benutzerschnittstelle 240A, die Informationen empfangen kann, die Schutztypen definieren, wie z. B. Bereichsattribute, einen Kompilierer 210A, einen Verknüpfungseditierer 220A und ein Ausführelement 230A.
Bei einem anderen Ausführungsbeispiel der vorliegenden Erfindung kann die Benutzerschnittstelle 240A Informationen empfangen, die Schutztypen beschreiben. Zum Beispiel kann die Benutzerschnittstelle 240A ein Bereichsattribut empfangen, das spezifiziert, dass der Code (C2A) des Bereichs 2 den Code (C1A) des Bereichs 1 aufrufen kann. Wenn die Benutzerschnittstelle 240A keine Informationen empfängt, die spezifizieren, dass die anderen Bereiche 3–9 den Code (C1A) aufrufen können, dann ist der Code C1A vor dem Code der Bereiche 3–9 „geschützt", die den Code C1A aufrufen. Bereichsattribute werden hierin nachfolgend detaillierter beschrieben.
Bei einem wiederum anderen Ausführungsbeispiel empfängt die Benutzerschnittstelle 240A Informationen, die eine Beziehung zwischen den Schutztypen und den Codeabschnitten beschreiben. Unter Fortsetzung des Beispiels, wenn die Benutzerschnittstelle 240A Informationen empfängt, die spezifizieren, dass der Code (C2A) des Bereichs 2 den Code (C1A) des Bereichs 1 aufrufen kann, wird eine Beziehung zwischen den Bereichen 1 und 2 beschrieben. Ferner spezifizieren die Informationen, die die Benutzerschnittstelle 240A empfangen hat, ebenfalls eine Beziehung zwischen dem Bereich 2 und den anderen Bereichen 3–9, z. B., dass der Code (C2A) von Bereich 2 den Code (C4A, C5A, C6A, C7A, C8A, C9A) der anderen Bereiche (3–9) nicht aufrufen kann.
Bei der Multics-Architektur ist die Beziehung zwischen dem Code in den Ringen und dem Schutz, der dem Code gegeben ist, durch die Vertrauensebenen linear. Bei einem Ausführungsbeispiel der vorliegenden Erfindung ist die Beziehung zwischen den Schutztypen und dem Codeabschnitt jedoch nicht notwendigerweise linear. Unter Fortsetzung des Beispiels, wenn die Benutzerschnittstelle 240A ferner Informationen empfängt, die spezifizieren, dass der Code C3A des Bereichs 3 den Code C4A des Bereichs 4 aufrufen kann, besteht keine lineare Beziehung zwischen den Codes C1A–C4A der Bereiche 1–4 darüber, welcher Code den anderen Code von C1A–C4A aufrufen kann.
Durch Unterteilen des Codes einer Anwendung in Abschnitte, wie z. B. Bereiche, und Zuordnen von Schutztypen, wie z. B. Bereichsattributen, zu jenen Codeabschnitten, trennen Ausführungsbeispiele der vorliegenden Erfindung einen Privileg von dem Schutz. Somit kann dem Code (C1A, C2A, C3A, C4A, C5A, C6A, C7A, C8A, C9A) und den Daten (D1A, D2A, D3A, D4A, D5A, D6A, D7A, D8A, D9A) eine hohe Schutzebene bereitgestellt werden, während der Code (C1A, C2A, C3A, C4A, C5A, C6A, C7A, C8A, C9A) mit einer niedrigen Privilegebene ausgeführt wird, wie z. B. der Benutzerebene, während gleichzeitig der Mehraufwand reduziert wird, durch Vermeiden einer Kontextumschaltung, Bewahren der Betriebssystemkernstabilität und Beseitigen des Bedarfs, dass Anwendungsprogrammentwickler die Genehmigung von Betriebssystemkernentwicklern zu erhalten, einen Anwendungscode in den Betriebssystemkern zu platzieren, wie nachfolgend besser offensichtlich wird.
Wie in 2A gezeigt ist, kompiliert der Kompilierer 210A und der Verknüpfungseditierer 22A editiert die Codeabschnitte (C1A, C2A, C3A, C4A, C5A, C6A, C7A, C8A, C9A) und die Datenabschnitte (D1A, D2A, D3A, D4A, D5A, D6A, D7A, D8A, D9A), um das Ausführelement 230A zu erzeugen. Gemäß dem vorliegenden Ausführungsbeispiel ordnet der Verknüpfungseditierer 220A die Informationen, die die Schutztypen beschreiben, und die Informationen, die die Beziehung beschreiben, den Codeabschnitten (C1A, C2A, C3A, C4A, C5A, C6A, C7A, C8A, C9A) zu. Unter Fortsetzung des Beispiels kann der Verknüpfungseditierer 220A Informationen speichern, die beschreiben, dass der Code (C2A) des Bereichs 2 den Code des Bereichs 1 (C1A) in den Anfangsblöcken der Ausführelemente für Code C2A und/oder C1A aufrufen kann, wie nachfolgend detaillierter beschrieben wird.
Manchmal wird ein Code nicht auf dem selben Computer ausgeführt, auf dem er kompiliert und verknüpfungseditiert wurde. Zum Beispiel kann ein Ausführelement 230A, das auf dem Softwaresystem 200A kompiliert und verknüpfungseditiert wurde, auf einem anderen Computer ausgeführt werden.
2B ist ein Blockdiagramm eines exemplarischen Softwaresystems zum Ausführen von Codeabschnitten gemäß Ausführungsbeispielen der vorliegenden Erfindung. Die Blöcke in 2B können anders angeordnet sein als dargestellt ist, und können zusätzliche Merkmale implementieren, die hierin nicht beschrieben sind. Das Ausführelement 230A, gezeigt in 2A, kann auf dem Softwaresystem 200B ausgeführt werden, wie in 2B gezeigt ist.
Das Softwaresystem 200B zeigt einen Betriebsystemkern 240B und eine Benutzerebene 250B, einen Code (C1B, C2B, C3B, C4B, C5B, C6B, C7B, C8B, C9B) und Daten (D1B, D2B, C3B, D4B, D5B, D6B, D7B, D8B, D9B), die in Bereiche 1–9 unterteilt sind. Das Softwaresystem 200B umfasst ferner ein Ladeprogramm 270B in dem Betriebssystemkern 240B, das die Abschnitte von Code (C1B, C2B, C3B, C4B, C5B, C6B, C7B, C8B, C9B) und Daten (D1B, D2B, D3B, D4B, D5B, D6B, D7B, D8B, D9B) in die Benutzerebene 250B aus dem Ausführelement 230A aus 2A lädt. Ein Speicherverwalter 260B liegt ebenfalls in dem Betriebssystemkern 240B vor. Der Speicherverwalter 260B ruft den Code (C1B, C2B, C3B, C4B, C5B, 06B, C7B, C8B, C9B) und die Daten (D1B, D2B, D3B, D4B, D5B, D6B, D7B, D8B, D9B) in und aus dem Hauptspeicher, wenn auf den Code (C1B, C2B, C3B, C4B, C5B, C6B, C7B, C8B, C9B) und die Daten (D1B, D2B, D3B, D4B, D5B, D6B, D7B, D8B, D9B) zugegriffen wird.
Bei einem Ausführungsbeispiel ermöglicht die vorliegende Erfindung, dass Codeabschnitte in der selben Privilegebene des Computersystems ausgeführt werden. Um das Beispiel fortzusetzen, sind die Abschnitte des Codes (C1B, C2B, C3B, C4B, C5B, C6B, C7B, C8B, C9B) und der Daten (D1B, D2B, D3B, D4B, D5B, D6B, D7B, D8B, D9B) für eine Anwendung und können daher in der Benutzerebene 250B ausgeführt werden.
Das Ladeprogramm 270B extrahiert die Informationen, die die Schutztypen beschreiben, und die Informationen, die die Beziehung von den Codeabschnitten beschreiben, gemäß einem Ausführungsbeispiel. Unter Fortsetzung des Beispiels kann das Ladeprogramm 270B die Informationen extrahieren, die beschreiben, dass der Code C2B des Bereichs 2 den Code C1B des Bereichs 1 aus dem Anfangsblock des Ausführelements für Code C2B aufrufen kann, wo ihn der Verknüpfungseditierer 220A aus 2A platziert hat.
Bei einem anderen Ausführungsbeispiel bestimmt der Speicherverwalter 260B, ob Codeabschnitten erlaubt ist, auf andere Codeabschnitte zuzugreifen, basierend auf den Informationen, die die Schutztypen beschreiben. Unter Fortsetzung des Beispiels zeigt der Schutztyp, der dem Code C1B zugeordnet ist, an, dass er den Code von C2B aufrufen kann. Der Schutztyp, der dem Code C2B zugeordnet ist, kann jedoch anzeigen, dass er dem Code C1B nicht erlauben wird, ihn aufzurufen. Wenn der Code von C1B den Code C2B aufruft, kann der Speicherverwalter 260B die Schutztypen vergleichen, die den Codes C1B und C2B zugeordnet sind, um zu bestimmen, dass es dem Code C1B nicht erlaubt ist, den Code C2B aufzurufen, wie hierin nachfolgend detaillierter beschrieben wird.
Ein Kontextumschalten muss nicht durchgeführt werden, wenn Codeabschnitte einander aufrufen, bei einem wiederum anderen Ausführungsbeispiel der vorliegenden Erfindung. Zum Beispiel, Bezug nehmend auf 2B, wenn Code C1B den Code C2B aufruft, ist ein Kontextumschalten vielleicht nicht erforderlich, da ihre jeweiligen Schutztypen anzeigen, dass C1B C2B aufrufen kann. Somit wird der Mehraufwand beim Speichern und Wiederherstellen einer großen Anzahl von Registern durch das vorliegende Ausführungsbeispiel vermieden.
Ferner können bei einem Ausführungsbeispiel der vorliegenden Erfindung einige Werte, die den Schutztypen zugeordnet sind, in Registern gespeichert werden. Diese Werte müssen vielleicht gespeichert und wiederhergestellt werden, wenn die Ausführungssteuerung zwischen Bereichen umschaltet (hierin nachfolgend bezeichnet als „Kreuzbereichsschalten"). Zum Beispiel, wenn der Code C1B den Code C2B aufruft, können die Inhalte eines Registers, das Werte für ein oder mehrere Bereichsattribute umfasst, die Bereich 1 zugeordnet sind, so gespeichert werden, dass das Register mit einem oder mehreren Bereichsattributwerten initialisiert werden kann, die dem Bereich 2 zugeordnet sind. Nach der Rückkehr zu Code C2B können die Inhalte des Registers wiederhergestellt werden. Ein Kreuzbereichschalten erfordert nicht den Mehraufwand, den ein Kontextumschalten erfordert, da eine große Anzahl von Registern nicht gespeichert und wiederhergestellt wird.
Bei einem Ausführungsbeispiel der vorliegenden Erfindung spezifizieren die Schutztypen, ob ein Kreuzbereichsschalten erforderlich ist oder nicht. Unter Fortsetzung des Beispiels kann der Schutztyp, der dem Code C2A zugeordnet ist, spezifizieren, dass ein Kreuzbereichschalten erforderlich ist, wenn der Code C2A den Code C1A aufruft, und der Schutztyp, der dem Code C3A zugeordnet ist, kann spezifizieren, dass ein Kreuzbereichschalten nicht erforderlich ist, wenn der Code C3A den Code C4A aufruft, wie detaillierter beschrieben wird.
Bereichs- bzw. Domgin-Attribute
Gemäß einem Ausführungsbeispiel werden Schutztypen durch Bereichsattribute definiert. Beispiele dieser Bereichsattribute umfassen, sind jedoch nicht beschränkt auf, einen Bereichsidentifizierer, einen Private Key (privaten Schlüssel), einen SharedCode Key (Gemeinschaftscode-Schlüssel), einen SharedData Key (Gemeinschaftsdaten-Schlüssel), einen AllowOthers Key (Anderen-Ermöglichen-Schlüssel) und einen AccessOthers Key (Auf-Andere-Zugreifen-Schlüssel). Wie hierin nachfolgend detaillierter beschrieben wird, können einige der Bereichsattribute als Listen spezifiziert sein. Zum Beispiel können mehrere Schlüssel einem bestimmten Bereich zugeordnet sein zum gemeinschaftlichen Verwenden von Code anderer Bereiche in der Form einer SharedCode Key List (Gemeinschaftscode-Schlüsselliste), wie nachfolgend detaillierter beschrieben wird.
Zu Zwecken der Darstellung soll die nachfolgende Erklärung Bezug auf Strukturen nehmen, die in 2B gezeigt sind.
Gemäß einem Ausführungsbeispiel spezifiziert der Bereichsidentifizierer einen eindeutigen Wert für einen bestimmten Bereich. Zum Beispiel können die Bereiche 1–9 jeweilige eindeutige Bereichsidentifizierer PD-id1 bis PD-id9 aufweisen. Diese Bereichsidentifizierer können verwendet werden, um die Prozesse zu identifizieren, die aus dem Ausführen von Code (C1B, C2B, C3B, C4B, C5B, C6B, C7B, C8B, C9B) resultieren, der den Bereich 1–9 zugeordnet ist.
Bei einem anderen Ausführungsbeispiel spezifiziert der Private Key einen eindeutigen Schutzschlüssel pro Benutzerkontext eines Prozesses, z. B. einen eindeutigen Wert zum Schützen des Kontexts jedes Benutzers, der gleichzeitig ablaufend einen bestimmten Bereich verwendet.
Bei einem wiederum anderen Ausführungsbeispiel spezifiziert der SharedCode Key einen Wert, den ein bestimmter Bereich verwenden muss, um auf einen Code zuzugreifen, der einem anderen Bereich zugeordnet ist. Zum Beispiel kann der Wert PK5 als der SharedCode Key spezifiziert sein, den der Bereich 1 verwenden muss, um auf den Code C6B aus Bereich 6 zuzugreifen.
Ferner muss bei einem Ausführungsbeispiel der vorliegenden Erfindung ein Kreuzbereichsschalten nicht durchgeführt werden, um auf einen Code unter Verwendung des SharedCode Key zuzugreifen. Unter Fortsetzung des Beispiels muss ein Kreuzbereichsschalten nicht durchgeführt werden, wenn die Steuerung zwischen dem Ausführen des Codes C6B mit dem Bereich 6 und des Codes C1B des Bereichs 1 umschaltet.
Gemäß einem wiederum anderen Ausführungsbeispiel werden Bereichsidentifizierer und SharedCode-Key-Paare einem bestimmten Bereich zugeordnet, um anzuzeigen, welche Schlüssel der spezifizierte Bereich verwenden muss, um auf den bestimmten Bereich zuzugreifen. Um das Beispiel fortzusetzen, zeigt das Zuordnen des Bereichsidentifizierens und des SharedCode-Key-Paars „PD-id1/PK5" zu dem Bereich 6 an, dass der Bereich 1 (z. B. der Bereich für PD-id1) den SharedCode Key PK5 verwenden muss, wenn er auf den Code C1B für Bereich 1 zugreift.
Eine Liste von Bereichsidentifizierern und SharedCode Keys (hierin nachfolgend bezeichnet als „SharedCode Key List") wird einem bestimmten Bereich zugeordnet, um anzuzeigen, welche Schlüssel die spezifizierten Bereiche verwenden müssen, um auf den Code des bestimmten Bereichs zuzugreifen, gemäß einem Ausführungsbeispiel. Um das Beispiel fortzusetzen, umfasst eine SharedCode Key List „PD-id1/PK5: PD-id2/PK5: PD-id3/PK5" drei Paare aus Bereichsidentifizierer und SharedCode Key, die durch Doppelpunkte getrennt sind, die dem Bereich 6 zugeordnet sein können, um anzuzeigen, dass Bereich 1, Bereich 2 und Bereich 3 PK5 verwenden müssen, um auf den Code C6B des Bereichs 6 zuzugreifen.
Bei einem anderen Ausführungsbeispiel kann ein Paar von SharedCode Key zu Bereichsidentifizierer von "*/PK5" dem Bereich 6 zugeordnet sein, um anzuzeigen, dass alle anderen Bereiche den SharedCode Key PK5 verwenden müssen, um auf den Code C5B zuzugreifen.
Der SharedData Key spezifiziert einen Wert, den ein bestimmter Bereich verwenden muss, um auf Daten zuzugreifen, die einem anderen Bereich zugeordnet sind, bei einem anderen Ausführungsbeispiel. Zum Beispiel kann der Wert PK6 als der SharedData Key spezifiziert sein, den Bereich 1 verwenden muss, um auf die Daten D6B des Bereichs 6 zuzugreifen. Gemäß einem Ausführungsbeispiel muss ein Kreuzbereichs schalten nicht durchgeführt werden, um unter Verwendung des SharedData Key auf Daten zuzugreifen. Um das Beispiel fortzusetzen, muss ein Kreuzbereichsschalten nicht durchgeführt werden, wenn der Code C1B des Bereichs 1 auf die Daten D6B des Bereichs 6 zugreift.
Paare aus Bereichsidentifizierer und SharedData Key sind einem bestimmten Bereich zugeordnet, um anzuzeigen, welche Schlüssel der spezifizierte Bereich verwenden muss, um auf die Daten des bestimmten Bereichs zuzugreifen, gemäß einem Ausführungsbeispiel. Um das Beispiel fortzusetzen, zeigt das Zuordnen des Paars aus Bereichsidentifizierer und SharedData Key „PD-id1/PK6" zu einem bestimmten Bereich, wie z. B. dem Bereich 6, an, dass der Bereich 1 (z. B. der Bereich für PD-id1) den SharedCode Key PK6 beim Zugreifen auf die Daten D1B für Bereich 1 verwenden muss.
Eine Liste von Bereichsidentifizierern und SharedData Keys (bezeichnet hierin nachfolgend als eine „SharedData Key List") ist einem bestimmten Bereich zugeordnet, um anzuzeigen, welche Schlüssel die spezifizierten Bereiche verwenden müssen, um auf die Daten des bestimmten Bereichs zuzugreifen, gemäß einem Ausführungsbeispiel. Um das Beispiel fortzusetzen, umfasst eine SharedData Key List „PD-id1/PK6: PD-id2/PK7: PD-id4/PK8" drei Paare aus Bereichsidentifizierer und SharedData Key, die durch Doppelpunkte getrennt sind, die dem Bereich 6 zugeordnet sein können, um anzuzeigen, dass die Bereiche 1–4 die Schlüssel PK6, PK7, PK8 jeweils verwenden müssen, um auf die Daten D6B des Bereichs 6 zuzugreifen.
Ein Paar aus Bereichsidentifizierer und SharedData Key, wie z. B. "*/PK9", kann einem Bereich zugeordnet sein, wie z. B. dem Bereich 6, um anzuzeigen, dass alle anderen Bereiche, z. B. "*", einen SharedData Key verwenden müssen, wie z. B. PK9, um auf die Daten zuzugreifen, wie z. B. D5B, gemäß einem Ausführungsbeispiel.
Bei einem Ausführungsbeispiel spezifiziert der AllowOthers Key einen Wert, den ein bestimmter Bereich verwenden muss, um auf einen Code zuzugreifen, der einem anderen Bereich zugeordnet ist, in Verbindung mit dem bestimmten Bereich, der ein Kreuzbereichschalten durchführt. Zum Beispiel zeigt ein Zuordnen von „PD-id5: PD-id6" zu dem Bereich 6 an, dass ein Kreuzbereichschalten durchgeführt werden muss, damit der Code (CB5, CB6) der Bereiche 5 und 6 auf den Code CB3 des Bereichs 3 zugreift. Gemäß einem Ausführungsbeispiel kann eine Liste von Paaren aus Bereichsidentifizierer und AllowOthers Key einem bestimmten Bereich zugeordnet sein. Zum Beispiel zeigt das Zuordnen von „PD-id5/PK3: PD-id6/PK3" zu dem Bereich 3 an, dass der Code der Bereiche 5 und 6 auf den Code des Bereichs 3 unter Verwendung des Schlüssels PK3 zugreifen kann.
Der AccessOthers Key spezifiziert einen Wert, der verwendet wird, um einen Zugriff eines Codes anzufordern, der einem bestimmten Bereich zugeordnet ist, im Auftrag eines anderen Bereichs, bei einem wiederum anderen Ausführungsbeispiel. Zum Beispiel kann PK8 als der Schlüssel spezifiziert sein, den der Bereich 1 verwenden möchte, um auf den Code CB8 des Bereichs 8 zuzugreifen. Gemäß einem Ausführungsbeispiel kann eine Liste von Paaren aus Bereichsidentifizierer und AccessOthers Key einem bestimmten Bereich zugeordnet sein. Zum Beispiel zeigt das Zuordnen von „PD-id8/PK8: PD-id9/PK9" zu dem Bereich 1 an, dass der Code CB1 auf den Code CB8 und CB9 mit den jeweiligen Schlüsseln PK8 und PK9 zugreifen möchte.
Ferner werden bei einem Ausführungsbeispiel die SharedCode Keys und die SharedData Keys der Zielbereiche mit den AllowOthers Keys der anfordernden Bereiche verglichen, um zu bestimmen, ob die anfordernden Bereiche auf den Code der Zielbereiche zugreifen können. Um das Beispiel fortzusetzen, können die AllowOthers Keys des anfordernden Bereichs 1 „PD-id8/PK8: PD-id9/PK9" durch den Verknüpfungseditierer 270B mit den SharedCode Keys und SharedData Keys der Ziel bereiche (z. B. Bereiche 8 und 9) verglichen werden. Wenn z. B. der Bereich 8 einen SharedCode Key hat, der anzeigt, dass der Bereich 1 PK8 verwenden kann, um auf den Code des Bereichs 8 zuzugreifen, dann wäre es dem Code CB1 erlaubt, auf den Code C8B zuzugreifen.
Eine Implementierung auf der Itanium-Architektur
Einige Computerarchitekturen schützen Seiten davor, dass ohne Erlaubnis auf sie zugegriffen wird (ebenfalls bekannt als „Seitenebenenschutz"). Zum Beispiel kann jede Seite einen Schlüssel aufweisen, der derselben zugeordnet ist. Ein Code, der anfordert, auf diese Seite zuzugreifen, muss diesen Schlüssel ebenfalls haben, um eine Erlaubnis zu erhalten, auf diese Seite zuzugreifen. Wenn der Code diesen Schlüssel verwendet, um auf die Seite zuzugreifen, dann ist es dem Code erlaubt, auf die Seite zuzugreifen. Anderweitig wird dem Code ein Zugriff auf diese Seite verweigert.
Gemäß einem Ausführungsbeispiel kann die vorliegende Erfindung auf der Architektur der Itanium-Prozessorfamilie (IPF) von Intel sowie auf den meisten modernen Mikroprozessoren implementiert sein. Bei IPF haben die Seiten in dem Speicher ihre eigenen Schutzattribute, die Schlüsselform, die durch die Hardware durch Vergleichen der Schlüssel der Seite mit Attributen für den momentan laufenden Code durchgesetzt werden, der einem bestimmten Bereich in der Form eines Programms oder einer DLL zugeordnet ist. Zum Beispiel kann das Schutzschlüsselregister (PKR; PKR = protection key register) von IPF gemäß einem Ausführungsbeispiel Werte für Bereichsattribute enthalten, die auf die Bereiche von Code abbilden, der gegenwärtig ausgeführt wird, wie nachfolgend detaillierter beschrieben wird. Das PKR wird auf diese Werte initialisiert, wenn die Steuerung zwischen Codeabschnitten umschaltet, was ebenfalls als „Kreuzbereichsschalten" bekannt ist.
Zum Beispiel, wenn der Code von Bereich 1 ausgeführt wird, kann das PKR Werte für Bereichsattribute umfassen, die dem Bereich 1 zugeordnet sind. Wenn die Steuerung zu einem anderen Bereich umschaltet, wie z. B. Bereich 2, können die Inhalte des PKR gespeichert werden und das PKR kann mit den Werten für die Bereichsattribute initialisiert werden, die dem Bereich 2 zugeordnet sind. Wenn die Steuerung zurück zu dem Code von Bereich 1 umschaltet, werden die Inhalte des PKR, die jetzt die Werte der Bereichsattribute enthalten, die dem Bereich 2 zugeordnet sind, gespeichert, und das PKR wird wieder zurück-initialisiert, mit den Werten der Bereichsattribute, die dem Bereich 1 zugeordnet sind.
Das PKR enthält unter anderem den Wert des Private-Key-Attributs, das dem Bereich des Codes oder der Daten zugeordnet ist, die ausgeführt werden, gemäß einem wiederum anderen Ausführungsbeispiel. Wenn der Code C1B z. B. ausgeführt wird, können die Werte des Private-Key-Attributs, die dem Bereich 1 zugeordnet sind, in dem PKR gespeichert werden.
Gemäß einem Ausführungsbeispiel vergleicht die IPF-Architektur den Wert der Bereichsattribute in dem PKR mit einem Schlüssel, der einer Seite zugeordnet ist, wenn ein Codeabschnitt anfordert, auf die Seite zuzugreifen. Wenn der Schlüssel der Seite unter den Werten in dem PKR ist, dann wird Zugriff gewährt; anderweitig wird Zugriff verweigert.
Gemäß einem wiederum anderen Ausführungsbeispiel kann der Verknüpfer die DLL oder Programmwerte für Bereichsattribute zuweisen, wie bereits hierin erörtert wurde. Gemäß einem Ausführungsbeispiel, während einer Verknüpfungseditierung, ist der AccessOthers-Schlüssel eine Wunschliste, die durch den Verknüpfer analysiert wird. Beim Vergleichen des Werts des AccessOthers-Schlüssels für einen Codeabschnitt mit den Schutztypen, die anderen Codeabschnitten zugeordnet sind, kann der Verknüpfer den Wert des AccessOthers-Schlüssels ändern. Zum Beispiel, wenn Bereich 1 in dem AccessOthers Key spezifiziert, dass er auf den Code CA8 mit PK8 zugreifen möchte, aber Bereich 8 in seinem SharedCode Key spezifiziert, dass Code CA1 von Bereich 1 CA8 nicht aufrufen kann, dann kann der Verknüpfer den AccessOthers Key für Bereich 1 modifizieren.
Ferner kann der Verknüpfer Stichleitungen für Verfahren in dem Code für jeden Bereich erzeugen, auf die zugegriffen wird, wenn dieser Code durch den Code für andere Bereiche durch ein Kreuzbereichschalten aufgerufen wird, bei einem wiederum anderen Ausführungsbeispiel.
Gemäß einem Ausführungsbeispiel werden globale Variablen, die Bereichen zugeordnet sind, durch Bereichsattribute geschützt, die entsprechenden Bereichen zugeordnet sind. Dies kann. z. B. erreicht werden durch Gruppieren der globalen Variablen auf Seitengrenzen.
Operationsbeispiele
3A und 3B zeigen ein Flussdiagramm 300 zum Verstärken eines Schutzes in einem Computersystem durch Trennen von Schutz und Privileg gemäß Ausführungsbeispielen der vorliegenden Erfindung. Obwohl spezifische Operationen in dem Flussdiagramm 300 offenbart sind, sind solche Operationen exemplarisch. Das heißt, Ausführungsbeispiele der vorliegenden Erfindung sind gut geeignet zum Durchführen verschiedener anderer Operationen oder Abweichungen der Operationen, die in dem Flussdiagramm 300 erwähnt sind. Es wird darauf hingewiesen, dass die Operationen in dem Flussdiagramm 300 in einer unterschiedlichen Reihenfolge ausgeführt werden können, als der die dargestellt ist, und dass möglicherweise nicht alle Operationen in dem Flussdiagramm 300 durchgeführt werden. Alle oder ein Teil der Ausführungsbeispiele, die durch das Flussdiagramm 300 beschrieben werden, können unter Verwendung von computerlesbaren und computer ausführbaren Anweisungen implementiert werden, die z. B. in einem computerverwendbaren Medium eines Computersystems oder einer ähnlichen Vorrichtung vorliegen.
Zu Zwecken der Darstellung soll die Erörterung des Flussdiagramms 300 Bezug auf die Strukturen nehmen, die in 2A und 2B gezeigt sind.

Bei 302 werden gemäß einem Ausführungsbeispiel Informationen, die Schutztypen beschreiben, und Informationen, die eine Beziehung zwischen den Schutztypen und Codeabschnitten beschreiben, empfangen. Zum Beispiel empfängt der Verknüpfungseditierer 220A Informationen, wie in Tabelle 1 unten gezeigt ist, von einem Benutzer, die anzeigen, dass die Bereichsattribute für den Bereich id, Private Key, Shared Code Key List oder AccessOthers List den entsprechenden Bereichen 1, 4, 5 zugeordnet sein können: Tabelle 1: Informationen, die Schutztypen beschreiben und Informationen, die eine Beziehung zwischen den Schutztypen und den Codeabschnitten beschreiben

Bereichsname	Bereichsattribute	Werte, die den Bereichsattributen zugeordnet sind
Bereich 1	Bereichs-ID Private Key AccessOthers List	PD-id1 PK1 PD-id4/PK7:PD-id5/PK5
Bereich 4	Bereichs-ID Private Key SharedCode Key List	PD-id4 PK4 PD-id1/PK4:PD-id5/PK4
Bereich 5	Bereichs-ID Private Key SharedCode Key List	PD-id5 PK5 PD-id1/PK5:PD-id4/PK5

In Tabelle 1 umfassen die Informationen, die die Schutztypen beschreiben, die Werte PD-id1, PD-id4, PD-id5 für die Bereichs-ids, die Werte PK1, PK4, PK5 für die Private Keys und die Werte PK7, PK5 für die AccessOthers-Key-List- und PK4, PK5 für die SharedCode-Key-List-Bereichsattribute. Da die Bereichsattribute AccessOthers Key List und SharedCode Key List in der Form von Bereichs-id-zu-Schlüssel-Paaren vorliegen, sind die Informationen, die die Beziehung zwischen den Schutztypen und Codeabschnitten beschreiben, mit diesen zwei Bereichsattributen definiert.
Obwohl andere Bereiche in 2A und 2B gezeigt sind, soll diese Darstellung der Einfachheit halber auf die Bereiche 1, 4, 5 beschränkt sein.
Bei 306 sind die Informationen, die die Schutztypen beschreiben, und die Informationen, die die Beziehung beschreiben, den Codeabschnitten zugeordnet, gemäß einem anderen Ausführungsbeispiel. Wenn z. B. der Code C1A, C4A, C5A kompiliert und verknüpfungseditiert ist, ordnet der Verknüpfungseditierer 221 die Werte der Bereichsattribute, die in Tabelle 1 gezeigt sind, den Codeabschnitten C1A, C4A, C5A zu, um das Ausführelement 230A zu erzeugen. Genauer gesagt können die Werte PD-id1 für die Bereichs-id, PK1 für den Private Key und PD-id4/PK7: PD-id5/PK5 für die AccessOthers Key List in dem Anfangsblock des Ausführelements für den Codeabschnitt C1A platziert werden. Die Bereichsattributwerte, die in Tabelle 1 für Bereiche 4, 5 gezeigt sind, sind den Bereichen 4, 5 auf eine ähnliche Weise zugeordnet.
Beim Vergleichen des Werts der AccessOthers Key List für einen Codeabschnitt der Schutztypen, die anderen Codeabschnitten zugeordnet sind, kann der Verknüpfungseditierer 220A den Wert des AccessOthers Key ändern. Zum Beispiel kann der Verknüpfungseditierer 220A den Wert PD-id4/PK7 der AccessOthers Key List für den Bereich 1 mit dem Wert PK4 des Private Key für Bereich 4 ändern und bestimmen, dass, obwohl der Bereich 1 einen Zugriff auf den Code C4B mit PK7 anfordert, auf C4B nur mit PK4 zugegriffen werden kann. In diesem Fall kann der Verknüpfungseditierer 220A den Wert PD-id4/PK7 zu PD-id4/PK4 ändern. Alternativ kann der Verknüpfungseditierer 220A den Wert nicht modifizieren und zu der Ausführungszeit kann dem Code C1B des Bereichs 1 der Zugriff auf den Code C43 verweigert werden, wie nachfolgend detaillierter beschrieben wird.
Bei 308 werden die Informationen, die die Schutztypen beschreiben, wiedergewonnen. Zum Beispiel wird das Ausführelement 230A bei einem wiederum anderem Ausführungsbeispiel, das Ausführelemente für Code C1B, C4B, C5B umfasst, auf dem Softwaresystem 200B ausgeführt, das in 2B gezeigt ist. In diesem Fall, während das Ladeprogramm 270B das Ausführelement 230A in einen Hauptspeicher lädt, gewinnt das Ladeprogramm 270B die Werte für die Bereichsattribute wieder, wie in Tabelle 1 gezeigt ist, aus den Ausführelementen für die Codeabschnitte C1B, C4B, C5B. Gemäß einem Ausführungsbeispiel leitet das Ladeprogramm 270B die Werte der Bereichsattribute zu dem Speicherverwalter 260B weiter.
Bei 310 fordert gemäß einem anderen Ausführungsbeispiel ein erster Codeabschnitt einen Zugriff auf einen zweiten Codeabschnitt an. Zum Beispiel, Bezug nehmend auf 2B, kann ein Code C4B einen Zugriff auf einen Code C5B anfordern, durch Aufrufen eines Prozesses in dem Code C5B.
In dem Entscheidungsfeld 312, Bestimme, ob der erste Codeabschnitt auf den zweiten Codeabschnitt zugreifen darf, gemäß einem Ausführungsbeispiel. Der Speicherverwalter 260B erfasst, dass der Code C43 einen Zugriff auf Code C5B angefordert hat. Während der Code C4A ausgeführt wird, wurde das PKR PK4, PK5 umfassen, wobei PK4 der Wert des Private Key des Bereichs 4 ist, und die SharedCode Key List von Bereich 5 spezifiziert, dass Bereich 4 einen Code aus Bereich 5 unter Verwendung von PK5 gemeinschaftlich verwenden kann. Der Speicherverwalter 260B bestimmt, ob Code C4A einen Code C5A aufrufen kann. Wenn es dem ersten Codeab schnitt erlaubt ist, auf den zweiten Codeabschnitt zuzugreifen, dann wird die Operation 316 ausgeführt; ansonsten wird die Operation 320 ausgeführt.
Bei 316 gemäß einem wiederum anderen Ausführungsbeispiel wird es dem ersten Codeabschnitt ermöglicht, auf den zweiten Codeabschnitt zuzugreifen. Zum Beispiel, da das PKR PK5 umfasst, was der Wert des Private Key des Bereichs 5 ist, ist es dem Code C4A erlaubt, auf den Code C5A zuzugreifen.
Bei 320 ist es dem ersten Codeabschnitt gemäß einem Ausführungsbeispiel nicht erlaubt, auf den zweiten Codeabschnitt zuzugreifen. Zum Beispiel, würde das PKR PK5 nicht umfassen, wäre es dem Code C4A nicht erlaubt worden, auf den Code von C5A zuzugreifen.

Wie bei einem Ausführungsbeispiel bereits erwähnt wurde, ist die Beziehung zwischen den Schutztypen und den Codeabschnitten nicht notwendigerweise linear. Obwohl jedoch Ausführungsbeispiele der vorliegenden Erfindung nicht erfordern, dass die Beziehung linear ist, können Ausführungsbeispiele der vorliegenden Erfindung trotzdem verwendet werden, um eine lineare. Beziehung zu implementieren. Das Nachfolgende beschreibt ein anderes Operationsbeispiel, bei dem Ausführungsbeispiele der vorliegenden Erfindung verwendet werden, um eine Multics-Architektur mit linearen Vertrauensebenen zu implementieren. Tabelle 2: Multics-Architektur implementiert mit Bereichen und Bereichsattributen

VERTRAUENSEBENE	RING	ANWENDUNG	WERTE VON BEREICHSATTRIBUTEN
am wenigsten vertrauenswürdig	Ring 3	Main()	Bereichs-ID: PD-id1 Private Key: PK1 SharedCode Key List:/PK11 SharedData Key List:/PK12 AllowOthers Key List: NULL AccessOthers Key List: NULL
mittel vertrauenswürdig	Ring 2	SQL/MX	Bereichs-ID: PD-id2 Private Key: PK2 SharedCode Key List: Null
			SharedData Key List: Null AllowOthers Key List: PD-id1/PK2:PD-id3/PK2 AccessOthers Key List: PD-id1/PK1:PD-id3/PK3
am meisten vertrauenswürdig	Ring 1	Benutzerbibliothek	Bereichs-ID: PD-id3 Private Key: PK3 SharedCode Key List: NULL SharedData Key List: NULL AllowOthers Key List: PD-id1/PK3:PD-id2/PK3 AccessOthers Key List: NULL

Bezug nehmend auf Tabelle 2, gemäß einem Ausführungsbeispiel, während der Code für Bereich 1 ausgeführt wird, z. B. PD-id1, kann das PKR „PK1, PK11, PK12" umfassen. Das PKR umfasst PK1, da das der private Schlüssel von Bereich 1 ist. Das PKR umfasst PK11, da die SharedCode Key List von Bereich 1 anzeigt, dass alle anderen Bereiche, z. B. "*" PK11 verwenden können, um auf den Code von Bereich 1 zu zugreifen. PKR umfasst PK12, da die SharedData Key List im Bereich 1 anzeigt, dass alle anderen Bereiche, z. B. "*", PK11 verwenden können, um auf die Daten von Bereich 1 zuzugreifen.
Während der Code für Bereich 2 gemäß einem Ausführungsbeispiel ausgeführt wird, z. B. PD-id2, kann das PKR „PK2, PK3, PK11, PK12" umfassen. PKR umfasst PK2, da dies der Private Key von Bereich 2 ist. PKR umfasst PK3, da die AccessOthers Key List von Bereich 3 anzeigt, dass Bereich 2, z. B. PD-id2, PK3 verwenden kann, um auf den Code von Bereich 2 zuzugreifen. Das PKR umfasst PK11, da die Shared-Code Key List von Bereich 1 anzeigt, dass alle anderen Bereiche, z. B. "*", PK11 verwenden können, um auf den Code von Bereich 1 zuzugreifen. PKR umfasst PK12, da die Shared-Data Key List von Bereich 1 anzeigt, dass alle anderen Bereiche, z. B. "*", PK11 verwenden können, um auf die Daten aus Bereich 1 zuzugreifen.
Während der Code von Bereich 3 gemäß einem Ausführungsbeispiel ausgeführt wird, kann das PKR „PK3, PK11, PK12" umfassen. Das PKR umfasst PK3, da es der Private Key von Bereich 3 ist. Das PKR umfasst PK11, da die SharedCode Key List von Bereich 1 anzeigt, dass alle anderen Bereiche, z. B. "*", PK11 verwenden können, um auf den Code von Bereich 1 zuzugreifen. Das PKR umfasst PK12, da die SharedData Key List von Bereich 1 anzeigt, dass alle anderen Bereiche, z. B. "*", PK11 verwenden können, um auf die Daten von Bereich 1 zuzugreifen.
Gemäß einem anderen Ausführungsbeispiel speichert und die Computerhardware die Inhalte jedes Registers und gewinnt dieselben wieder, das Werte von Bereichsattributen für Kreuzbereichsschaltungen enthält. In dem Fall der IPF-Architektur würde die Hardware die Inhalte des PKR während Kreuzbereichsschaltungen speichern und wiedergewinnen. Unter Fortsetzung des Beispiels, das in Tabelle 2 gezeigt ist, während Code ausgeführt wird, der dem Bereich zugeord net ist, kann das PKR „PK1, PK11, PK12" enthalten. Wenn ein Kreuzbereichsschalten zwischen Bereich 1 und Bereich 2 auftritt, dann können die Werte „PK1, PK11, PK12" gespeichert werden und das PKR kann mit den Werten „PK2, PK3, PK11, PK12" initialisiert werden. Wenn die Steuerung zurück von dem Code von Bereich 2 zu dem Code von Bereich 1 schaltet, können die Werte „PK2, PK3, PK11, PK12" gespeichert werden und das PKR kann mit den Werten „2K1, PK11, PK12" reinitialisiert werden.
Obwohl Tabelle 1 die Ringe 1–3 zeigt, könnten die Ringe jegliche Ringe in einer Multics-Architektur sein, wo main() in einem Ring ist, der eine niedrigere Vertrauensebene hat als die Ringe, in denen SQL/MX und die Benutzerbibliothek vorliegen, wobei die Benutzerbibliothek in einem Ring ist, der vertrauenswürdiger ist als die Ringe, in denen SQL/MX und main() vorliegen, und SQL/MX in einem Ring vorliegt, der eine Vertrauensebene zwischen den Ringen aufweist, in denen main() und die Benutzerbibliothek vorliegen.
Obwohl Ausführungsbeispiele der vorliegenden Erfindung verwendet werden können, um eine lineare Beziehung zwischen Schutztypen und Codeabschnitten zu implementieren, wie in Tabelle 2 gezeigt ist, erfordern Ausführungsbeispiele der vorliegenden Erfindung nicht, dass die Beziehung zwischen Schutztypen und Codeabschnitten linear ist, wie in dem Operationsbeispiel beschrieben ist, das sich auf Tabelle 1 bezieht.
Hardware-Übersicht
4 stellt ein exemplarisches Computersystem 490 dar, auf dem Ausführungsbeispiele der vorliegenden Erfindung praktiziert werden können. Im Allgemeinen weist das Computersystem 490 folgende Merkmale auf: einen Bus 400 zum Kommunizieren von Informationen, einen Prozessor 401, der mit dem Bus 400 zum Verarbeiten von Informationen und Anweisungen gekoppelt ist, einen (flüchtigen) Direktzugriffsspeicher (RAM; RAM = Random Access Memory) 402, der mit dem Bus 400 zum Speichern von Informationen und Anweisungen für den Prozessor 401 gekoppelt ist, einen (nichtflüchtigen) Nur-Lese-Speicher (ROM; ROM = Read-Only-Memory) 403, der mit dem Bus 400 zum Speichern von statischen Informationen und Anweisungen für den Prozessor 401 gekoppelt ist, eine Datenspeicherungsvorrichtung 404, wie z. B. eine magnetische oder optische Platte und ein Plattenlaufwerk, das mit einem Bus 400 zum Speichern von Informationen und Anweisungen gekoppelt ist, eine optische Benutzerausgabevorrichtung, wie z. B. eine Anzeigevorrichtung 405, die mit dem Bus 400 zum Anzeigen von Informationen an den Computerbenutzer gekoppelt ist, eine optionale Benutzereingabevorrichtung, wie z. B. eine alphanumerische Eingabevorrichtung 406, die alphanumerische und Funktions-Tasten umfasst, die mit dem Bus 400 gekoppelt sind, zum Kommunizieren von Informationen und Befehlsauswahlmöglichkeiten zu dem Prozessor 401 und eine optionale Benutzereingabevorrichtung, wie z. B. eine Cursorsteuerungsvorrichtung 407, die mit dem Bus 400 zum Kommunizieren von Benutzereingabeinformationen und Befehlsauswahlmöglichkeit zu dem Prozessor 401 gekoppelt ist. Ferner wird eine optionale Eingabe-/Ausgabe-Vorrichtung (I/O-Vorrichtung) 408 verwendet, um das Computersystem 490 z. B. auf ein Netzwerk zu koppeln.
Die Anzeigevorrichtung 405, die mit dem Computersystem 490 verwendet wird, kann eine Flüssigkristallvorrichtung, eine Kathodenstrahlröhre oder eine andere Anzeigevorrichtung sein, die geeignet zum Erzeugen von graphischen Bildern und alphanumerischen Zeichen ist, die für den Benutzer erkennbar sind. Die Cursorsteuerungsvorrichtung 407 ermöglicht es dem Computerbenutzer, die zweidimensionale Bewegung eines sichtbaren Symbols (Zeiger) auf einem Anzeigebildschirm der Anzeigevorrichtung 405 dynamisch zu signalisieren. Viele Implementierungen der Cursorsteuerungsvorrichtung sind in der Technik bekannt und umfassen einen Trackball, eine Maus, einen Joystick oder spezielle Tasten auf einer alpha numerischen Eingabevorrichtung 406, die in der Lage sind, eine Bewegung einer gegebenen Richtung oder eine Art und Weise der Verschiebung zu signalisieren. Es wird darauf hingewiesen, dass die Cursorsteuerung 407 ebenfalls über eine Eingabe von der Tastatur unter Verwendung spezieller Tasten und Tastensequenzbefehle angewiesen und/oder aktiviert werden kann. Alternativ kann der Cursor über eine Eingabe von einer Anzahl von speziell angepassten Cursorrichtungsvorrichtungen angewiesen und/oder aktiviert werden.
Bei dem vorliegenden Ausführungsbeispiel können Softwaresysteme 200A und 200B auf einem Computersystem implementiert sein, wie z. B. dem Computersystem 490.
Schlussfolgerung
Durch Unterteilen des Codes einer Anwendung in Abschnitte, wie z. B. Bereiche, und Zuordnen von Schutztypen, wie z. B. Bereichsattributen, zu diesen Codeabschnitten, trennen Ausführungsbeispiele der vorliegenden Erfindung Privileg von Schutz. Somit kann dem Code eine hohe Schutzebene bereitgestellt werden, während er mit einer niedrigen Privilegebene ausgeführt wird, wie z. B. der Benutzerebene, während gleichzeitig der Aufwand reduziert wird, durch Vermeiden eines Kontextschaltens, Bewahren einer Betriebssystemkernstabilität und Beseitigen des Bedarfs, dass Anwendungsprogrammentwickler eine Genehmigung von Betriebssystemkern-Programmentwicklern erhalten, um den Anwendungscode in dem Betriebssystemkern zu platzieren.
Erweiterungen und Alternativen
Obwohl viele der Ausführungsbeispiele der vorliegenden Erfindung unter Verwendung der IPF-Architektur beschrieben wurden, können die Ausführungsbeispiele auf einer Computer architektur implementiert sein, die einen Seitenebenenschutz liefert.
Obwohl bestimmte Ausführungsbeispiele der vorliegenden Erfindung mit Codeabschnitten in der Benutzerebene beschrieben wurden, kann die vorliegende Erfindung verwendet werden, um ebenfalls unterschiedliche Schutztypen zu Codeabschnitten in dem Betriebssystemkern zuzuordnen.
Obwohl bestimmte Ausführungsbeispiele der vorliegenden Erfindung beschrieben wurden, die Werte von Bereichsattributen in den Anfangsblöcken von Ausführelementen speichern, können andere Mechanismen zum Speichern der Werte der Bereichsattribute verwendet werden. Zum Beispiel können bei den meisten Computerarchitekturen und Betriebssystemen die Werte der Bereichsattribute in einer Datenbank gespeichert werden. In dem Fall, dass das Multiple-Virtual-Storage-Betriebssystem (MVS-Betriebssystem) auf einem Mainframe läuft, können die Werte alternativ in einem Virtual-Storage-Access-Method-Datensatz (VSAM-Datensatz) gespeichert werden.
Obwohl bestimmte Ausführungsbeispiele der Erfindung beschrieben wurden, die Werte von Bereichsattributen in den Anfangsblöcken von Ausführelementen beibehalten, können andere Mechanismen zum Beibehalten der Werte der Bereichsattribute verwendet werden. Zum Beispiel können in den meisten Computerarchitekturen und Betriebssystemen die Werte der Bereichsattribute in einer Datenbank beibehalten werden. In dem Fall des MVS-Betriebssystems (MVS = Multiple Virtual Storage), das auf einem Mainframe läuft, können die Werte alternativ in Steuerungsblöcken oder in einem VSAM-Datensatz (VSAM = Virtual Storage Access Method) gespeichert werden.
Obwohl bestimmte Ausführungsbeispiele der vorliegenden Erfindung beschrieben wurden, wo Beziehungen zwischen Schutztypen und Codeabschnitten unter Verwendung von Be reichs-id-zu-Schlüsselpaaren spezifiziert wurden, können andere Mechanismen, wie z. B. Datenbanken, zum Beibehalten dieser Beziehungen verwendet werden.

Claims

Verfahren zum Bereitstellen eines flexiblen Schutzes in einem Computersystem durch Trennen von Schutz von Privileg, wobei das Verfahren folgende Schritte aufweist: Empfangen von Informationen, die zwei oder mehr Schutztypen beschreiben (302); Empfangen von Informationen, die eine Beziehung zwischen den zwei oder mehr Schutztypen und Codeabschnitten beschreiben, die auf einer gleichen Privilegebene des Computersystems ausgeführt werden, wobei die Beziehung nicht notwendigerweise linear ist (302); und Zuordnen der Informationen, die die zwei oder mehr Schutztypen beschreiben, und der Informationen, die die Beziehung beschreiben, zu den Codeabschnitten, wobei die einem ersten Codeabschnitt zugeordneten Informationen definieren, welche anderen Codeabschnitte auf den ersten Codeabschnitt zugreifen dürfen, wobei die Codeabschnitte Bereiche sind und jeder der Schutztypen zumindest teilweise durch eines oder mehrere Bereichsattribute definiert ist, und wobei das eine oder die mehreren Bereichsattribute einen Bereichsidentifizierer umfassen, der einen eindeutigen Wert für einen bestimmten Bereich spezifiziert.
Verfahren gemäß Anspruch 1, bei dem die Beziehung vom Benutzer definierbar ist.
Verfahren gemäß Anspruch 1 oder 2, bei dem das eine oder die mehreren Bereichsattribute einen Private Key umfassen, der einen eindeutigen Wert spezifiziert, zum Schützen jedes Benutzers, der gleichzeitig einen bestimmten Bereich verwendet.
Verfahren gemäß einem der Ansprüche 1 bis 3, bei dem das eine oder die mehreren Bereichsattribute einen SharedCode Key umfassen, der einen Wert spezifiziert, den ein bestimmter Bereich verwenden muss, um auf Code zuzugreifen, der einem anderen Bereich zugeordnet ist.
Verfahren gemäß einem der Ansprüche 1 bis 4, bei dem das eine oder die mehreren Bereichsattribute einen SharedData Key umfassen, der einen Wert spezifiziert, den ein bestimmter Bereich verwenden muss, um auf Daten zuzugreifen, die einem anderen Bereich zugeordnet sind.
Verfahren gemäß einem der Ansprüche 1 bis 5, bei dem das eine oder die mehreren Bereichsattribute einen AllowOthers Key umfassen, der einen Wert spezifiziert, den ein bestimmter Bereich verwenden muss, um auf einen Code zuzugreifen, der einem anderen Bereich zugeordnet ist, in Verbindung mit dem bestimmten Bereich, der ein Kreuzbereichschalten zu dem anderen Bereich durchführt.
Verfahren gemäß einem der Ansprüche 1 bis 6, bei dem das eine oder die mehreren Bereichsattribute einen AccessOthers Key umfassen, der einen Wert spezifiziert, der verwendet wird, um einen Zugriff eines Codes anzufordern, der einem bestimmten Bereich zugeordnet ist, im Auftrag eines anderen Bereichs.
Verfahren zum Bereitstellen eines flexiblen Schutzes in einem Computersystem durch Trennen von Schutz von Privileg, wobei das Verfahren folgende Schritte aufweist: Erfassen einer Anforderung von einem ersten Codeabschnitt, auf einen zweiten Codeabschnitt zuzugreifen, wobei der erste und der zweite Codeabschnitt auf einer gleichen Privilegebene des Computersystems ausgeführt werden; Bestimmen, ob es dem ersten Codeabschnitt erlaubt ist, auf den zweiten Codeabschnitt zuzugreifen, basierend auf Informationen, die zwei oder mehr Schutztypen beschreiben, und ebenfalls basierend auf Informationen, die eine Beziehung zwischen dem einen oder den mehreren Schutztypen und den Codeabschnitten beschreiben, wobei die Beziehung nicht notwendigerweise linear ist (312), wobei die dem zweiten Codeabschnitt zugeordneten Informationen definieren, welche anderen Codeabschnitte auf den zweiten Codeabschnitt zugreifen dürfen, und wobei die Codeabschnitte Bereiche sind und jeder der Schutztypen zumindest teilweise durch eines oder mehrere Bereichsattribute definiert ist, und wobei das eine oder die mehreren Bereichsattribute einen Bereichsidentifizierer umfassen, der einen eindeutigen Wert für einen bestimmten Bereich spezifiziert; und wenn die Beziehung spezifiziert, dass der erste Codeabschnitt auf den zweiten Codeabschnitt zugreifen kann (12), dann Erlauben, dass der erste Codeabschnitt auf den zweiten Codeabschnitt zugreift (316); ansonsten Nicht-Erlauben, dass der erste Codeabschnitt auf den zweiten Codeabschnitt zugreift (320).
Verfahren gemäß Anspruch 8, bei dem die Informationen, die die zwei oder mehr Schutztypen beschreiben, und die Informationen, die die Beziehungen beschreiben, den Codeabschnitten zugeordnet sind, und wobei das Verfahren ferner das Wiedergewinnen der Informationen, die zwei oder mehr Schutztypen beschreiben, und der Informationen, die die Beziehungen beschreiben, aufweist.
Computersystem, das folgende Merkmale aufweist: eine Speichereinheit; und einen Prozessor, der mit der Speichereinheit gekoppelt ist, wobei der Prozessor zum Ausführen eines Verfahrens zum Verstärken des Schutzes durch Trennen von Schutz von Privileg in einem Computersystem vorgesehen ist, wobei das Verfahren folgende Schritte aufweist: Empfangen von Informationen an einer Benutzerschnittstelle, die zwei oder mehr Schutztypen beschreiben; Empfangen von Informationen an der Benutzerschnittstelle, die eine Beziehung zwischen den zwei oder mehr Schutztypen und Codeabschnitten beschreiben, die in einer gleichen Privilegebene des Computersystems ausgeführt werden, wobei die Beziehung nicht notwendigerweise linear ist; und Zuordnen, an einem Verknüpfungseditierer, der Informationen, die die zwei oder mehr Schutztypen beschreiben, und der Informationen, die die Beziehung beschreiben, zu den Codeabschnitten, wobei die einem ersten Codeabschnitt zugeordneten Informationen definieren, welche anderen Codeabschnitte auf den ersten Codeabschnitt zugreifen dürfen, und wobei die Codeabschnitte Bereiche sind und jeder der Schutztypen zumindest teilweise durch eines oder mehrere Bereichsattribute definiert ist, und wobei das eine oder die mehreren Bereichsattribute einen Bereichsidentifizierer umfassen, der einen eindeutigen Wert für einen bestimmten Bereich spezifiziert.
Computersystem gemäß Anspruch 10, bei dem die Beziehung vom Benutzer definierbar ist.
Computersystem gemäß Anspruch 10 oder 11, bei dem die Codeabschnitte Bereiche sind und jeder der Schutztypen zumindest teilweise durch eines oder mehrere Bereichsattribute definiert ist.
Computersystem, das folgende Merkmale aufweist: eine Speichereinheit; und einen Prozessor, der mit der Speichereinheit gekoppelt ist, wobei der Prozessor ein Verfahren ausführt zum Bereitstellen eines flexiblen Schutzes in einem Computersystem durch Trennen von Schutz von Privileg, wobei das Verfahren folgende Schritte aufweist: Erfassen einer Anforderung von einem ersten Codeabschnitt an einem Speicherverwalter, um auf einen zweiten Codeabschnitt zuzugreifen, wobei der erste und der zweite Codeabschnitt in einer gleichen Privilegebene des Computersystems ausgeführt werden; Bestimmen, bei dem Speicherverwalter, ob dem ersten Codeabschnitt erlaubt ist, auf den zweiten Codeabschnitt zuzugreifen, basierend auf Informationen, die zwei oder mehr Schutztypen beschreiben, und ferner basierend auf Informationen, die eine Beziehung zwischen den zwei oder mehr Schutztypen und den Codeabschnitten beschreiben, wobei die Beziehung nicht notwendigerweise linear ist), wobei die dem zweiten Codeabschnitt zugeordneten Informationen definieren, welche anderen Codeabschnitte auf den zweiten Codeabschnitt zugreifen dürfen, und wobei die Codeabschnitte Bereiche sind und jeder der Schutztypen zumindest teilweise durch eines oder mehrere Bereichsattribute definiert ist, und wobei das eine oder die mehreren Bereichsattribute einen Bereichsidentifizierer umfassen, der einen eindeutigen Wert für einen bestimmten Bereich spezifiziert; und wenn die Beziehung spezifiziert, dass der erste Codeabschnitt auf den zweiten Codeabschnitt zugreifen kann, dann Erlauben, an dem Speicherverwalter, dass der erste Codeabschnitt auf den zweiten Codeabschnitt zugreift; ansonsten Nicht-Erlauben, an dem Speicherverwalter, dass der erste Codeabschnitt auf den zweiten Codeabschnitt zugreift.
Computersystem gemäß Anspruch 13, bei dem die Informationen, die die zwei oder mehr Schutztypen beschreiben, und die Informationen, die die Beziehungen beschreiben, den Codeabschnitten zugeordnet sind, und wobei das Verfahren ferner das Wiedergewinnen von Informationen, die die zwei oder mehr Schutztypen beschreiben, und Informationen, die die Beziehungen beschreiben, bei einem Ladeprogramm aufweist.
Computerverwendbares Medium, das einen computerlesbaren Programmcode aufweist, der in demselben verkörpert ist, um zu bewirken, dass ein Computersystem ein Verfahren gemäß einem der Ansprüche 1 bis 9 ausführt.