DE19840029C1 - Verfahren zum Linken von in einen Arbeitsspeicher eines Prozessors nachgeladenen Programmodulen auf einer Chipkarte - Google Patents

Abstract

Verfahren zum Linken von nachgeladenen Programmodulen auf einer Chipkarte mit ebenfalls nachgeladenen Bibliotheken, wobei das Verfahren in zwei Abschnitte aufgeteilt ist, wobei der erste Abschnitt zu einem beliebigen Zeitpunkt nach dem Kompilieren des Programmoduls erfolgen kann, und lediglich der zweite Abschnitt, in dem die dynamischen Referenzen aufgelöst werden, nach dem Laden der Programmodule auf der Chipkarte erfolgen muß.

Description

Die vorliegende Erfindung betrifft ein Verfahren zum Linken von in einen Arbeitsspeicher eines Prozessors nachgeladenen Programmodulen, beispielsweise auf einer Chipkarte. Die Er­ findung befaßt sich mit folgender Problemstellung:

Auf zukünftigen Multiapplikations-Chipkarten sollen neben dem statisch vorgeladenen Betriebssystem und Standardbibliotheken auch individuelle Programmodule vom Benutzer nachgeladen wer­ den können. Dies ist bislang aus folgendem Grund nicht mög­ lich: Jedes Programm basiert auf Adressen, an deren Position das Programm abgearbeitet wird. Ein sogenannter "Linker" legt diese Adressenzuordnung fest. Da für das nachzuladende Pro­ gramm völlig unbekannt ist, welche Adressen in der Chip-Karte bereits belegt sind, muß die Möglichkeit geschaffen werden, nachzuladende Programme auf beliebigen Adressen ablaufen las­ sen zu können; d. h. die nachzuladenden Programme müssen auf der Chip-Karte relokatierbar sein. Es ist zu erwarten, daß die nachladbaren Module in ihrer Summe den auf der Chipkarte zur Verfügung stehenden physikalischen Adreßbereich überstei­ gen. Den Modulen kann deshalb kein fest vorgegebener physika­ lischer Adreßbereich zugewiesen werden. Das Betriebssystem auf der Karte muß deshalb in der Lage sein, einem Modul beim Aufladen auf die Karte dynamisch einen freien Speicherbereich zuzuweisen. Hierzu muß ein nachzuladendes Modul der Chipkar­ te mitteilen, auf welche Bibliotheken es zugreifen muß. Nach­ dem verifiziert wurde, daß dem Modul der Zugriff auf die ent­ sprechenden Bibliotheken erlaubt ist, muß es an sie gelinkt werden, d. h. mit den entsprechenden logischen Adressen für die Zugriffe versehen werden. Logische Adressen werden vom Betriebssystem der Karte verwaltet und lassen sich eindeutig physikalischen Adressen zuordnen. Befinden sich alle Biblio­ theken auf feststehenden Adreßbereichen, so kann das neue Mo­ dul statisch vorgelinkt sein und unverändert auf die Chipkar­ te übernommen werden. Sollte sich allerdings eine Bibliothek ihrerseits auf einem dynamisch zugewiesenen Adreßbereich be­ finden, so muß das neue Modul an sie dynamisch angelinkt wer­ den, d. h., daß das neue Modul mit den aktuell gültigen logi­ schen Adressen der Bibliothek versehen werden muß. Das neue Modul enthält bei der Programmierung also lediglich den Namen der Bibliothek und die entsprechenden symbolischen Segmentre­ ferenzen, sowie gegebenenfalls weitere Referenzen, auf die zugegriffen werden soll. Beim Linkvorgang müssen diese Refe­ renzen dann durch die aktuell gültigen logischen Adressen, insbesondere die der entsprechenden Segmente der Bibliothek ersetzt werden.

Der Linkvorgang kann prinzipiell entweder im Kartenterminal oder auf der Chipkarte stattfinden. Der erstere Fall ist als zu unsicher anzusehen, da gewährleistet sein muß, daß das Terminal nicht manipuliert wurde. Außerdem können auf der Kommunikationsstrecke zwischen Terminal und Karte die Daten nochmals manipuliert werden.

