WO2000014631A2 - Verfahren zum linken von in einen arbeitsspeicher eines prozessors nachgeladenen programmodulen auf einer chipkarte - Google Patents

Verfahren zum linken von in einen arbeitsspeicher eines prozessors nachgeladenen programmodulen auf einer chipkarte Download PDF

Info

Publication number
WO2000014631A2
WO2000014631A2 PCT/DE1999/002784 DE9902784W WO0014631A2 WO 2000014631 A2 WO2000014631 A2 WO 2000014631A2 DE 9902784 W DE9902784 W DE 9902784W WO 0014631 A2 WO0014631 A2 WO 0014631A2
Authority
WO
WIPO (PCT)
Prior art keywords
block
symbolic
object code
references
read
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/DE1999/002784
Other languages
English (en)
French (fr)
Other versions
WO2000014631A3 (de
Inventor
Christian May
Jürgen Freiwald
Olaf Brixel
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Infineon Technologies AG
Siemens AG
Siemens Corp
Original Assignee
Infineon Technologies AG
Siemens AG
Siemens Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Infineon Technologies AG, Siemens AG, Siemens Corp filed Critical Infineon Technologies AG
Priority to EP99953697A priority Critical patent/EP1145118A2/de
Priority to KR1020017002772A priority patent/KR20010079730A/ko
Priority to JP2000569311A priority patent/JP2002524792A/ja
Publication of WO2000014631A2 publication Critical patent/WO2000014631A2/de
Publication of WO2000014631A3 publication Critical patent/WO2000014631A3/de
Priority to US09/798,105 priority patent/US20010034818A1/en
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/445—Program loading or initiating
    • G06F9/44521—Dynamic linking or loading; Link editing at or after load time, e.g. Java class loading
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/40—Transformation of program code
    • G06F8/54—Link editing before load time

Definitions

  • the present invention relates to a method for linking program modules loaded into a main memory of a processor, for example on a chip card.
  • the invention addresses the following problem:
  • the operating system on the card must therefore be able to dynamically allocate a free memory area to a module when it is loaded onto the card.
  • a module to be reloaded must inform the chip card of which libraries it must access. After it has been verified that the module is allowed access to the corresponding libraries, it must be linked to it, ie provided with the corresponding logical addresses for the accesses. Logical addresses are managed by the card's operating system and can be clearly assigned to physical addresses. If all libraries are on fixed address areas, the new model can dul be statically pre-linked and transferred to the chip card unchanged.
  • the new module must be dynamically linked to it, ie the new module must be provided with the currently valid logical addresses of the library.
  • the new module therefore only contains the name of the library and the corresponding symbolic segment references, as well as others, if applicable. References to be accessed. During the link process, these references must then be replaced by the currently valid logical addresses, in particular those of the corresponding segments of the library.
  • the link process can take place either in the card terminal or on the chip card.
  • the former case is considered too unsafe, since it must be ensured that the terminal has not been manipulated.
  • the data can be manipulated again on the communication link between the terminal and the card.
  • this object is achieved in that the linking process is divided into two sections, the first section being able to take place at any time after the program module has been compiled, and only the second section, in which the symbolic references are resolved, after the The program modules must be loaded.
  • a particularly simple program structure is preferably obtained if, in the first section of the method, an object file with a Kop? is generated in which the information about the libraries and their segments that should be linked to.
  • header of the object file also contains the information about those dynamic references that are used in the actual object code.
  • Blocks is broken down, at the beginning of each block there is information on how many bytes of the object code can be read in until the first symbolic reference occurs, and the block ends with the symbolic reference.
  • a particularly simple processing preferably results from the fact that the header of the object code is stored in the working memory at the beginning of the second section of the link process and the actual addresses on the card are assigned to the dynamic references there.
  • a particularly simple link process results if, during the second section of the link process, a block start is read in on the card, the number of bytes is saved that can be read without converting a dynamic reference, and then the block without the block start in the memory on the card is read, and at the end of the block, instead of the dynamic reference, the actual address on the card is read from the converted header of the object code.
  • 1 shows the structure of the object file as it is structured according to the first section of the link method according to the invention
  • 2 shows the state of the program after the conversion of the references in the object code header into the absolute addresses, a reference list having been created
  • FIG. 3 shows the state of the program after the conversion of the references in the object code header, a reference stack having been generated
  • the dynamic reloading of program modules takes place on a chip card.
  • the complex part of the linker has to be split off and removed from the card. Only a simple machine runs in the card itself, which does the resolving of the symbolic references.
  • the linker on the card is sufficiently described by the new link format of the object files:
  • the header 10 of the object file contains the information about the libraries and their segments to which links are to be placed, as well as the corresponding symbolic references that are used in the actual object code.
  • the actual object code is now a sequence of blocks 12, 14, 16. At the beginning of a block there is information about how many bytes of the
  • Program codes can be read in until the first dynamic reference occurs. She ends the block.
  • the corresponding structure of the object file, as it is transferred to the chip card, is shown in FIG. 1.
  • the Object File con- sists of a head 10 of the name of each library and the ⁇ respective segment is to be linked to the respective and contains the corresponding symbolic reference.
  • the individual blocks of the object code follow this object header, whereby the block length is always specified at the beginning of the block and each block ends with a symbolic reference.
  • the creation of such a 1 structured object codes can occur at any time after the compilation of the program and on any computer.
  • the linker on the map reads in the object header and assigns the actual addresses on the map to the symbolic references. If a few symbolic references are often required in the object code, it is advisable to create an assignment table of the symbolic references to the actual addresses. This information must then be present during the entire link process. If a large number of dynamic references are only called up relatively rarely in the object code, there is the option of
  • the next block can then be processed.
  • Figures 2 to 5 show the object code after conversion of the dynamic references in the head 10.
  • the absolute addresses can either be organized in the form of a table, with the assignment to the respective dynamic references in the object code using corresponding reference numbers (1, 2, 3) or the header, like a stack, can contain the absolute addresses in the order in which they are needed by the blocks.
  • FIG. 2 shows a solution according to the invention in which a list is generated from the object code header, which list contains the names and the references as well as the respective actual current addresses. This only creates a very small table that takes up very little space if only a few references occur very often in the program. This is shown, for example, by the multiple occurrence of the reference M in the figure.
  • FIG. 3 shows a solution according to the invention, the object code header being organized in the form of a stack which stores the addresses in the order in which they occur in the object memory. contains code.
  • the loading process is further simplified here, since the top address from the stack only has to be copied in after each block.
  • FIG. 4 shows a solution according to the invention, in which a table is stored which, in addition to the name and address, contains the positions at which the respective symbolic reference must be replaced by the actual current address.
  • This table can then also be arranged at the end of the object code. This arrangement is even more favorable for processing, since the table then does not have to be kept in the memory, but can only be processed successively after the object code has been loaded into the memory.
  • the linker is thus split into a complex prelinker, which can be executed immediately after the program has been compiled. After the prelink process, the code can be signed. The signed code is in the
  • the present invention allows for the first time the secure reloading of libraries and applications that are based on these access libraries. Without it, only applications could be reloaded dynamically. For example, the following possible application results:
  • the kernel and operating system are statically linked on the chip card.
  • the user now wants to dynamically load IATA, a library of all airlines, onto the card and then reload a Guthansa bonus point application that accesses the IATA library.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Devices For Executing Special Programs (AREA)
  • Stored Programmes (AREA)

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

Beschreibung
Verfahren zum Linken von in einen Arbeitsspeicher eines Prozessors nachgeladenen Programmodulen auf einer Chipkarte.
Die vorliegende Erfindung betrifft ein Verfahren zum Linken von in einen Arbeitsspeicher eines Prozessors nachgeladenen Programmodulen, beispielsweise auf einer Chipkarte. Die Erfindung 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 werden können. Dies ist bislang aus folgendem Grund nicht mög- lieh: 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- grarnm 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 lassen 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 physikalischer 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ß. Nachdem verifiziert wurde, daß dem Modul der Zugriff auf die entsprechenden 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 Bibliotheken auf feststehenden Adreßbereichen, so kann das neue Mo- dul statisch vorgelinkt sein und unverändert auf die Chipkarte übernommen werden. Sollte sich allerdings eine Bibliothek ihrerseits auf einem dynamisch zugewiesenen Adreßbereich befinden, so muß das neue Modul an sie dynamisch angelinkt wer- den, d.h., daß das neue Modul mit den aktuell gültigen logischen Adressen der Bibliothek versehen werden muß. Das neue Modul enthält bei der Programmierung also lediglich den Namen der Bibliothek und die entsprechenden symbolischen Segmentreferenzen, sowie gegebenenfalls weitere. Referenzen, auf die zugegriffen werden soll. Beim Linkvorgang müssen diese Referenzen 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 vordefinierte 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 daher bisher nicht mit vertretbarem Aufwand möglich, auf einer hinreichend sicheren Chipkarte Bibliotheken auf dynamisch zu- gewiesenen Adressbereichen zu verwenden. Der nächstgelegene Stand der Technik auf diesem Gebiet ergibt sich aus der DE 197 23 676 AI. 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 dynamisch 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 daher 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 Verfahren zur Verfügung zu stellen, bei dem nachladbare Applikationen 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 Kompilieren des Programmoduls erfolgen kann, und lediglich der zweite Abschnitt, in dem die symbolischen Referenzen aufgelöst werden, nach dem Laden der Programmodule erfolgen muß.
Um zusätzliche Ressourcen einzusparen, ist es besonders vorteilhaft, die Auflösung der dynamischen Referenzen durch einen 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 Kop? erzeugt wird, in dem sich die Information über die Bibliotheken und ihre Segmente befindet, an die angelinkt werden soll.
Es ist dabei weiter besonders bevorzugt, daß in dem Kopf des Object-Files zusätzlich die Information über diejenigen dynamischen 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 Information liegt, wie viele Bytes des Objectcodes eingelesen werden 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 Linkvorgangs der Kopf des Objektcodes in den Arbeitsspeicher abgespeichert 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 Blockanfang in den Speicher auf der Karte eingelesen wird, und am Ende des Blocks statt der dynamischen Referenz die tatsächliche 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äutert. 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 Referenzen im Objectcodekopf in die absoluten Adressen, wobei eine Referenzliste erstellt wurde;
Fig. 3 den Zustand des Programms nach der Umwandlung der Referenzen im Objectcodekopf, wobei ein Referenzstack erzeugt wurde;
Fig. 4 den Zustand des Programms nach der Umwandlung der Referenzen, wobei eine Positionenliste erzeugt wurde; und
Fig. 5 den Zustand des Programms nach der Umwandlung der Referenzen, wobei die Adressen ersetzt worden sind.
Bei dem beschriebenen Ausführungsbeispiel der Erfindung erfolgt das dynamische Nachladen von Programmodulen auf einer Chipkarte. Dabei muß der komplexe Teil des Linkers abgespalten und aus der Karte ausgelagert werden. In der Karte selbst läuft nur ein einfacher Automat ab, der das Auflösen der symbolischen Referenzen erledigt. Der Linker auf der Karte ist durch das neue Linkformat der Object-Files hinreichend beschrieben:
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 eigentlichen 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 dynamische Referenz auftritt. Sie beendet den Block. Die entsprechende 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 werden soll und die zugehörige symbolische Referenz enthält. Nach diesem Objectkopf folgen die einzelnen Blöcke des Objectcodes, wobei am Blockbeginn immer die Blocklänge angegeben ist und jeder Block mit einer symbolischen Referenz endet. 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 erfolgen.
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 tatsä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 Objectcodes die symbolischen Referenzen in der Reihenfolge ihres 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 Umsetzung 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 eingearbeitet werden müssen. Dazu muß nicht der Kopf ersetzt werden, es reicht, wenn eine entsprechende Liste im Speicher gehalten wird. Diese Liste kann nach dem Laden gelöscht werden, wodurch erheblich Speicherplatz gespart wird. Nach Erzeugung dieser Adresstabelle oder Adressliste wird jeweils ein Blockanfang eingelesen und die Anzahl der Bytes gespeichert, 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 Organisation kann der Kopf auch in Form eines Stapelspeichers (Stack) organisiert sein.
Sodann kann der nächste Block abgearbeitet werden.
Die Figuren 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 erfolgt, oder der Kopf kann wie ein Stapelspeicher die absoluten 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 mehrfache Auftreten der Referenz M in der Figur dargestellt.
Fig. 3 zeigt eine erfindungsgemäße Lösung, wobei der Objectcodekopf 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 Referenz 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 erfindungsemäße Lösung, bei der eine direkte Auflösung der Adressen erfolgt.
Allen diesen erfindungegemäßen Lösungen ist gemeinsam, daß die Ersetzung der symbolischen Referenzen durch die tatsäch- liehe aktuelle Adresse einmalig während des Ladens des Programms auf die Karte erfolgt, und nicht zur Zeit der Abarbeitung 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. Erfindungsgemäß wird also der Linker aufgespalten in einen komplexen 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 verifiziert. In den Figuren 2 bis 4 kann der Eintrag "name n" dabei gegebenenfalls auch wegfallen, sofern die Adressen eindeutig sind.
Die vorliegende Erfindung erlaubt erstmals das sichere Nachladen von Bibliotheken und Applikationen, die auf diese Bi- bliotheken zugreifen. Ohne ihn könnten nur Applikationen dynamisch 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

Patentansprüche
1. Verfahren zum Linken von in einem Arbeitsspeicher eines Prozessors nachgeladenen Programmodulen, d a d u r c h g e- k e n n z e i c h n e t, daß das Verfahren in zwei Abschnitte aufgeteilt wird, wobei der erste Abschnitt zu einem beliebigen Zeitpunkt nach dem Compilieren des Programmoduls erfolgen kann, und lediglich der zweite Abschnitt, in dem die symbolischen Referenzen aufgelöst werden, nach dem Laden der Pro- grammodule in den Arbeitsspeicher erfolgen muß.
2. Verfahren nach Anspruch 1, d a d u r c h g e k e n nz e i c h n e t, daß die Auflösung der symbolischen Referenzen durch einen einfachen Automaten erfolgt.
3. Verfahren nach Anspruch 1 oder 2, d a d u r c h g ek e n n z e i c h n e t, daß im ersten Abschnitt des Verfahrens 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, d a d u r c h g e k e n nz e i c h n e t, daß in dem Kopf (10) des Objekt Files zusätzlich die Informationen über diejenigen symbolischen Refe- renzen enthalten sind, die im eigentlichen Objektcode verwendet werden.
5. Verfahren nach Anspruch 4, d a d u r c h g e k e n nz e i c h n e t, 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 symbolischen Referenz endet.
6. Verfahren nach Anspruch 5, d a d u r c h g e k e n nz e i c h n e t, 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, d a d u r c h g e k e n nz e i c h n e t, daß während des zweiten Abschnitts des Linkvorgangs jeweils ein Blockanfang eingelesen wird, die Anzahl der Bytes gespeichert wird, die ohne Umwandlung einer symbolischen 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.
PCT/DE1999/002784 1998-09-02 1999-09-02 Verfahren zum linken von in einen arbeitsspeicher eines prozessors nachgeladenen programmodulen auf einer chipkarte Ceased WO2000014631A2 (de)

Priority Applications (4)

Application Number Priority Date Filing Date Title
EP99953697A EP1145118A2 (de) 1998-09-02 1999-09-02 Verfahren zum linken von in einen arbeitsspeicher eines prozessors nachgeladenen programmodulen auf einer chipkarte
KR1020017002772A KR20010079730A (ko) 1998-09-02 1999-09-02 프로세서의 작업 메모리내에서 스와핑된 프로그램 모듈을칩카드상에 링킹하기 위한 방법
JP2000569311A JP2002524792A (ja) 1998-09-02 1999-09-02 プロセッサのワークメモリに後ロードされたプログラムモジュールをチップカード上でリンクする方法
US09/798,105 US20010034818A1 (en) 1998-09-02 2001-03-02 Method for linking program modules reloaded into a main memory of a processor on a smart card

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE19840029.2 1998-09-02
DE19840029A DE19840029C1 (de) 1998-09-02 1998-09-02 Verfahren zum Linken von in einen Arbeitsspeicher eines Prozessors nachgeladenen Programmodulen auf einer Chipkarte

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US09/798,105 Continuation US20010034818A1 (en) 1998-09-02 2001-03-02 Method for linking program modules reloaded into a main memory of a processor on a smart card

Publications (2)

Publication Number Publication Date
WO2000014631A2 true WO2000014631A2 (de) 2000-03-16
WO2000014631A3 WO2000014631A3 (de) 2000-07-20

Family

ID=7879588

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/DE1999/002784 Ceased WO2000014631A2 (de) 1998-09-02 1999-09-02 Verfahren zum linken von in einen arbeitsspeicher eines prozessors nachgeladenen programmodulen auf einer chipkarte

Country Status (7)

Country Link
US (1) US20010034818A1 (de)
EP (1) EP1145118A2 (de)
JP (1) JP2002524792A (de)
KR (1) KR20010079730A (de)
CN (1) CN1354853A (de)
DE (1) DE19840029C1 (de)
WO (1) WO2000014631A2 (de)

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2001283160A (ja) * 2000-03-30 2001-10-12 Dainippon Printing Co Ltd Ｉｃカードおよびｉｃカードの更新装置とその方法
WO2002008873A1 (en) * 2000-07-25 2002-01-31 Macrovision Coporation System and method of verifying the authenticity of dynamically connectable executable images
US6510516B1 (en) 1998-01-16 2003-01-21 Macrovision Corporation System and method for authenticating peer components
US6802006B1 (en) 1999-01-15 2004-10-05 Macrovision Corporation System and method of verifying the authenticity of dynamically connectable executable images
WO2002097619A3 (en) * 2001-05-30 2004-10-28 Research In Motion Ltd A mobile communications device application processing system
US7650504B2 (en) 1999-07-22 2010-01-19 Macrovision Corporation System and method of verifying the authenticity of dynamically connectable executable images

Families Citing this family (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
RU2206119C2 (ru) * 2000-09-22 2003-06-10 Закрытое акционерное общество "МЦСТ" Способ получения объектного кода
US7131121B2 (en) * 2001-11-14 2006-10-31 Axalto, Inc. Method and apparatus for linking converted applet files without relocation annotations
NL1019876C2 (nl) * 2002-01-31 2003-08-04 Chess Embedded Technology B V Systeem en werkwijze voor het laden van een programmacode in een inrichting alsmede een werkwijze voor het voeden van een programmacode aan een inrichting.
FR2839792B1 (fr) * 2002-05-15 2004-08-20 Gemplus Card Int Procede de chargement d'une applet dans un objet electronique portatif
US7047101B1 (en) * 2002-07-29 2006-05-16 Kla-Tencor Technologies Corporation Reuse in semiconductor measurement recipes
DE102004058882A1 (de) * 2004-12-06 2006-06-08 Giesecke & Devrient Gmbh Erzeugen von Programmcode in einem Ladeformat und Bereitstellen von ausführbarem Programmcode
EP1724677A1 (de) * 2005-05-19 2006-11-22 Axalto SA System und Verfahren zur Speicherverwaltung in tragbarem Gerät
JP2010198139A (ja) * 2009-02-23 2010-09-09 Dainippon Printing Co Ltd プラットフォーム完全性検証システム及び方法，並びに，セキュリティトークン
DE112021007471T5 (de) * 2021-04-07 2024-01-18 Mitsubishi Electric Corporation Code-anpassungseinrichtung und code-anpassungsverfahren
CN114860204B (zh) * 2022-04-27 2024-07-02 恒宝股份有限公司 程序处理、运行方法、装置、终端、智能卡及存储介质

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2000846A1 (de) * 1968-01-26 1969-09-12 Hirst Buckley Ltd
JPH02214994A (ja) * 1989-02-15 1990-08-27 Hitachi Maxell Ltd Ｉｃカード
CA2066724C (en) * 1989-09-01 2000-12-05 Helge Knudsen Operating system and data base
US5507030A (en) * 1991-03-07 1996-04-09 Digitial Equipment Corporation Successive translation, execution and interpretation of computer program having code at unknown locations due to execution transfer instructions having computed destination addresses
EP0691006B1 (de) * 1993-03-23 1998-01-07 Apple Computer, Inc. Gerät und verfahren für ein verschiebbares dateiformat
US5734822A (en) * 1995-12-29 1998-03-31 Powertv, Inc. Apparatus and method for preprocessing computer programs prior to transmission across a network
US6055314A (en) * 1996-03-22 2000-04-25 Microsoft Corporation System and method for secure purchase and delivery of video content programs
FR2757970B1 (fr) * 1996-12-30 1999-03-26 Gemplus Card Int Procede de chargement d'un programme d'utilisation dans un support a puce
US6317872B1 (en) * 1997-07-11 2001-11-13 Rockwell Collins, Inc. Real time processor optimized for executing JAVA programs
US6282706B1 (en) * 1998-02-10 2001-08-28 Texas Instruments Incorporated Cache optimization for programming loops

Cited By (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6510516B1 (en) 1998-01-16 2003-01-21 Macrovision Corporation System and method for authenticating peer components
US6802006B1 (en) 1999-01-15 2004-10-05 Macrovision Corporation System and method of verifying the authenticity of dynamically connectable executable images
US7650504B2 (en) 1999-07-22 2010-01-19 Macrovision Corporation System and method of verifying the authenticity of dynamically connectable executable images
JP2001283160A (ja) * 2000-03-30 2001-10-12 Dainippon Printing Co Ltd Ｉｃカードおよびｉｃカードの更新装置とその方法
WO2002008873A1 (en) * 2000-07-25 2002-01-31 Macrovision Coporation System and method of verifying the authenticity of dynamically connectable executable images
AU2000263715B2 (en) * 2000-07-25 2004-11-04 Rovi Solutions Corporation System and method of verifying the authenticity of dynamically connectable executable images
KR100752067B1 (ko) * 2000-07-25 2007-08-28 메크로비젼 코오포레이션 동적으로 연결 가능한 실행 가능 이미지들의 진정성을증명하는 시스템 및 방법
CN100394385C (zh) * 2000-07-25 2008-06-11 麦克罗维西恩公司 确认动态可连接可执行镜像的可靠性的系统和方法
WO2002097619A3 (en) * 2001-05-30 2004-10-28 Research In Motion Ltd A mobile communications device application processing system
US7493616B2 (en) 2001-05-30 2009-02-17 Research In Motion Limited Mobile communication device application processing system
EP2244185A1 (de) * 2001-05-30 2010-10-27 Research In Motion Limited System zur Verarbeitung einer Anwendung für ein mobiles Kommunikationsgerät
US8627316B2 (en) 2001-05-30 2014-01-07 Blackberry Limited Mobile communications device application processing system

Also Published As

Publication number Publication date
KR20010079730A (ko) 2001-08-22
US20010034818A1 (en) 2001-10-25
WO2000014631A3 (de) 2000-07-20
JP2002524792A (ja) 2002-08-06
EP1145118A2 (de) 2001-10-17
CN1354853A (zh) 2002-06-19
DE19840029C1 (de) 2000-04-20

Similar Documents

Publication Publication Date Title
DE69918334T2 (de) Erzeugung von kompilierten programmen für interpretative laufzeitumgebungen
DE69123775T2 (de) Programmsteuersystem für eine tragbare Datenspeichervorrichtung
WO2000014631A2 (de) Verfahren zum linken von in einen arbeitsspeicher eines prozessors nachgeladenen programmodulen auf einer chipkarte
DE60001118T2 (de) Migration von unterschiedlichen quellsprachen zu einer ausführungsumgebung
DE2725718C2 (de) Datenverarbeitungsanordnung zum Übersetzen von virtuellen Adressen
DE2226382C3 (de) Datenverarbeitungsanlage mit mehreren Prozessoren und diesen zugeordneten Pufferspeichern
DE69819686T2 (de) Objekt und verfahren zum bereitstellen eines effizienten mehrbenutzerzugriff auf verteilten betriebssystemkernkode durch instanzierung
DE69427174T2 (de) Dynamische Hochleistungsprogrammverknüpfung durch Cachespeicherung
DE69029210T2 (de) Verwaltungsverfahren und Vorrichtung zur Datenspeicherung
DE19681256C2 (de) Ausführung von Anwendungen am Platz vom Speicher
DE68916853T2 (de) Unabhängige Programmlader für virtuelle Maschinenarchitektur.
DE69814174T2 (de) Java laufzeitsystem mit veränderter sammlung von konstanten
DE2550268A1 (de) Schnelldrucker fuer datenverarbeitungssysteme
DE69028269T2 (de) Virtuelles Adressierungsverfahren zum Betrieb eines Speichers in einer Datenverarbeitungsanlage und Einrichtung zur Ausführung besagten Verfahrens
DE69429777T2 (de) System zur dezentralen massenspeichersteuerung eines rechners mit virtuellem speicher
DE69932964T2 (de) Verfahren, System und Rechnerprogrammprodukt zur Initialisierung einer Datenstruktur beim ersten Gebrauch
DE2350146A1 (de) Verfahren und netzwerk zur neuordnung eines rechnerspeichersystems
DE1499182B2 (de) Datenspeichersystem
DE68929080T2 (de) Anordnung zum Speichern von Informationen für einen Datenanbieterprozessor
DE2326616A1 (de) Verfahren zum betreiben einer mehrere speichereinheiten enthaltenden datenverarbeitungsanlage
DE4429969A1 (de) Verfahren für einen Programmpaketeaustausch in einem Mehrrechnersystem und Rechner dafür
DE3441640A1 (de) Streifenfeldspeichercontroller
DE2550212A1 (de) Drucker mit pufferspeicher
DE19933584A1 (de) Verfahren zur kompakten Darstellung von Informationspaketen und deren Speicherung oder Übertragung
DE102008044808B4 (de) Verfahren zur Generierung von Programmcode in einem Betriebssystemspeicher und einem Applikationsspeicher eines Datenträgers

Legal Events

Date Code Title Description
WWE Wipo information: entry into national phase

Ref document number: 99810510.4

Country of ref document: CN

AK Designated states

Kind code of ref document: A2

Designated state(s): BR CN IN JP KR MX RU UA US

AL Designated countries for regional patents

Kind code of ref document: A2

Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE

121 Ep: the epo has been informed by wipo that ep was designated in this application
AK Designated states

Kind code of ref document: A3

Designated state(s): BR CN IN JP KR MX RU UA US

AL Designated countries for regional patents

Kind code of ref document: A3

Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE

WWE Wipo information: entry into national phase

Ref document number: 1999953697

Country of ref document: EP

DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
ENP Entry into the national phase

Ref document number: 2000 569311

Country of ref document: JP

Kind code of ref document: A

WWE Wipo information: entry into national phase

Ref document number: 1020017002772

Country of ref document: KR

Ref document number: PA/a/2001/002268

Country of ref document: MX

WWE Wipo information: entry into national phase

Ref document number: IN/PCT/2001/260/KOL

Country of ref document: IN

WWP Wipo information: published in national office

Ref document number: 1020017002772

Country of ref document: KR

WWP Wipo information: published in national office

Ref document number: 1999953697

Country of ref document: EP

WWW Wipo information: withdrawn in national office

Ref document number: 1999953697

Country of ref document: EP

WWR Wipo information: refused in national office

Ref document number: 1020017002772

Country of ref document: KR

ENPW Started to enter national phase and was withdrawn or failed for other reasons

Ref document number: PI9917392

Country of ref document: BR

Free format text: PEDIDO CONSIDERADO RETIRADO EM RELACAO AO BRASIL, POR TER SIDO A FASE NACIONAL INTEMPESTIVA.