Da das neu, dynamisch angebundene Modul prinzipiell gegenüber seinem Zustand vor dem Linkvorgang verändert ist, da ja bei dem Linkvorgang die symbolischen Referenzen aufgelöst werden mußten, kann in der Chipkarte auch nicht eine statisch vorde­ finierte Signatur des Programms überprüft werden. Der einzig sichere Weg ist, den Linker auf die Chipkarte zu verlegen. Das Problem hierbei ist jedoch, daß die herkömmliche Link- Strategie, bei der ein relativ komplexer Parser den Object­ code liest und dynamische Referenzen befriedigt, zu viele Speicherressourcen auf der Karte benötigt. Bisher gab es für dieses Problem im Stand der Technik keine Lösung. Es war da­ her bisher nicht mit vertretbarem Aufwand möglich, auf einer hinreichend sicheren Chipkarte Bibliotheken auf dynamisch zu­ gewiesenen Adressbereichen zu verwenden.

Aus der DE 690 30 425 T2 ist bereits ein Kompilierungsverfah­ ren bekannt, bei dem ein Teil des Kompilierungsvorganges, nämlich die interprozedurale Registerzuordnung auf einen spä­ teren Zeitpunkt, nämlich auf den Zeitpunkt des Linkens der Programme verschoben wird.

Aus diesem Stand der Technik ergibt sich jedoch keine Lösung, die das Linken nachträglich geladener Programmodule erlauben würde. Vielmehr befaßt sich diese Entgegenhaltung ausschließ­ lich mit der Problematik der interprozeduralen Registerzuwei­ sungen beim Kompilieren.

Der nächstgelegene Stand der Technik auf diesem Gebiet ergibt sich aus der DE 197 23 676 A1. Diese Druckschrift beschreibt ebenfalls ein Verfahren zum Nachladen von Programmen auf eine Chipkarte. Gemäß diesem Stand der Technik können zwar Pro­ gramme dynamisch auf entsprechende Programmbänke verteilt werden. Dieses Verfahren ermöglicht jedoch nicht den Zugriff eines dynamisch nachgeladenen Programms auf ein anderes dyna­ misch nachgeladenes Programm oder eine dynamisch nachgeladene Adresse, da gemäß diesem Stand der Technik lediglich die Sprungadressen innerhalb eines Programms umgerechnet und an­ gepasst werden können. Auch dieser Stand der Technik löst da­ her nicht die Aufgabe, den Zugriff nachladbarer Applikationen auf Bibliotheken zu ermöglichen, die ebenfalls auf dynamisch zugewiesenen Adressbereichen abgelegt sind.

Es ist daher Aufgabe der vorliegenden Erfindung, ein Verfah­ ren zur Verfügung zu stellen, bei dem nachladbare Applikatio­ nen auf Bibliotheken zugreifen können, die sich auf dynamisch zugewiesenen Adressbereichen befinden, ohne daß Sicherheits­ probleme durch einen ausgelagerten und beispielsweise im Kartenterminal ablaufenden Linkvorgang entstehen.

Erfindungsgemäß wird diese Aufgabe dadurch gelöst, daß der Linkvorgang in zwei Abschnitte aufgeteilt wird, wobei der er­ ste Abschnitt zu einem beliebigen Zeitpunkt nach dem Kompi­ lieren des Programmoduls erfolgen kann, und lediglich der zweite Abschnitt, in dem die symbolischen Referenzen aufge­ löst werden, nach dem Laden der Programmodule erfolgen muß.

Um zusätzliche Ressourcen einzusparen, ist es besonders vor­ teilhaft, die Auflösung der dynamischen Referenzen durch ei­ nen einfachen Automaten ausführen zu lassen.

Vorzugsweise ergibt sich eine besonders einfache Programm­ struktur, wenn im ersten Abschnitt des Verfahrens ein Object- File mit einem Kopf erzeugt wird, in dem sich die Information über die Bibliotheken und ihre Segmente befindet, an die an­ gelinkt werden soll.

Es ist dabei weiter besonders bevorzugt, daß in dem Kopf des Object-Files zusätzlich die Information über diejenigen dyna­ mischen Referenzen enthalten ist, die im eigentlichen Object­ code verwendet werden.

Eine besonders einfache Verarbeitung auf der Karte ergibt sich, wenn der eigentliche Objectcode in eine Sequenz von Blöcken zerlegt ist, wobei am Anfang jedes Blocks die Infor­ mation liegt, wie viele Bytes des Objectcodes eingelesen wer­ den können, bis die erste symbolische Referenz auftritt, und der Block mit der symbolischen Referenz endet.

Eine besonders einfache Verarbeitung ergibt sich vorzugsweise auch dadurch, daß am Beginn des zweiten Abschnitts des Link­ vorgangs der Kopf des Objektcodes in den Arbeitsspeicher ab­ gespeichert wird, und dort den dynamischen Referenzen die tatsächlichen Adressen auf der Karte zugeordnet werden.

Ein besonders einfacher Linkvorgang ergibt sich, wenn während des zweiten Abschnitts des Linkvorgangs auf der Karte jeweils ein Blockanfang eingelesen wird, die Anzahl der Bytes gespei­ chert wird, die ohne Umwandlung einer dynamischen Referenz eingelesen werden können, und dann der Block ohne den Block­ anfang in den Speicher auf der Karte eingelesen wird, und am Ende des Blocks statt der dynamischen Referenz die tatsächli­ che Adresse auf der Karte aus dem umgewandelten Kopf des Ob­ jektcodes eingelesen wird.

Im folgenden wird die vorliegende Erfindung anhand des in den Zeichnungen dargestellten Ausführungsbeispiels näher erläu­ tert. Es zeigen:

Fig. 1 die Struktur des Object-Files, wie es nach dem ersten Abschnitt des erfindungsgemäßen Linkverfahrens aufgebaut ist;

Fig. 2 den Zustand des Programms nach der Umwandlung der Refe­ renzen im Objectcodekopf in die absoluten Adressen, wobei eine Referenzliste erstellt wurde;

Fig. 3 den Zustand des Programms nach der Umwandlung der Re­ ferenzen im Objectcodekopf, wobei ein Referenzstack erzeugt wurde;

Fig. 4 den Zustand des Programms nach der Umwandlung der Re­ ferenzen, wobei eine Positionenliste erzeugt wurde; und

Fig. 5 den Zustand des Programms nach der Umwandlung der Re­ ferenzen, wobei die Adressen ersetzt worden sind.

Bei dem beschriebenen Ausführungsbeispiel der Erfindung er­ folgt das dynamische Nachladen von Programmodulen auf einer Chipkarte. Dabei muß der komplexe Teil des Linkers abgespal­ ten und aus der Karte ausgelagert werden. In der Karte selbst läuft nur ein einfacher Automat ab, der das Auflösen der sym­ bolischen Referenzen erledigt. Der Linker auf der Karte ist durch das neue Linkformat der Object-Files hinreichend be­ schrieben:

Im Kopf 10 des Object-Files befindet die Information über die Bibliotheken und ihre Segmente, an die angelinkt werden soll, sowie die entsprechenden symbolischen Referenzen, die im ei­ gentlichen Objectcode verwendet werden. Der eigentliche Ob­ jectcode ist nun eine Sequenz von Blöcken 12, 14, 16. Am An­ fang eines Blocks liegt die Information, wie viele Byte des Programmcodes eingelesen werden können, bis die erste dynami­ sche Referenz auftritt. Sie beendet den Block. Die entspre­ chende Struktur des Objectfiles, wie es an die Chipkarte übergeben wird, ist in Fig. 1 dargestellt. Das Objectfile be­ steht aus einem Kopf 10, der jeweils den Namen der jeweiligen Bibliothek und des jeweiligen Segments, an das angelinkt wer­ den soll und die zugehörige symbolische Referenz enthält.

Nach diesem Objectkopf folgen die einzelnen Blöcke des Ob­ jectcodes, wobei am Blockbeginn immer die Blocklänge angege­ ben ist und jeder Block mit einer symbolischen Referenz en­ det. Die Erstellung eines solchen gem. Fig. 1 strukturierten Objectcodes kann zu einem beliebigen Zeitpunkt nach der Com­ pilierung des Programmes und auf einem beliebigen Rechner er­ folgen.

Auf der Chipkarte muß lediglich der zweite Abschnitt des Linkvorgangs erfolgen:

Der Linker auf der Karte liest den Objectkopf ein und ordnet den symbolischen Referenzen die tatsächlichen Adressen auf der Karte zu. Sofern wenige symbolische Referenzen des öfte­ ren im Objectcode benötigt werden, empfiehlt es sich, eine Zuordnungstabelle der symbolischen Referenzen auf die tat­ sächlichen Adressen anzulegen. Diese Information muß dann während des gesamten Linkvorgangs vorhanden sein. Wenn eine Vielzahl von dynamischen Referenzen nur relativ selten im Ob­ jectcode aufgerufen werden, besteht die Möglichkeit, den Linkvorgang weiter zu vereinfachen, indem im Kopf 10 des Ob­ jectcodes die symbolischen Referenzen in der Reihenfolge ih­ res Auftretens im Objectcode angeordnet werden. In diesem Fall kann man auch direkt die Adresse im Objectcode angeben, an der substituiert werden soll. Die Blockstruktur entfällt dann. Interessant ist auch noch die Möglichkeit, direkt am Ende eines Blocks den Namen und die symbolische Referenz zu spezifizieren, die dann jedesmal aufgelöst wird. Nach der Um­ setzung auf der Karte auf die tatsächlichen physikalischen Adressen steht dann im Kopf 10 eine Liste der absoluten Adressen in der Reihenfolge, wie sie in den Objectcode einge­ arbeitet werden müssen. Dazu muß nicht der Kopf ersetzt wer­ den, es reicht, wenn eine entsprechende Liste im Speicher ge­ halten wird. Diese Liste kann nach dem Laden gelöscht werden, wodurch erheblich Speicherplatz gespart wird.

Nach Erzeugung dieser Adresstabelle oder Adressliste wird je­ weils ein Blockanfang eingelesen und die Anzahl der Bytes ge­ speichert, die ohne Umwandlung einer symbolischen Referenz in das Programmsegment eingelesen werden kann. Der Blockanfang, der ja lediglich die Zahl der Bytes dieses Blocks angibt, wird dabei nicht in den Programmcode mit aufgenommen. Am Ende des Blocks wird die symbolische Referenz durch die aktuelle tatsächliche aktuelle Adresse ersetzt. Dazu wird entweder die Vergleichstabelle im Objectcodekopf 10 herangezogen, oder aus einer entsprechenden Liste einfach die zu diesem Block gehö­ rige physikalische Adresse abgerufen. Bei der letzteren Orga­ nisation kann der Kopf auch in Form eines Stapelspeichers (Stack) organisiert sein.

Sodann kann der nächste Block abgearbeitet werden.

Die Fig. 2 bis 5 zeigen den Objectcode nach Umwandlung der dynamischen Referenzen im Kopf 10. Die absoluten Adressen können dabei entweder in Form einer Tabelle organisiert sein, wobei über entsprechende Bezugszahlen (1, 2, 3) die Zuordnung zu den jeweiligen dynamischen Referenzen im Objectcode er­ folgt, oder der Kopf kann wie ein Stapelspeicher die absolu­ ten Adressen in der Reihenfolge, wie diese von den Blöcken benötigt werden, enthalten.

Im einzelnen zeigt die Fig. 2 eine erfindungsgemäße Lösung, bei der aus dem Objectcodekopf eine Liste erzeugt wird, die jeweils die Namen und die Referenzen sowie die jeweiligen tatsächlichen aktuellen Adressen enthält. Damit wird nur eine sehr kleine Tabelle erzeugt, die sehr wenig Speicherplatz braucht, wenn nur einige wenige Referenzen sehr oft in dem Programm vorkommen. Dies ist beispielsweise durch das mehrfa­ che Auftreten der Referenz M in der Figur dargestellt.

Fig. 3 zeigt eine erfindungsgemäße Lösung, wobei der Object­ codekopf in Form eines Stapelspeichers organisiert ist, der die Adressen in der Reihenfolge ihres Auftretens im Object­ code enthält. Hierbei ist der Ladevorgang weiter vereinfacht, da lediglich nach jedem Block die oberste Adresse aus dem Stapelspeicher einkopiert werden muß.

Fig. 4 zeigt eine erfindungsgemäße Lösung, wobei eine Tabelle abgespeichert wird, die außer Name und Adresse jeweils die Positionen enthält, an denen die jeweilige symbolische Refe­ renz durch die tatsächliche aktuelle Adresse ersetzt werden muß. Diese Tabelle kann dann auch am Ende des Objectcodes an­ geordnet sein. Diese Anordnung ist für die Abarbeitung noch günstiger, da die Tabelle dann nicht im Speicher gehalten werden muß, sondern erst nach dem Laden des Objectcodes in den Speicher sukzessive abgearbeitet werden kann.

Fig. 5 zeigt eine erfindungsgemäße Lösung, bei der eine direk­ te Auflösung der Adressen erfolgt.

Allen diesen erfindunsgemäßen Lösungen ist gemeinsam, daß die Ersetzung der symbolischen Referenzen durch die tatsäch­ liche aktuelle Adresse einmalig während des Ladens des Pro­ gramms auf die Karte erfolgt, und nicht zur Zeit der Abarbei­ tung des Programms. Die symbolischen Referenzen werden also nur einmal während des Ladens aufgelöst. Es müssen daher nicht dauernd die Listen mit der Zuordnung symbolischer Refe­ renz auf tatsächliche aktuelle Adresse im Speicher gehalten werden, was zu einer erheblichen Speicherersparnis führt. Er­ findungsgemäß wird also der Linker aufgespalten in einen kom­ plexen Prelinker, der unmittelbar nach dem Compilieren des Programms ausgeführt werden kann. Nach dem prelink Prozeß kann der Code signiert werden. Der signierte Code wird im Linker auf der Karte während des Einlesens gelinkt und veri­ fiziert. In den Fig. 2 bis 4 kann der Eintrag "name n" da­ bei gegebenenfalls auch wegfallen, sofern die Adressen ein­ deutig sind.

Die vorliegende Erfindung erlaubt erstmals das sichere Nach­ laden von Bibliotheken und Applikationen, die auf diese Bi­ bliotheken zugreifen. Ohne ihn könnten nur Applikationen dy­ namisch nachgeladen werden. Beispielsweise ergibt sich damit folgene Anwendungsmöglichkeit:

Kernel und Betriebssystem befinden sich statisch gelinkt auf der Chipkarte. Der Benutzer möchte nun IATA, eine Bibliothek aller Fluglinien, dynamisch auf die Karte laden und anschlie­ ßend noch eine Bonuspunkt-Applikation der Lufthansa, die auf die IATA-Bibliothek zugreift, nachladen.

Claims (7)

1. Verfahren zum Linken von in einen Arbeitsspeicher eines Prozessors nachgeladenen Programmodulen, dadurch ge­ kennzeichnet, daß das Verfahren in zwei Abschnitte aufgeteilt wird, wobei der erste Abschnitt zu einem beliebi­ gen Zeitpunkt nach dem Compilieren des Programmoduls erfolgen kann, und lediglich der zweite Abschnitt, in dem die symboli­ schen Referenzen aufgelöst werden, nach dem Laden der Pro­ grammodule in den Arbeitsspeicher erfolgen muß.

2. Verfahren nach Anspruch 1, dadurch gekenn­ zeichnet, daß die Auflösung der symbolischen Referen­ zen durch einen einfachen Automaten erfolgt.

3. Verfahren nach Anspruch 1 oder 2, dadurch ge­ kennzeichnet, daß im ersten Abschnitt des Verfah­ rens ein Objekt File mit einem Kopf (10) erzeugt wird, in dem sich die Information über die Bibliotheken und ihre Segmente befindet, an die angelinkt werden soll.

4. Verfahren nach Anspruch 3, dadurch gekenn­ zeichnet, daß in dem Kopf (10) des Objekt Files zu­ sätzlich die Informationen über diejenigen symbolischen Refe­ renzen enthalten sind, die im eigentlichen Objektcode verwen­ det werden.

5. Verfahren nach Anspruch 4, dadurch gekenn­ zeichnet, daß der eigentliche Objektcode in eine Se­ quenz von Blöcken (12, 14, 16) zerlegt ist, wobei am Anfang jedes Blocks (12, 14, 16) die Information liegt, wie viele Bytes des Objektcodes eingelesen werden können, bis die erste symbolische Referenz auftritt, und der Block mit der symboli­ schen Referenz endet.

6. Verfahren nach Anspruch 5, dadurch gekenn­ zeichnet, daß am Beginn des zweiten Abschnitts des Linkvorgangs im Arbeitsspeicher der Kopf (10) des Objektcodes abgespeichert wird, und dort den symbolischen Referenzen die tatsächlichen Adressen zugeordnet werden.

7. Verfahren nach Anspruch 6, dadurch gekenn­ zeichnet, daß während des zweiten Abschnitts des Link­ vorgangs jeweils ein Blockanfang eingelesen wird, die Anzahl der Bytes gespeichert wird, die ohne Umwandlung einer symbo­ lischen Referenz eingelesen werden können, und dann der Block ohne den Blockanfang in den Arbeitsspeicher eingelesen wird, und am Ende des Blocks statt der symbolischen Referenz die tatsächliche Adresse im Arbeitsspeicher aus dem umgewandelten Kopf des Objektcodes eingelesen wird.